Migrating a live site to a new host without downtime is genuinely achievable, and the mistakes that cause visible outages during a migration are almost always about doing things in the wrong order, not about anything technically difficult. The full sequence, done correctly, keeps a site fully live and working for every visitor the entire time, right up until traffic quietly shifts to the new server.
Start With DNS TTL, Days Before Anything Else Moves
The single highest-leverage step happens before any files move: lowering the TTL (time to live) on your domain’s DNS records, ideally 48 hours ahead of the actual cutover. If your current TTL sits at a common default like 3,600 seconds (one hour) or higher, dropping it to something like 300 seconds well in advance means that by the time you actually change where the domain points, resolvers around the internet pick up the new value within minutes rather than potentially an hour or more, since their cached copies expire fast. Skipping this step is the single most common reason a technically well-executed migration still produces a visible gap for some visitors.
Move Everything While the Domain Still Points at the Old Host
Copy the site’s files and export the database to the new host while the domain’s DNS is still pointing entirely at the old server. This is the part of the process with zero risk to live visitors, since nothing about what they’re actually seeing changes yet, you’re just getting an exact copy running somewhere new. Once the copy is complete, access the new host directly through its temporary URL or IP address (most hosts provide one specifically for this purpose) rather than through the live domain, and verify everything actually works there: pages load correctly, forms submit, any dynamic functionality behaves as expected, before the domain has anything to do with it.
The Rule That Prevents Most Migration Disasters
Don’t touch DNS until everything has been verified working on the new host through its temporary address. This is the step people skip when they’re in a hurry, and it’s the single biggest predictor of whether a migration goes smoothly or turns into a visible outage. A site that looks fine on the temporary URL but breaks once the real domain and its associated configuration (SSL certificate binding, absolute URLs hardcoded somewhere, environment-specific settings) get involved is a real, common failure mode, and catching it before DNS changes means catching it with zero visitor impact.
Making the Actual Cutover
Once verification is complete, update the domain’s A record (and any other relevant DNS records) to point at the new server. With the TTL already lowered in advance, most visitors transition to the new server within minutes to a couple of hours, rather than the up-to-48-hour window a full nameserver delegation change can take. Keep the old hosting account active and untouched during this transition window, canceling it too early, before you’re confident every visitor and every cached DNS resolver has moved over, is the second most common cause of migration downtime, right behind skipping the TTL step.
What People Forget: Email
Website DNS and email DNS are often the same domain but genuinely separate records (MX records specifically), and they don’t necessarily migrate on the same schedule as your web traffic. If email is staying with a different provider than your web hosting, or if email needs to move too, confirm MX records are handled as their own explicit step in the migration plan, not assumed to just follow along with the web hosting move. A migration that goes perfectly for web traffic but silently breaks incoming email for a day is still a real, disruptive failure, just a quieter one than a visibly broken website.
After the Move
Once the new server has been live and stable for a day or two, with no remaining traffic hitting the old host’s logs, it’s safe to decommission the old hosting account and raise the DNS TTL back to a normal value, a low TTL indefinitely means more DNS lookups than necessary for no ongoing benefit once there’s no more change planned. The full sequence, lower TTL early, migrate files with DNS untouched, verify on the temporary URL, only then cut over DNS, and keep the old host alive through the transition, is what separates a migration nobody notices from one that generates support tickets.