Skip to main content

Blog · Migration

Moving web hosts without losing a second

By the Hosting & Domains team Published 27 July 2026 7 min read

Fear of the move keeps more people on poor hosting than any renewal discount has ever managed. That fear is misplaced. Take the steps in the right order and a migration produces no downtime whatsoever, not a small amount but none, since the old site goes on answering every visitor until the new copy has proved itself and been switched in. Outages turn up when the order gets muddled, and only then.

Below is that order, the reason each step sits where it does, and the two familiar mistakes behind every horror story. Come to us and our team runs the whole thing at no charge. Knowing what a clean move looks like is still worth having, if only so you can check our work.

One rule: copy first, cut over last

Think of a migration as three distinct jobs: copy the site, check what you copied, then redirect the traffic. Your old host never learns that a copy exists and keeps serving the domain as it always has. Job three, the DNS change, holds all the risk. That is exactly why it comes last, after the duplicate has passed its checks.

In practice, keep paying for the old account right through the changeover. A few dollars buys you the overlap, and an outage costs a great deal more than that. Copy the lot, test it hard on the new server, and repoint the name only after that. Cancel the old plan a week or two on, once nothing depends on it.

The sequence, step by step

1. Write the inventory: site files, databases, mailboxes with everything inside them, the quieter DNS records like SPF and DKIM and any subdomains, whatever certificates you need, cron jobs. Migration pain almost always traces back to something left off that inventory, and it is usually mail or the DNS extras.

2. Shift the files and the database across to the new host. WordPress has a well-worn path for this, and anything sitting on cPanel restores whole from a full account backup.

3. Check the copy while DNS is still untouched. Point your hosts file at the new server, or use the preview URL the host gives you, and browse the site as though it were already live. Submit the forms. Run a checkout, log in, log out. That dull hour of testing is what makes the cutover safe.

4. A day before the switch, lower the DNS TTL to 300 seconds. The change then propagates in minutes instead of days. (Our jargon buster explains what TTL means.)

5. Build the mailboxes on the new host, then choose the moment for the mail cutover on purpose. Mail is the part nobody thinks about until a message bounces. The email migration guide covers copying the contents across over IMAP.

6. Move DNS, watch requests start landing on the new server, confirm the certificate has issued, then send yourself a test message. For a few hours, stragglers holding cached DNS still reach the old server. Both copies serve identical content, so nobody notices the join.

7. Once a full week has passed without incident, take one last backup of the old account and close it.

The two errors every outage story shares

Mistake one: repointing DNS while the copy is still unchecked. Visitors flood onto a half-built site and now you are debugging in production, with customers watching you do it. Every migration-downtime story that reaches us starts at that precise moment, which is why the copy-first rule exists.

Mistake two: shutting the old account down too early. At a good many hosts, cancelling means deletion, so if the new copy is concealing a fault, the working original no longer exists. That old account is your rollback. Hold onto it until the new one has carried real traffic for several days.

A word about lock-in. Where a host makes leaving awkward, refusing backup exports, putting an obstacle course in front of cancellation, or charging transfer-out fees on names, it is telling you its retention strategy. Test whether you can leave before the day you need to. It is also the reason our migrations run as a free, checked, no-downtime service: arriving should be simple, and nothing technical should stand in the way of the exit.

Quick answers

How long does a host-to-host move take?

Measured on the calendar, a few days, and most of that is waiting on purpose: the TTL drop first, then the watch after cutover. Measured in working hours, a handful for an ordinary site, or close to zero when the new host carries out the move for you. Copy at the beginning, switch at the end, and the site never goes dark.

Does email break when you switch hosts?

Not if the mailboxes are already sitting on the new host before DNS changes, with their contents copied across over IMAP. Mail is the piece a migration forgets most often. Put it at the top of your list and plan its cutover with the same care you give the website.

Cancel the old hosting before the move, or once it is done?

Afterwards, without exception. Leave it running through the switch itself and for a week beyond that, at the very least. Should the new server misbehave, that account is your live rollback, and the overlap costs a few dollars set against the real price of an outage.

Up next

More from the blog

The hosting these notes are written on

Renewals that stay flat, limits printed before you buy, migration at no charge and a support desk that writes back, all wrapped into one plan.

Browse Hosting Plans