Migrate without downtime by lowering DNS TTL to 300 seconds 48 hours ahead, building and verifying the new server privately, issuing TLS certificates via a DNS challenge before cutover, diffing response codes across both origins, then switching DNS and leaving the old host running for 72 hours.
Key takeaways
- Lower the TTL first, and early. Changing it on the day of the move accomplishes nothing — resolvers already cached the old value.
- Issue TLS before DNS moves, using a DNS-01 challenge. HTTP-01 cannot succeed until traffic already points at the new server.
- Diff every URL's status code across both origins. This is what catches the ranking-killing 404s.
- Database last, files first. Files sync in advance; the final database dump belongs immediately before cutover.
- Keep the old host alive 72 hours. It is free insurance and your fastest rollback.
Why migrations lose rankings
Rankings drop after a migration when crawlers encounter errors, not because the site changed address. A page returning 500 during propagation, a URL that silently 404s on the new server, or a origin that got slower are the three causes. Each is preventable, and each is invisible unless you check for it deliberately.
Google recrawls a moved site fairly aggressively, which is usually a good thing — the new server gets evaluated quickly. It also means mistakes get discovered quickly. A missing redirect that would take weeks to matter on a static site can cost you positions within days during a migration window.
- TTL (Time To Live)
- The number of seconds a DNS record may be cached by resolvers before they must ask again. A 86,400-second TTL means some resolvers will keep sending visitors to your old server for a full day after you change the record — which is why lowering it in advance is the single most important preparatory step.
Two days before: lower the TTL
This is the step people skip, and it is the one that makes everything else possible. Set the TTL on your A and AAAA records to 300 seconds. Then wait — the change itself needs to propagate under the old TTL before it takes effect.
Build the new server, verify it privately
Provision the VPS and deploy the full application before touching DNS. Verify it over the raw IP address or a temporary hostname such as new.example.com. Point production DNS at nothing you have not already loaded in a browser yourself.
- Match the PHP, Node or Python version to the old host — version drift is a common source of post-migration 500s.
- Recreate cron jobs. Shared hosting control panels hide these, and they are routinely forgotten.
- Check file permissions and ownership after transfer, particularly for upload directories.
- Confirm outbound mail works, or configure a relay. Many VPS providers block port 25 by default.
Issue TLS certificates before cutover, not after
Use a DNS-01 ACME challenge to obtain certificates while traffic still flows to the old host. An HTTP-01 challenge requires the certificate authority to reach your domain at the new server, which cannot happen until DNS already points there — guaranteeing a window where visitors see certificate warnings.
This is the most common cause of a visible outage during otherwise careful migrations. The server works, the files are right, and every visitor gets a browser security warning for ten minutes while certbot runs. A DNS-01 challenge removes the window entirely.
Diff response codes across both origins
Pull your URL list from the sitemap, server logs, or Search Console, then request every one against both origins and compare. You are looking for URLs that answer 200 on the old host and anything else on the new one.
| Old host | New host | Cause | Blocks cutover? |
|---|---|---|---|
| 200 | 404 | Missing file, or rewrite rules not ported | Yes |
| 200 | 500 | Runtime version mismatch or missing extension | Yes |
| 301 | 200 | Redirect rule lost in translation | Usually |
| 200 | 200, slower | Under-provisioned instance or cold cache | Investigate |
| 404 | 404 | Already broken before the move | No |
Cutover: data last, then DNS
- Sync files with rsync once, days ahead. They change slowly.
- Put the old site into maintenance or read-only mode if it accepts writes.
- Run a final rsync for anything changed since, then dump and import the database.
- Update the A record to the new IP address.
- Watch both servers' access logs. Traffic should visibly shift within minutes at a 300-second TTL.
The read-only window exists because any write accepted by the old server after your final database dump is lost. For a content site that window is irrelevant. For anything taking orders or comments, it is the whole reason to schedule the migration at your lowest-traffic hour.
After: the 72-hour rule
Leave the old server running and serving for at least 72 hours after cutover. Resolvers regularly ignore stated TTLs, some crawlers cache DNS independently, and corporate networks can hold records far longer than they should. The old origin is also the fastest rollback available if a problem surfaces late.
- Monitor 404 and 500 rates on the new server for a week, not a day.
- Check Search Console's crawl stats for a spike in errors or a drop in crawl rate.
- Compare response times against your pre-migration baseline — a slower origin is a slow-acting ranking problem.
- Raise the TTL back to 3600 seconds or higher once you are confident, to reduce resolver load.
The short version
A migration is a sequencing problem, not a systems-administration problem. Lower the TTL early, verify privately, issue TLS ahead of the switch, diff every URL, move data last, and leave the old host running. Do those six things in that order and downtime is measured in seconds rather than hours.