Migrating to a new host sounds risky, but with the right sequence you can move a website with little or no visible downtime. The secret is preparation and a careful cutover — never just switching things and hoping. Here is a practical, order-of-operations guide.
Step 1: Lower Your DNS TTL First
Days before the migration, reduce the TTL on the DNS records you will change (typically your A/AAAA records) to a low value such as 300 seconds. TTL controls how long resolvers cache your records, so lowering it in advance means that when you finally switch, the change propagates in minutes rather than hours. This single step prevents most “why is half my traffic still hitting the old server” problems.
Step 2: Set Up and Test the New Server
Provision the new host and replicate your environment — web server, runtime, dependencies, and configuration. Deploy your application and copy your files. Crucially, test the new server before any DNS change by accessing it directly via its IP address or a temporary hostname. Confirm the site loads and works fully on the new server while the old one still serves live traffic.
Step 3: Sync Your Data Last
For a site with a database or changing content, do an initial data copy during setup, then a final sync right before cutover to capture anything that changed in between. For busy sites, consider a brief read-only or maintenance window during the final sync to avoid losing writes. Static sites skip this complexity entirely.
Step 4: Cut Over the DNS
Once the new server is verified, update your DNS records to point to the new server’s IP. Because you lowered the TTL earlier, traffic will shift over within minutes. During this propagation window, keep the old server running — some resolvers will still be sending users there until their cache expires.
Step 5: Run Both in Parallel
This is the key to zero downtime: do not shut down the old server the moment you change DNS. Keep both servers live and serving the same content for at least 24–48 hours, until you are confident all traffic has moved. If your site takes writes, point both to the same database during this window, or keep the old one read-only, so no data is lost regardless of which server a visitor lands on.
Step 6: Verify, Then Decommission
Check your new server’s logs to confirm it is receiving traffic and the old server’s logs to confirm traffic has tapered off. Test forms, logins, email, and any integrations on the new host. Only once the old server has gone quiet and everything is verified should you decommission it. Raise your TTL back to a normal value afterward.
Common Pitfalls
- Forgetting email. If the old host also handled email, plan MX and mail migration separately — do not let a web move break your mail.
- Hardcoded IPs. Application configs or third-party integrations pointing at the old IP will break; find them before cutover.
- Skipping the test step. Never change DNS before confirming the new server fully works.
- Killing the old server too soon. Cached DNS means stragglers arrive for a while; keep it alive.
How Noded Can Help
We help customers migrate onto our platform with this kind of careful, parallel cutover so the move is smooth and low-risk. If you are planning a migration — a website, a database, or a whole fleet — tell us about your current setup and we will map out the sequence, including the data-sync and DNS timing, so your users never notice the move.
FAQ
How long does a website migration take?
The work varies with site complexity, but the visible cutover can be minutes if you lower DNS TTL in advance and run both servers in parallel. Plan for a day or two of overlap before decommissioning the old host.
Will my site go down during migration?
It does not have to. By testing the new server before changing DNS and keeping the old server running during propagation, you can achieve little or no visible downtime. Sites that take writes may want a brief read-only window during the final data sync.
Why lower the DNS TTL before migrating?
TTL controls how long resolvers cache your DNS records. Lowering it in advance means your cutover propagates in minutes instead of hours, so traffic moves to the new server quickly and predictably.
When can I shut down the old server?
After traffic has fully shifted — usually 24 to 48 hours post-cutover — and you have verified the new server is handling everything correctly. Cached DNS keeps sending some visitors to the old server until it expires, so do not decommission early.