Moving a live business onto new infrastructure without stopping it

The business took orders every day of the week and had no natural quiet hour. That single fact removes most of the standard playbook: there is no maintenance window to hide in, so the migration has to be something that happens alongside trading rather than instead of it.

What follows is the actual sequence we used, including the parts that were slower than they needed to be. The systems were a hosted application, a production database with nine years of history, and a file store the whole operation depended on.

The first week produced no migration at all. It produced a list: every service, every scheduled job, every integration, every credential, and — the item most often missed — every thing that writes to the database from outside the application. There were three of those, and two were undocumented.

The rule we hold to: you cannot move what you have not enumerated, and enumeration is always slower than it looks because the undocumented items are only found by tracing traffic rather than reading code.

The new infrastructure was built alongside the old and fed continuous replication from the live database. For six days the two systems ran in parallel with the old one still authoritative: all reads and writes stayed where they were, and the new stack simply followed along.

This is the part that buys the whole thing. By the time you cut over, the destination has been running your real data under real load for a week, and you have watched it do so. Nothing about the cutover is a first attempt.

Before touching production we ran a restore of the new environment’s backup into a third, isolated environment, and had the client’s own operations lead verify specific records — a recent order, an old invoice, a customer with unusual characters in their name.

We do this because a backup that has never been restored is a belief. It failed the first time. The file store restored, the database restored, and the references between them did not line up, because the two were snapshotted eleven minutes apart. The fix was ordering the snapshots and taking them under a brief write lock; the discovery was worth the whole rehearsal.

Cutover ran at the quietest hour we could find rather than the ideal one. The sequence: stop accepting new writes at the edge and queue them, let replication drain to zero lag, promote the new database, repoint the application, drain the queue into the new stack, and open the edge again.

Total time with writes queued rather than lost: nineteen minutes. No orders were dropped, because they were held rather than refused — queuing at the edge is what turns downtime into latency.

We had a rollback prepared and rehearsed: the old stack stayed intact and authoritative-capable for seventy-two hours, with a written decision rule for when to use it. We did not need it. Preparing it was still the right call, because the only reason the cutover was calm was that nobody in the room was afraid of it.

Two things. We would snapshot the database and the file store as one operation from the start rather than discovering the ordering problem in rehearsal. And we would run the parallel period for two weeks rather than one, not because a week was insufficient but because the second week costs almost nothing and covers the monthly jobs a single week never exercises.

A migration is not a technical event. It is a rehearsal, a queue, and a rollback nobody needs.