The migration, in the order it actually happens
A migration rarely fails on the technical side: it fails on sequence. The TTL lowered after the cutover, the MX changed before the mailboxes exist, the old contract cancelled before anyone read the logs — each of those inversions costs half a day. Here is the full sequence, from the first inventory to the cancellation.
The day markers apply to an ordinary site or server. A shop in peak season, or a fleet of several dozen mailboxes, means stretching these steps out — not skipping any of them.
- D-7 — Inventory what actually runs. The sites and their domains, the PHP version in use, the databases and their engine, the mailboxes and their size, the scheduled tasks, the certificates and their expiry dates, and every third party that knows your current IP address (payment gateway, SMTP relay, webhooks). That list, not your memory, is what you will check against at the end.
- D-7 — Size the target on real usage, not on the plan you are paying for today. Measure the disk space actually used, the size of the databases, the memory actually consumed. A site that fits in 6 GB does not need a 200 GB plan just because the old one advertised it.
- D-5 — Open the new hosting and build the copy. Files and databases are transferred once, in full, with nothing changing on the public side. This copy does not need to be up to the second: it is there to prove the application starts.
- D-3 — Freeze changes on the old server. No new articles, no plugin updates, no theme edits until the cutover. Anything written after this point will have to be resynchronised by hand.
- D-2 — Lower the TTL on the records that are going to change, down to 300 seconds. This is done at least 48 hours before the cutover, for the reason explained in the DNS section below. It is the step most often done too late, and the only one that cannot be caught up.
- D-1 — Test the copy under its real domain name, without touching public DNS: edit the
hosts file on your machine so the domain points to the new IP address. You then see exactly what your visitors will see, absolute links and redirects included.
- D-1 — Prepare the target DNS zone without publishing it. Write down the exact values of the A, AAAA, MX, SPF, DKIM, DMARC and CAA records you are going to set. Writing them beforehand avoids improvising on the day, when the site is already half switched.
- D-Day — Resync the delta. A second copy pass transfers only what changed since D-5, then a fresh database dump replaces the previous one. That short second pass is what defines the real downtime window.
- D-Day — Publish the new DNS records. With a 300-second TTL set two days earlier, the cutover takes effect within minutes for most visitors, not within twenty-four hours.
- D-Day — Run the checks in the order given below. Do not tick anything from memory: open the list and actually test.
- D+1 — Raise the TTL back to its usual value; 3600 seconds is fine in most cases. A permanently short TTL multiplies queries against your name servers for no benefit.
- D+7 — Cancel the old contract, not before. Wait until you have received mail on the new mailboxes, restored a backup on the new host, and read through the error logs. Cancelling often wipes the data the same day.
What gets transferred, and by which means
A hosting account is not one single block: it is a stack of items, each of which moves with its own tool. Handling them separately avoids the most common mistake, which is to copy the files and hope the rest follows.
- Files.
rsync over SSH when both sides allow it, SFTP otherwise. Two passes beat one: a full pass while the site is running, and a second one just before the cutover that only picks up the differences. Then check that permissions, ownership and symbolic links survived — a badly configured FTP client flattens them without warning.
- Databases.
mysqldump --single-transaction --quick for MySQL and MariaDB, pg_dump -Fc for PostgreSQL. Note the character set and collation of the source database and create the target with the same ones: that detail is what turns accented characters into unreadable text after import.
- The panel backup. If your current hosting is run through a control panel, its built-in export — files, databases, mailboxes and settings in one archive — is often the safest route. Our web hosting plans ship with the Plesk panel, which has its own backup and restore tooling.
- The disk image, for a whole server. On a VPS or dedicated server there are two routes: copy the disk as it is (a
raw or qcow2 image, or a block-level copy from a rescue system), or start from a clean system and redeploy the application on top. If your current host does not give you access to the disk image, the second route is the only one available — and it is the one we recommend anyway for a system that is several years old.
- Certificates. Do not move them: a Let's Encrypt certificate is reissued in seconds on the new server once the domain points there. If you pay for an extended-validation certificate, export the private key before cancelling, or you will have to buy it again.
- Mailboxes. An IMAP synchronisation copies messages, the folder tree and the read/unread state from one server to the other. Run it twice, as with the files: once before the cutover, once after, to catch the messages that arrived in between.
- Scheduled tasks and services.
cron jobs, systemd timers, queues and long-running processes appear in no site backup. Copy them by hand, then check that they actually run after the cutover, not merely that they are declared.
- Secrets. Authorised SSH keys, API tokens, application encryption keys, service credentials: they often live outside the site folder and get lost silently. An application that starts but can no longer decrypt its stored data is almost always a key left behind on the old server.
DNS: what to prepare before, what switches on the day
DNS is the part of a migration you do not control on your own. Between your zone and your visitors sit resolvers that hold the old answer in memory for exactly as long as you told them to. That duration is the TTL, and it is the only lever you have to shorten the cutover.
Hence the rule: lower the TTL before, never during. If your TTL is currently 86400 seconds and you drop it to 300 on the morning of the cutover, resolvers that already hold the old value will keep honouring it for twenty-four hours. Lowering it 48 hours earlier lets the old value expire on its own, and the cutover becomes a matter of minutes.
- 48 hours before: lower the TTL to 300 seconds on every record you are going to change — A and AAAA at a minimum, plus the MX and its related CNAMEs if mail is moving too. The TTL is set in the DNS zone, wherever that zone is hosted: your registrar, in most cases.
- Record the current zone before touching it. A
dig yourdomain.com ANY query, or a zone export from the interface, gives you the starting state. Keep it: that is your way back if something goes wrong.
- A and AAAA. The A record carries the IPv4 address of the new hosting, AAAA its IPv6 address if it has one. Do not forget
www and the subdomains actually in use: a webmail, an api, a staging site. The ones people forget are the ones they never visit themselves.
- MX: the record everyone forgets. It names the server that receives your mail, and it is independent of the one hosting the site. If your mail stays where it is, do not touch it — that is the classic "replace every IP in the zone" mistake, which redirects mail to a server that has never heard of it. If mail is moving too, change the MX only once the mailboxes exist and are synchronised.
- SPF. A single TXT record listing the servers allowed to send mail in your name. If it still names the old hosting, messages sent from the new one will be filed as spam or rejected. Add the new server before the cutover, remove the old one once the migration is confirmed — and keep one single SPF record: two cancel each other out.
- DKIM. The signature is produced by the sending server and verified against a public key published in your zone under a selector. Publish the new server's selector before switching and leave the old one in place for a few days: two selectors coexist without interfering, which is not the case for SPF.
- DMARC. It tells recipients what to do with messages that fail the checks above. During a migration, stay on
p=none with a reporting address: you observe without breaking anything, and you tighten the policy once SPF and DKIM are clean on both sides.
- CAA, if present. This record lists the authorities allowed to issue a certificate for your domain. If it does not name the one your new host uses, issuance fails silently and the site stays on invalid HTTPS, with no clear error message anywhere.
- Reverse DNS (PTR). It is not set in your zone but on the IP address, so at the host that owns it. It matters as soon as your server sends mail itself: without a PTR consistent with the name the server announces, some recipients will refuse the message. On our side, reverse DNS can be customised on request.
The real downtime, and how to bring it close to zero
The outage most people fear — "my site will be unreachable during DNS propagation" — does not exist if both hostings answer at the same time. During propagation some visitors land on the old server and some on the new one, and both serve the site. Nobody sees an error.
The real window is elsewhere: it is the moment the site still accepts writes on one side while the database has already been exported. An order placed during that window is recorded on the old server and will never exist on the new one. Reducing downtime therefore means reducing that write window — not fighting DNS.
- Brochure or static site: no downtime at all. Nothing is written server-side, the copy can be made the day before, and the cutover needs no particular precaution.
- Database-driven site: a few minutes. Put the site in read-only or maintenance mode, export the database, import it, switch. On an ordinary site the whole operation fits in five to fifteen minutes, scheduled during a quiet hour.
- Online shop: the same window, but announced. Warn the team, pick a genuinely quiet slot — often early morning — and afterwards compare the last orders on both sides before treating the old server as disposable.
- Mail: no outage, but an overlap period. Until the MX has propagated everywhere, messages keep arriving on the old server. Keep access to it for a few days and run a second IMAP synchronisation after the cutover: that is what prevents the lost message.
- Applications with a queue or deferred jobs: drain the queue first. A job in flight at export time will be lost, or replayed twice. Stop the consumers, let the queue empty, then export.
After the cutover: the checks, in order
This list is worked through from top to bottom on cutover day. The order is not decorative: each item assumes the previous one passed, and a failure at item 2 makes everything after it meaningless.
- DNS resolution. Query a public resolver and your own ISP's: both must return the new address. Until they do, what you see in your browser proves nothing.
- The site answers, from the right machine.
curl -I https://yourdomain.com must return a 200; if in doubt, curl --resolve lets you force the address and compare both servers side by side.
- The certificate. Valid, for the right name, and covering
www as well. Allow a few minutes after propagation for automatic issuance; beyond an hour, go and look at the CAA record.
- Redirects. HTTP to HTTPS, and
www to the bare domain or the other way round — but in one direction only, as a 301 rather than a 302, and with no chain of two consecutive redirects.
- Deep pages. The homepage almost always works. Open five or six internal URLs picked at random: that is where lost rewrite rules and absolute links still pointing at the old domain show up.
- Forms. Send a test message through the contact form and check it arrives. A form that displays "thank you" while sending nothing is the most common post-migration defect.
- Payment, if there is any. A test order in sandbox mode, through to the confirmation and its email. Check as well that the gateway does not have an IP allowlist waiting to be updated.
- Outbound mail. Send a message from the site to an external address, open the header of what you received and read the SPF and DKIM results. You want "pass" on both; if not, go back to the DNS section.
- Inbound mail. Write from outside to one of the migrated addresses, and keep watching the old mailbox for a few days.
- Scheduled tasks. Wait until one run has gone by and check its trace, rather than checking only that the line exists in the job table.
- Error logs. Read them for the first 48 hours. A missing extension or a hard-coded absolute path shows up there immediately, usually before anyone complains.
- A first backup on the new host. Take one, then restore it once to make sure it is usable. That is the condition to meet before cancelling the old contract.
The pitfalls that cost a full day
- The TTL lowered on the day itself. It achieves nothing: the old, long value is already cached. Part of your visitors stay on the old server all day, and you go hunting for a fault that does not exist.
- The MX replaced out of reflex. Replacing "every IP in the zone" takes the mail along with the site. If the mailboxes are not moving, the MX does not move.
- The SPF left pointing at the old server. The site works, the emails leave, and nobody receives them — or they land in spam. It is the hardest defect to diagnose after the fact, because nothing visibly fails.
- The old contract cancelled too early. Cancellation wipes the data, often the same day, and takes with it the messages that arrived after the cutover and the only still-fresh copy of the files.
- The certificate requested before DNS points across. Validation fails, the site shows a security warning, and the browser remembers the error. Wait for propagation, then request issuance.
- The staging
robots.txt copied over as is. A Disallow: / inherited from the test environment deindexes the site within days. Read that file again right after the cutover.
- The PHP version changing without anyone deciding it. New hosting often defaults to a more recent version. Reproduce the original version first, upgrade afterwards, once the migration is behind you.
- Cache and CDN forgotten. If a CDN sits in front of your site, it is not the public A record you need to change but the origin declared inside the CDN. And purge the cache after the cutover, or you keep serving the old site.
- IP allowlists at third parties. Payment gateway, SMTP relay, partner API, remote database: anything that filters by IP address must know the new one before the cutover, not after.
Migrating a server is not migrating a site
The two operations share a name and not much else. Migrating a site means moving files, a database and mailboxes onto hosting that is already administered: the system, the security updates and the panel come with it. That is what the handled migration to our web hosting plans covers.
Migrating a server means rebuilding a machine: system, packages, services, firewall, users, certificates, backups. On a KVM VPS you get a dedicated IPv4 address, root SSH access and a panel offering reboot, reinstall, snapshots and a console. That console matters on cutover day: it is what lets you take back control if a firewall rule shuts the SSH door on you.
Our advice when the original machine is several years old: do not copy the disk, rebuild. Otherwise you inherit settings nobody can explain any more. Take a snapshot right before each risky step — it costs nothing in time and turns a mistake into a simple rollback. For a whole infrastructure to move, describe what you have in a quote: we will map out the sequence with you rather than announce a timeline before seeing the machine.
Search rankings during the migration
Changing hosts while keeping the same domain and the same URLs has, in itself, no effect on rankings: from a search engine's point of view only the IP address changes, and that is not a ranking factor. The losses observed after a migration almost always come from something else.
- URLs that change without redirects. If the structure evolves at the same time as the hosting, prepare the mapping table before the cutover and serve 301s, not 302s. Keep them for twelve months at least.
- An accidental indexing block.
robots.txt, an X-Robots-Tag header, a noindex tag inherited from a test environment: check all three on the day.
- A site slower than before. Application cache and compression often need re-enabling on the new hosting. Measure response time before and after rather than assuming it.
- A broken sitemap. Check it is still reachable and up to date, then let the crawler come back on its own. Crawl rate recovers within days; there is nothing to force if the URLs have not moved.
