Every server has a lifespan. Hardware generations improve, capacity needs change, a site outgrows the machine it launched on, or a better home simply becomes available. Moving a website from one server to another is one of the most ordinary operations in hosting, and also one of the most quietly feared, because the traditional version of it involves a maintenance page, a weekend, and a stretch of hours where nobody is entirely sure which server a given visitor is seeing.
We have built our platform so that a migration does not have to look like that. We move live sites between servers with no visitor-facing downtime: no maintenance page, no announcement, no late-night window. The site keeps answering on the old server until the new one is proven ready, and then traffic switches in an instant. We have done this on production sites, including a busy online shop, in the middle of a normal week.
This article explains how that works and, more importantly, why it changes the way infrastructure decisions get made.
The old cliff: DNS propagation
To understand what we changed, it helps to see where the pain traditionally comes from. In a classic migration, the address of your website, its DNS record, points directly at the old server. Moving means changing that record to point at the new one. The catch is that DNS changes do not take effect everywhere at once. Resolvers around the world cache the old answer and let go of it on their own schedule, over minutes or hours.
That lag is the cliff. During propagation, some visitors reach the old server and some reach the new one, and anything that changes on one side, an order, a form submission, a comment, is invisible on the other. The standard defenses are all unpleasant: freeze the site so nothing can change, put up a maintenance page, or schedule the whole exercise for the quietest hour you can find and accept the mess at the edges. The migration itself might take an hour; the uncertainty tail is what eats the weekend.
Fronting traffic at the edge changes the problem
On our platform, DNS does not point at the server where a site happens to live. It points at our edge, the traffic layer we run in front of every hosted site. The edge terminates the secure connection, applies protections like the firewall and bot handling, and then forwards each request to whichever server currently runs the site.
That one level of indirection dissolves the cliff. When a site moves, its public address does not change at all, so there is nothing for the wider internet to slowly propagate. The only thing that changes is an internal routing decision at our edge: requests for this site now go to the new server instead of the old one. That decision takes effect for all visitors at the same moment, because it happens in one place we control rather than in thousands of caches we do not.
How a move actually unfolds
With the addressing problem gone, the migration itself becomes a careful, unhurried sequence. We provision the site on the destination server first: the same hardened containers, the same configuration, built from the same definitions as the original, because everything about how a site runs is described in versioned form rather than accumulated by hand on one machine. Then we bring the data across and verify the result while the old server continues to serve every visitor, blissfully unaffected.
Verification is the step we refuse to rush. Before any traffic moves, we check the new environment against the running site: the application comes up, the content is present, the integrations respond, the certificates are in order. Only when the new server has demonstrated that it is ready does the edge switch traffic over, instantly and for everyone. A final synchronization closes the small gap that accumulated during the switch, and the move is done.
Notice what is absent from that sequence: a maintenance page, a frozen site, a leap of faith. At every point until the switch, the old server is fully in charge. At every point after it, the new one is. There is no in-between period where the site is half moved, and if verification had turned up a problem, the switch simply would not have happened, with visitors none the wiser.
We do this on live sites, on weekdays
Process descriptions are cheap, so it matters that this is not a theoretical capability. We have moved production sites between servers this way, including an online shop where every minute of downtime is a minute of lost orders, and we did it mid-week, during normal hours, without a maintenance page. Visitors browsed and bought through the entire operation. The shop owner experienced the migration mainly as a message from us saying it was complete.
Doing this during the week, rather than hiding it in the small hours of a weekend, is a deliberate choice. An operation that is only safe when nobody is watching is not really safe; it is merely unobserved. Because the procedure keeps the site continuously available, we can run it when our full team is fresh and present, which is exactly when you want people making the final checks. The quality of attention at two in the afternoon is simply better than at two in the morning.
Reversibility is the real prize
The zero-downtime part of this story is what clients notice, but the deeper benefit is what it does to decision-making. When moving is risky, infrastructure choices calcify. A site stays on an aging server not because anyone believes it is the best home, but because the migration feels like surgery and nobody wants to schedule surgery without a pressing reason. Better hardware, better placement, better economics all sit on the far side of a move that keeps not happening.
When moving is routine, those decisions reopen. A server generation with better performance for the same money is worth taking, because taking it costs an afternoon of our time and none of yours. Rebalancing sites across machines, retiring old hardware on our schedule rather than its failure schedule, placing a growing site on a stronger host before it strains the current one: all of this becomes ordinary housekeeping instead of a project with a risk register. And because the edge can switch traffic in either direction, even the move itself stays reversible until the moment it has proven itself.
Infrastructure should stay a choice
The thought we want to leave you with is not really about migrations. It is about what mobility does to a hosting relationship. A site that can move freely is never held hostage by the machine underneath it. The server becomes what it always should have been: a replaceable component in service of the site, chosen on merit and swapped without ceremony when something better exists.
That is the standard we hold our own platform to. The best measure of a migration is that nobody outside the team ever has a reason to know it happened.