Migrating a Website to New Hosting Without Downtime
A step-by-step guide to moving hosting without losing the site, email or search rankings: DNS, TTL and verification, in the right order.
rabbitclip teamPublished: 5 min read
Short answer
A migration without downtime happens when the new server is fully set up and tested before the DNS records are switched over; the site is never left half-ready between two servers. That depends on lowering the DNS records' time-to-live, TTL, a few days before the move; otherwise the switch to the new server can take hours, sometimes a full day, to reach everyone.
A facilities management company's site stopped receiving email on migration day and lost customer enquiries for weeks; the cause was rarely the new server itself, it was the MX records not being changed at the same time as the rest of the DNS. A migration done in the right order removes that risk from the start.
What is actually at risk in a hosting migration?
A hosting migration is moving a website's files, database and email service from one server to another. The risk sits in three places: the site being unreachable during the move, email being delayed or lost, and a DNS change sending the wrong signal to search engines.
The common factor across all three is timing; a migration done in the right order with the right TTL setting largely closes off all three.
Pre-migration checklist
The following needs to be done at least a week before migration day.
- The site is fully set up and tested on the new server, checked via a temporary address, the server's own IP or a test subdomain
- A current backup of the database and files is taken and kept on both the old and new server
- A full list of DNS records, A, MX, CNAME, TXT, is pulled and matched one to one on the new server
- The TTL on the current DNS records is lowered at least 48 hours before migration
Why lower TTL days before migration?
TTL controls how long a DNS record is cached by browsers and servers. Per Cloudflare's DNS documentation, a change made against a long TTL can take hours to reach every visitor; that is why it makes sense to lower TTL ahead of time whenever a change is planned.
If TTL drops from an hour to a few minutes several days before migration, the actual DNS change on migration day propagates far faster; some visitors may still land on the old server for a few minutes, but that window stays measured in minutes rather than hours.
What order does migration day follow?
Once the new server is tested and ready, migration day runs in this order: DNS records are updated first, then the old server is kept running, usually for a week, continuing to answer any requests that arrive until the old TTL fully expires.
Both servers are watched during that waiting period; traffic is seen shifting to the new one, error rates and response times are compared. If something goes wrong, the DNS record can be pointed back at the old server, which is exactly why it should not be switched off immediately.
How to avoid an email outage
Email depends on where the MX records point; if MX records are forgotten while the site's DNS gets updated, or changed at a different time, incoming mail can end up split between the old and new server for a while, or lost outright.
The safer approach is running email as a service separate from the site; where possible, email sits on an independent service and is untouched by the site migration. If it stays on the same server, MX records need to be updated and tested at the same time as the site's own records, not afterwards.
How to confirm migration is actually complete
A DNS lookup tool that checks from several regions shows which IP address the domain currently resolves to in each one, and how far propagation has actually got. The old server should stay running until every region returns the new address; this check takes a few minutes.
The same check works for email; once the MX record is confirmed pointing at the new server, a test email should be sent and confirmed as actually arriving. These two simple checks turn a migration into something confirmed by evidence rather than assumed complete.
Post-migration verification and common mistakes
A few checks after migration catch a problem early: the SSL certificate is valid on the new server, forms and checkout actually work, and there is no sudden spike in errors in search console.
- Not lowering TTL before migration, letting propagation take hours
- Switching off the old server immediately on migration day, removing the option to roll back
- Updating MX records at a different time than the site's DNS records, causing email loss
- Not installing the SSL certificate on the new server before migration, triggering an insecure connection warning at the moment of the switch
A hosting migration, done in the right order, is a background process the visitor never notices. Lowering TTL early, moving MX records in step with the site's DNS, and not switching off the old server immediately are the three rules behind a clean migration. A discovery call with rabbitclip is a good place to review your own hosting migration plan.
FAQ
Does a hosting migration affect SEO rankings?
Not directly if the addresses stay the same. A migration that also changes URLs needs redirects set up properly; that is a separate piece of work.
How long does a migration take?
Preparation can run for days, but the actual downtime, with the right TTL setting, stays measured in minutes.
When should the old server be switched off?
After at least a few multiples of the TTL window, usually about a week, while the new server is monitored.
Is a separate email service required?
Not required, but it significantly cuts the risk of email depending on the site's own migration.
How is propagation confirmed as complete?
A DNS lookup tool checks whether the domain resolves to the new server's address from several regions; the old server stays on until every region agrees.
