When a migration quote contains the phrase "expect a few hours of disruption", that phrase does not describe a technical limit. It describes a method: switch off here, switch on there, and hope propagation is merciful.
Downtime is not inevitable. It is the result of two choices — changing DNS before anything has been tested, and turning the old server off too early — and it is avoided by preparing the move rather than performing it.
The principle: two live environments at once
The idea that makes everything else possible is simple. For a period, the site exists in two places, both working, and DNS gradually decides how many visitors each one serves.
There is no moment when the service is off. There is a period when it is served by two machines, and anyone still landing on the old one finds a site that answers. Everything else follows from this: the TTLs, the order of operations, the double mail sync.
Stage 1: the inventory, which is the part people skip
Before copying anything, you need to know what actually exists. Almost every migration that went badly had one item nobody had catalogued:
- cron jobs, which are not in the website: they run on the server, and nobody remembers them until a monthly report stops arriving;
- certificates, and who issues and renews them;
- subdomains used by external services — webmail, a business system, shipment tracking;
- mailboxes, all of them, including aliases and people who have left;
- integrations that call the server from outside: the ERP, the courier, the payment gateway, which often hold a list of allowed IP addresses that needs updating;
- who the domain's Registrant is, because that determines whether you can perform the migration or have to ask for it.
This stage produces a sheet of paper. That sheet is half the work.
Stage 2: the copy on a staging environment
Site, database and files are copied to the new host and tested on a temporary address, while the domain quietly keeps pointing at the old server.
What gets tested, concretely: the pages, the contact forms, the cart if there is one, the admin panel, image uploads, scheduled jobs and — separately — sending mail from the new environment.
This is where you find the different PHP version, the missing extension, the absolute path hard-coded five years ago. Finding it now costs an hour. Finding it after the DNS change costs however long the site is broken for everybody.
Stage 3: the TTLs, the day before
A TTL is how long servers around the world are allowed to remember the old answer. If it is twenty-four hours, your change takes up to twenty-four hours to be seen everywhere — and, more importantly, any rollback takes just as long.
So: at least twenty-four hours before the move, the TTLs on the records that will change are lowered to a few minutes. This is not an optimisation, it is what makes the operation reversible.
After a few quiet days, they go back up.
Stage 4: the mail, which is the delicate part
A website is static compared to mail: you can copy it and it stays the same. Mailboxes do not — they keep receiving while you are copying them.
So mail is migrated in two passes:
- First synchronisation, complete, while everything still arrives at the old server. It can take hours and disturbs nobody.
- Change the MX records.
- Second synchronisation, immediately afterwards, collecting the messages that arrived between the first copy and the switch.
- The old mail server stays on for a few days, because some senders and servers will keep knocking at the old address until their TTL expires.
Done this way, nothing is lost. Skip step 3 and you lose exactly that day's mail — which is the mail people remember.
Stage 5: the switch, and what to check straight after
The DNS change happens outside working hours, but not in the middle of the night: it happens while somebody is still awake to look at the results.
In the first minutes you check, in this order: the site on the new address, HTTPS and the certificate, a real contact form, sending and receiving a real email, external integrations, scheduled jobs.
The old environment stays up until the new one has passed all of those and a few days of ordinary traffic. Turning it off is the last operation of a migration, not the first.
What about Google rankings?
If the domain does not change, nothing changes for search: the addresses stay identical and search engines simply see a different server answering. The two things that do hurt are different, and both are avoidable:
- changing URLs at the same time as the hosting. If the address structure needs reworking too, that happens later and with redirects, not in the same weekend;
- leaving the site unreachable for a long time. An hour does no damage; a full day does.
The method described here avoids both by construction.
How long it takes, in practice
A company website with a handful of mailboxes is prepared across a couple of non-consecutive days of work, and the switch itself takes an hour. An e-commerce site with integrations needs more preparation, not a longer switch.
The number that matters is not how long the move takes, but how many minutes of disruption it contains: prepared this way, none.
If your current supplier has offered you an outage window — or will not cooperate with the move — that is precisely what hosting and email migration handles.