Zero-downtime migration: how we move a live site

“Zero-downtime migration” sounds like a promise that should carry an asterisk. It does not need one — but it does need a method. The trick is that at no point does your site live in only one place: the old copy keeps serving until the new copy has provably taken over. Here is the five-step sequence we run for every move, and precisely which parts of it need you.

§01The five steps

1. 1

   Inventory and copy

   With read access to your current host, we take a complete copy — files, database, TLS requirements, and the full DNS record set — onto a staging berth on the fleet. Your live site is untouched; nothing in this step is visible to visitors.

2. 2

   Stage and verify

   The copy comes up at a private staging address on its assigned node. We click through the pages, submit the forms, confirm the database came across whole, and issue the TLS certificate ahead of time so the padlock never blinks during the switch.

3. 3

   Drop the TTL

   Every DNS record carries a time-to-live — how long the internet may remember an old answer. A day or more before cutover we lower yours from hours to five minutes. This one step is what makes the eventual switch take minutes instead of trickling out over days.

4. 4

   Freeze and sync the delta

   Just before cutover we ask for a short content freeze — no edits, typically minutes to an hour. We sync everything that changed since the first copy: new posts, new orders, new uploads. The two copies are now identical.

5. 5

   Cut over and watch

   We point DNS at the fleet. For the next few minutes both origins serve the same current site while the internet updates its memory. Monitoring watches both sides through the window, and your old hosting stays warm for about a week as a deliberate safety net.

§02Why nothing goes dark

DNS is not a switch; it is a rumor that spreads. When the record changes, some networks hear about it immediately, while others keep serving the old answer until their cached copy expires. A naive migration treats that lag as a problem. The method treats it as the mechanism: because the freeze already made both copies identical, it does not matter which origin a visitor reaches during propagation. There is no moment when the site is nowhere — there is a window when it is deliberately in two places at once.

§03Your side of the ledger, and ours

§04The email caveat

The one place migrations genuinely bite people is email — not because it is hard, but because it is forgotten. If your mailboxes live at your current host, the MX records that route your mail are part of what must be preserved or deliberately moved. Step one’s DNS inventory exists precisely for this: every record is accounted for before anything changes, so moving the website never silently takes the mail down with it. If email needs a new home as part of the move, that is handled — managed email and DNS is part of Forge and above.

§05What zero downtime actually means

Honesty requires defining the term. During the overlap window your site is fully up on both origins, so visitors never meet an error page. What “zero downtime” cannot mean — for any host — is zero seconds of content freeze on a database-driven site: those minutes are the price of the two copies being identical, and we schedule them where they cost nothing. Static and brochure sites usually skip even that.

Migration is included with every plan — it is step zero of hosting, not a billable adventure. If your setup has an unusual shape — custom services, a tangle of subdomains, DNS history nobody remembers writing — that is a conversation, not a surcharge. Write to us and we will map it before anything moves.