A website migration goes wrong when people switch the DNS first and test later. Do it in the right order and your visitors never see a flicker. The trick is to build and fully test the new home before you point the world at it, and to prepare DNS so the switch happens in minutes, not days. Here is the sequence that migrates a site, its DNS, and its server with no downtime.
Understand what makes migrations risky
When you change where your domain points, that change does not reach everyone at once. Internet providers cache the old location for a while, controlled by a setting called TTL (time to live). If your TTL is set to a day, some visitors keep hitting your old server for up to 24 hours after you switch. If the old server is already gone, those visitors see a dead site. Managing the TTL is what turns a scary cutover into a quiet one.
Step 1: Lower your TTL a day or two ahead
Before you touch anything else, go into your DNS and lower the TTL on the records you plan to change (usually the A record, and sometimes CNAME or MX). Drop it from the common 3600 or 86400 seconds down to 300 seconds, which is five minutes. Do this at least a full day before the migration, so the old, longer TTL has time to expire everywhere. Now, when you make the real switch, it propagates in about five minutes instead of a day.
Step 2: Build and prepare the new server first
Set up the new host completely while the old site keeps serving visitors. Copy over the files and the database, install the software, and get everything in place. Nobody is pointed here yet, so you can take your time and get it right. Do not change any public DNS during this step. The new server sits ready and invisible, usually reachable only by its raw IP address or a temporary host name.
Step 3: Test with your hosts file before you switch anything
This is the step that separates a clean migration from a gamble. Your computer has a hosts file that lets you override DNS for yourself only. You point your domain at the new server's IP address on your own machine, visit the site exactly as a real visitor would, and confirm everything works, all before the public DNS changes. If something is broken, only you see it, and you fix it with zero risk.
- On Windows: open Notepad as administrator and edit
C:\Windows\System32\drivers\etc\hosts. - On Mac or Linux: edit
/etc/hostswith sudo. - Add a line: the new server's IP, a space, then your domain, like
203.0.113.10 example.com www.example.com.
Save it, then load your domain in a browser. You are now seeing the new server while the rest of the world still sees the old one. Click every important page, submit a form, log in, check it on the real domain name so links and SSL behave correctly. When it all works, remove the line from your hosts file to return to normal.
Step 4: Cut over the DNS
Now make the real change. Update the A record (and any others) to point at the new server. Because you lowered the TTL in step one, the switch reaches visitors within about five minutes. Since you already tested with the hosts file, you know exactly what they will see, and it works.
Step 5: Keep the old server running and verify
Do not cancel the old host yet. Leave it running for several days. Some visitors and cached records take time to move over, and you want them landing on a working site the whole time. Meanwhile, verify the essentials on the new server: the SSL certificate is valid and the padlock shows, email still flows if the domain handles mail, and forms and logins work for real users, not just for you.
Step 6: Raise the TTL back up
Once everything is confirmed stable, raise the TTL on your records back to a normal value like 3600 or 86400 seconds. Low TTLs mean more frequent DNS lookups, so there is no reason to leave them at five minutes long term. Then, after a week of clean operation, you can safely decommission the old server.
A real scenario
You are moving a small business site to a faster host. Two days ahead, you drop the A record TTL to 300 seconds. You copy the site to the new server and, using your hosts file, browse the live domain pointed at the new IP. You catch a broken contact form, fix it, and retest, all invisible to customers. When it is perfect, you change the A record. Five minutes later, everyone is on the new server, the form works, and not a single visitor saw an error. You keep the old host for a week, then shut it down.
Frequently asked questions
Why lower the TTL before migrating?
TTL controls how long providers cache your old DNS record. Lowering it ahead of time means your switch propagates in minutes instead of up to a day, which shrinks the risky window to almost nothing.
What does editing the hosts file actually do?
It overrides DNS for your computer only. You can point your domain at the new server and test it as a real visitor before changing anything public, so mistakes stay private.
How long should I keep the old server running?
At least several days, ideally a week. Cached records and slow-to-update visitors keep hitting the old server for a while, and you want them to find a working site until everyone has moved.
Do I need to migrate email separately from the website?
Often yes. Email uses MX records, which are separate from the A record that points your website. Plan and verify the email move on its own so a website switch never disrupts your inboxes.
How do I confirm the migration finished propagating?
Query your domain from multiple regions and public resolvers and confirm they all return the new server's address. Once they agree, propagation is complete.