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

More people stay on bad hosting out of fear of moving than any renewal discount ever held. The fear is misplaced. Done in the right order a migration causes no downtime at all, not a little but none, because the old site keeps answering every visitor until the new copy is proven and switched in. Outages only appear when the order gets muddled.

Here is that order, why each step sits where it does, and the two classic mistakes behind the horror stories. Move to us and our team handles the whole thing at no charge, but knowing what a clean move looks like is worth having anyway, if only to check our work.

One rule: copy first, cut over last

A migration is three separate jobs: copying the site, checking the copy, and redirecting the traffic. The old host has no idea a copy exists and carries on serving your domain as usual. All the risk sits in job three, the DNS change, which is precisely why it goes last, once the copy has proved itself.

In practice that means keeping the old account paid through the transition. A few dollars buys the overlap, and an outage costs many times that. Copy everything, test it hard on the new server, and only then repoint the name. Cancel the old plan a week or two later, once nothing relies on it.

The sequence, step by step

1. List everything: site files, databases, mailboxes and their contents, the less obvious DNS records such as SPF, DKIM and subdomains, certificate needs, and cron jobs. Migration pain nearly always comes from the forgotten items on that list, usually mail and the DNS extras.

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

3. Check the copy before DNS moves at all. Use your hosts file or the host's preview URL and browse the new site as though it were live. Work through the forms, the checkout and the login. It is that dull round of testing that makes the cutover safe.

4. Drop the DNS TTL to 300 seconds a day before the switch, so the change propagates in minutes rather than days. (What TTL means.)

5. Create the mailboxes on the new host and time the mail cutover deliberately. Mail is the part everyone remembers only when it bounces. The email migration guide covers copying the contents across over IMAP.

6. Move DNS, watch the requests arrive at the new server, confirm the certificate has issued, and send yourself a test message. Stragglers on cached DNS reach the old server for a few hours, and since both copies serve the same content, nobody sees a join.

7. After a quiet week, take a final backup of the old account and shut it down.

The two errors every outage story shares

Mistake one: repointing DNS before the copy has been checked. Visitors pour onto a half-built site and you are debugging in production with customers watching. Every migration-downtime story we hear begins at exactly that point, and the copy-first rule exists so it cannot.

Mistake two: closing the old account too soon. At plenty of hosts cancellation triggers deletion, so if the new copy is hiding a fault, the working original has gone. The old account is your rollback. Keep it until the new one has taken real traffic for several days.

A word on lock-in. A host that makes leaving awkward, with no backup exports, an obstacle course at cancellation, or transfer-out fees on names, is showing you its retention strategy. Test portability before you need it. It is also why our migrations run as a free, checked, no-downtime service: easy to arrive, and nothing technical in the way of the exit.

Quick answers

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

On the calendar, a few days, most of it deliberate waiting through the TTL drop and the watch after cutover. In working hours, a few for an ordinary site, or nearly none if the new host runs the move for you. Copy at the start, switch at the end, and the site never goes dark.

Does email break when you switch hosts?

Not when the mailboxes already exist on the new host before DNS changes and the contents are copied over IMAP. Mail is the piece migrations forget most, so put it at the top of the list and plan its cutover as carefully as the website's.

Should the old hosting be cancelled before the move or after?

Afterwards, always. Keep it running through the switch and for a week beyond at least. It is your live rollback if the new server misbehaves, and the overlap costs a few dollars against what an outage really costs.

Up next

More from the blog

The platform these posts come from

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