We migrated a client's hosting with zero downtime: how we pulled it off in one weekend
A client who sells handmade furniture wrote to us in August because the host they’d had for four years (signed up before they worked with us) hiked the price 40% from one month to the next, no warning, just a different invoice in their inbox. They decided to leave. The catch is that store takes orders every single day, Saturdays included, so even two hours of downtime meant real lost sales, not some abstract number on a dashboard.
Migrating a site to another host with zero downtime means, in practice, running both servers in parallel during the switch and lowering the TTL on the DNS records days in advance, so propagation takes minutes instead of the usual 24-48 hours. That’s the short answer. The longer one has more wrinkles than it looks.
The first thing we did, a week before touching anything, was drop the TTL on every record to 300 seconds. Most providers leave it at 3600 or even 86400 by default, and if you switch DNS with that value still set, resolvers out there will keep hitting the old server for the better part of a day, no matter what you’ve already migrated. With a low TTL, within five minutes most visits were already landing on the new server.
What breaks if you just flip the DNS and hope
The classic mistake is to get the new server ready, change the A record, and assume everything flows on its own. It doesn’t. During the propagation window, which even with a low TTL still ran a couple of hours and not zero, we had traffic hitting both servers at once. If the old server keeps taking orders while the new one already has its own database, you end up with duplicate or missing sales in between. We fixed it by putting the old server into read-only mode 48 hours before the switch, with a quiet notice on the checkout page, and syncing the database one last time right before shutting it down for good.
Email is the thing almost nobody remembers
And then there’s email, which is what actually bit us. We changed the A record thinking only about the website, and forgot the MX records still pointed at the old host (makes sense, mail never lived there), but the old host’s own panel was internally redirecting SMTP traffic in a way we’d never documented. For forty minutes, contact forms went nowhere. Nobody complained, thankfully, but it was the kind of silent failure you only catch if you’re watching the logs that same afternoon, something we now do as a matter of course after the day a host went down without warning taught us not to trust “if nobody’s complaining, it’s fine.”
We ended up moving that client to one of the VPS boxes we manage ourselves, with active monitoring from minute one, not three months in once we’d gotten comfortable. It cost us a whole Saturday and a couple extra coffees, but by Monday the client had no idea they’d even switched providers.
What still bugs me, months later, is that this whole process still lives in a mental checklist shared across the team, nowhere written down with enough detail. Every migration we’ve remembered something different at the last minute — email this time, a payment plugin’s webhooks the time before. How many invisible things are still riding on someone happening to remember just in time?