Moving hosts without downtime: the hosting migration sequence

Moving a website to a new host without downtime is almost entirely a DNS sequencing problem. Get the domain’s records changed and propagated correctly, with the old host still running during the transition, and the move is invisible to visitors. Skip that overlap, and the site goes dark for however long propagation takes. The DNS sequencing below is the part specific to hosting migration. The ordinary launch-checklist items that apply to any migration are covered separately in what a migration checklist contains.

Why downtime happens when moving off old hosting, mechanically

A domain’s DNS records tell the internet which server to fetch a website from. When a host changes, those records need to be updated to point at the new server. But DNS changes do not take effect everywhere at once. Internet service providers around the world cache DNS records for a period set by the Time to Live (TTL) value on that record. That means some visitors reach the new host quickly, while others — whose provider has an older cached record — keep reaching the old one for a while afterward. Downtime happens specifically when the old host is switched off or emptied before this propagation window has fully passed.

The hosting plan migration sequence: how to migrate to a new server without downtime

Lower the TTL on the domain’s DNS records well before the move, ideally at least 24 to 48 hours in advance. A shorter TTL means cached records expire and refresh faster once the actual change is made, shrinking the propagation window.

Set up the new site fully on the new host, before touching DNS at all. Test the new host and confirm it works — reachable via its own temporary address or a local hosts-file test — with all content, forms and functionality verified, while the domain’s DNS still points at the old host.

Change the DNS records, then keep the old host running. Once DNS is updated, do not turn off or delete the old hosting account immediately. Some visitors will still be reaching the old host during propagation. Keeping it live and functional during this window is what actually prevents visible downtime.

Monitor both the old and new hosts during the propagation window. Confirm traffic is gradually shifting to the new host, and that both versions of the site keep working correctly for whoever reaches them.

Only decommission the old host once propagation is confirmed complete — checked using a DNS propagation checking tool, or simply by monitoring traffic and error logs on the old host until visits there have genuinely stopped.

Getting the backup files, cPanel export and MySQL database onto the new hosting account first

None of the DNS sequencing above matters until the site itself actually exists on the new host. For most small-business sites that means transferring the website’s files and, where the site runs on a database-driven platform such as WordPress, its MySQL database as well. Most hosting control panels — cPanel being the most common — provide a built-in backup tool that packages the site’s files and a database export together. Where cPanel is not available, an FTP transfer of the files plus a separate database export and import covers the same ground manually. Whichever method is used, the new hosting account should hold a complete, working copy of the old one — files and database both — before any DNS record is touched. That is exactly the testing step covered next.

Testing the new web hosting provider before the domain’s name servers point at it

To confirm the new host actually works before committing to the DNS change, reach the new server directly, bypassing DNS entirely. Do this either through a temporary address the new host provides, or by editing the local hosts file on a testing computer to point the domain name at the new server’s IP address, just for that machine. This lets a genuine, full test of the new host — every page, every form, every integration — happen against the real domain name in a browser. No other visitor is affected, and the live DNS record stays untouched until the test has actually passed.

The certificate has to be ready before the switch, not after

A valid SSL/TLS certificate for the domain needs to be issued and correctly installed on the new host before DNS is pointed at it, not requested afterward. If DNS switches over to a new host that does not yet have a working certificate for the domain, visitors reaching the new host see a security warning or a broken padlock rather than a working page. That looks and functions exactly like an outage, even though DNS and hosting are both technically working as configured. Confirming the certificate is live and correctly matched to the domain is part of the pre-cutover testing step — not a separate task left until after the move.

What to do about content that changes during the transition window

If the site accepts anything dynamic — a form submission, an order, a booking — during the propagation window itself, there is a real risk that some of that activity is captured by the old host and some by the new one, depending on which server a given visitor’s request happened to reach. For a low-traffic informational site, this is a minor and rarely realised risk. For a site processing live orders or time-sensitive bookings, it is worth either scheduling the cutover during the business’s quietest period, or briefly showing a maintenance notice during the narrowest part of the transition specifically to avoid this split. Do not assume the propagation window is uneventful for every kind of site.

A one-page sequence

Step	Timing
Lower DNS TTL	24–48 hours before the move
Build and fully test the new site on the new host	Before any DNS change
Update DNS records to point at the new host	The move itself
Keep the old host running and monitored	Through the full propagation window
Decommission the old host	Only once propagation is confirmed complete

Where email complicates this

If business email is hosted through the same account as the website (a configuration covered as worth avoiding on its own terms elsewhere in this site’s hosting guidance), moving hosts risks briefly disrupting email delivery alongside the website — worth checking and, ideally, worth being a specific reason email is kept independent of website hosting in the first place.

What to do next

Build in a genuine overlap window rather than attempting an instant cutover — the overlap, not any specific technical trick, is what actually prevents downtime. For what this kind of migration typically involves as part of a broader project, web development services covers where hosting migration work sits in scope.