Every migration horror story has the same middle part: someone changed DNS first and then started copying. Downtime during a move is almost never about the copy being slow. It's about doing the steps in the wrong order.
Here's the order that works, whether you're leaving another provider or moving between two of our plans.
1. Two days before: lower the TTL
Find the DNS records you'll change (usually A, AAAA and any CNAME pointing at them) and drop their TTL to 300 seconds. Then wait at least as long as the old TTL was. A record with a TTL of a day means some resolvers will keep serving the old address for a day after you change it, and nothing you do on the server can speed that up.
This is the step people skip, and it's the one that turns a five-minute switch into a day of half the users seeing the old server.
2. Make an inventory of the old server
You're going to rebuild this box somewhere else, so write down what it actually does. Not what you remember it doing. What it does:
ss -tlnp # what is listening, and which process
crontab -l; ls /etc/cron.d # scheduled jobs
systemctl list-timers --all # the scheduled jobs people forget
systemctl list-units --type=service --state=running
Add to the list: the TLS certificates and how they renew, environment files with secrets, firewall rules, users and their SSH keys, the database and its size, and anything that talks to the server by IP address. That last group is the sneaky one: a partner's allowlist, a payment provider's webhook settings, a monitoring check.
3. Build the new server next to the old one
Order the new server and leave the old one alone. Pick a plan from the VPS list with the same or more disk than you use now, not than you were sold. If the old box receives any inbound traffic at all (a website, webhooks, an API), the new one needs its own IPv4. A NAT plan only accepts inbound connections on its SSH port, and what one forwarded port can and can't do explains why that matters.
Connect, install the same packages, recreate the users and the firewall. The connection guide covers keys and first login.
4. Sync the files twice
The first sync copies everything while the old server keeps working. It can take hours; that's fine.
rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/
--numeric-ids keeps file ownership by number, which avoids the classic "everything belongs to the wrong user" surprise when the two systems created users in a different order. If you've never used rsync over SSH, transferring files to a VPS walks through it.
The second sync, right before the switch, copies only what changed since the first one. It usually takes seconds.
5. Move the database deliberately
Files are easy. A database that takes writes is the one part where "zero downtime" needs either a short compromise or more work.
The simple way: dump and restore once for testing, then at switch time stop writes for a minute (put the app in read-only mode or stop it), take a fresh dump, restore it on the new server and start the app there. For most small projects that's a pause of a minute or two, announced in advance.
The no-pause way: set up replication from the old database to the new one, let it catch up, then promote the new one at switch time. It's more setup, and worth it when even a minute of lost writes is unacceptable.
6. Test the new server before anyone else sees it
DNS still points at the old server, so you can test the new one in private. Send a request for your real domain to the new address:
curl --resolve example.com:443:203.0.113.10 https://example.com/health
If the certificate isn't there yet, test over HTTP the same way, or add a temporary line to your hosts file and click through the site in a browser. Check logins, uploads, background jobs and outgoing email. This is the cheapest moment to find a missing PHP extension.
7. Switch, and keep the old server running
Do the final file sync and database step, then change the DNS records. With a 300-second TTL most traffic moves within minutes. Watch the old server's access log: it will keep getting a trickle of requests from resolvers and clients that ignore TTL. Leave it running, unchanged, for a few days. Then update the things that point at the old IP: partner allowlists, webhook URLs, and for mail the reverse DNS of the new address (on our dedicated-IP plans you set it yourself, see reverse DNS) and your SPF record.
What breaks most often
In rough order of how often we see it: a systemd timer nobody listed, a config file with the old IP hard-coded, files owned by the wrong user, a firewall that blocks the app's own port, a certificate that renews on the old server but not the new one, and mail landing in spam because the new address has no reverse DNS yet.
Where this checklist doesn't fit
A busy database with constant writes and no tolerance for a pause needs proper replication and a rehearsal, not a blog checklist. Windows servers move with different tools than rsync. And if the move is really about size, read this first: plans here grow in place. Moving to a bigger plan of the same network type adds vCPU, RAM and disk with one reboot, no migration at all. Only shrinking needs a new server. If you're moving because you're not sure the box is big enough, when you actually need 64 GB of RAM may save you the trip, and VPS vs shared hosting vs dedicated vs cloud helps if you're unsure a VPS is the right home at all.
Comments
No comments yet. Be the first.