Guides 25 August 2026 6 min read

Move your website to a new host without downtime

Migrations go wrong in the same four places every time. The order of operations that keeps your site, your email and your SSL running through the switch.

By the PearlFibers Team

Most hosting migrations are described the same way afterwards: "the site was fine, but the email broke for two days." That is not bad luck. It is what happens when a move is treated as one switch instead of four separate systems that happen to share a domain name.

A migration done in the right order has no downtime at all — not "a few minutes", none. Visitors keep loading the old server until the exact moment they start loading the new one, and neither server ever goes dark. Here is the order that makes that true.

First, understand what you are actually moving

A domain is a signpost, not a place. Behind it sit at least four independent things, and each has to be moved deliberately:

• The website — files and, usually, a database.
• Email — mailboxes and the years of mail already inside them. This is the part that hurts.
• DNS — the records that tell the world where the site and the mail live.
• The domain registration itself — which may sit with a completely different company than your host.

You do not have to move all four at once, and usually you should not. Moving the website is a small job. Moving mailboxes is the one that needs a plan and a weekend.

Lower your TTL a day early

Every DNS record carries a TTL — how long resolvers around the world are allowed to cache it. If your A record has a TTL of 14400, some visitors will keep hitting the old server for four hours after you change it, and there is nothing you can do about it at the time.

So do it before. A day ahead of the move, drop the TTL on the records you are going to change to 300 seconds. Now the world forgets the old answer in five minutes instead of four hours, and your cutover window shrinks from "most of a day" to "the length of a coffee". Put the TTL back up after the move is settled.

This single step is the difference between a clean switch and a day of "it works for me, not for her".

Build the new site and test it before any record changes

Copy files and database to the new server, then verify it there — before the domain points at it. Two ways to do that:

• A temporary hostname on the new host, which is fine for a static site but will mangle anything with absolute URLs baked into a database.
• A hosts-file entry on your own machine, which points only your computer at the new server while the rest of the world still sees the old one. This is the honest test: same domain, same URLs, real conditions.

Walk the site properly at this stage. Forms actually submitting. Login working. Images loading. The checkout completing. A migration is not "the homepage appeared" — it is every path a customer takes.

Email is the part that bites

Websites are stateless enough to copy twice. Mailboxes are not: while you are copying, new mail keeps arriving, and mail that lands on the old server after you switch is not automatically on the new one.

The sequence that works:

1. Create every mailbox on the new server first, with the same addresses — including the aliases and forwarders people forgot to mention.
2. Sync existing mail across with an IMAP transfer while the old server is still live and receiving. Nothing is lost, because nothing has been switched yet.
3. Change the MX records.
4. Run the sync again after the switch, to sweep up whatever arrived on the old server during the changeover.
5. Leave the old mailboxes in place for two weeks. They cost nothing and they are your safety net.

And test sending, not just receiving. A new server that receives perfectly but lands in spam has not finished migrating — which brings us to the records nobody remembers.

The records people forget

Everybody moves the A record and the MX. The ones that quietly cause trouble a week later:

• SPF — if it still authorises only your old provider, mail from the new one starts failing authentication.
• DKIM — new server, new key, new record. Copying the old one across achieves nothing.
• DMARC — if you publish a strict policy and forget the two above, you will reject your own mail convincingly.
• Subdomains — the CRM, the staging site, the tracking tool, the thing marketing set up in 2023.
• Verification TXT records — for search consoles and business tools, which silently unverify when dropped.

Export the full zone from the old provider before you touch anything, and treat it as the checklist. If you are not sure who is answering for your domain today, that question is worth settling first — we wrote about why we answer for our own domains rather than leaving it to a registrar's default.

Cut over, then watch

With a 300-second TTL, the change itself is anticlimactic. Point the records, then spend the next hour watching rather than celebrating: server logs on both machines, a test order, a test message in and out, and the SSL certificate on the new host — which must be issued and installed before the switch, not after, or the first visitors of the new era will meet a browser warning.

Do not cancel the old hosting the same day. Keep it for two to four weeks. It costs one more month and it is the cheapest insurance in this entire process; it also lets you compare behaviour if something looks different.

The migration checklist

• Full backup of files, database and mail, kept somewhere neither host controls
• Zone export from the current DNS provider
• TTLs lowered to 300, at least a day ahead
• Site copied and verified on the new server via hosts file
• SSL issued on the new host before cutover
• Mailboxes created, aliases included, first IMAP sync done
• Records changed: A, MX, SPF, DKIM, DMARC, subdomains, verification TXT
• Second mail sync after cutover
• Send and receive tested from outside your own network
• Old host kept alive for two to four weeks
• TTLs raised again once stable

Or hand it over

This is a well-understood procedure, but it is a procedure — and doing it for the first time on your own live business is an expensive place to learn. Moving a site onto PearlFibers hosting includes the migration: we take the export, stage the site, handle the mailboxes, prepare the records and cut over at a quiet hour, with the old host left running behind us.

If you are still deciding what you are moving to, the honest comparison is here: shared hosting or a VPS. And if the reason for moving is that nobody can tell you who controls your DNS today, start with managed DNS — that is a smaller move, and it makes every future one easier.