How to Migrate a Live Site to a New VPS Provider Without Downtime

Migrating to a new VPS provider gets stressful when it's treated as "copy the files, point DNS, done." Done that way, you get a visible outage somewhere between minutes and hours long, exactly when DNS is mid-propagation and half your visitors are hitting the old server while the other half hit a half-configured new one. The fix isn't complicated, but it does require sequencing the steps correctly — the new server should be fully working before DNS ever changes.

Why you plan the cutover, not just the move

The core idea: build and fully verify the new server first, with the old one still live and untouched, then make the DNS switch the very last step. Everything up to that point should be reversible with zero risk to the live site, because the live site hasn't been touched yet.

Step 1: build the new server in parallel

Provision the new VPS and set it up exactly as described in our production-ready VPS checklist — OS updates, firewall, aaPanel, your application stack. Do this entirely independently of the old server; nothing here affects the live site.

Step 2: sync data without touching the old server yet

Copy your application code, then bring over the database with a fresh dump:

# on the old server
pg_dump -Fc mydb > mydb.dump

# transfer it (scp, rsync, or your object storage if you already back up there)
scp mydb.dump user@new-server:/tmp/

# on the new server
pg_restore -d mydb /tmp/mydb.dump

Sync uploaded files the same way — directly from old server to new, or via the object storage bucket if you're already using one per our single-VPS SaaS guide. The old server keeps serving live traffic throughout this entire step.

Step 3: do a dry run with a hosts-file edit

Before touching DNS, point your own computer at the new server temporarily by editing your local /etc/hosts file (or the Windows equivalent) to map your domain to the new server's IP. Browse the site as if you were a real visitor: log in, submit a form, check that uploaded images load. This catches configuration mistakes while the new server is still invisible to everyone but you.

Step 4: lower your DNS TTL in advance

A day or two before the cutover, lower your DNS record's TTL (time-to-live) to something short, like 300 seconds. This is the single biggest lever for making the cutover fast — a long TTL from before the change means some visitors' DNS resolvers keep the old answer cached for hours after you've switched. A short TTL means most of the internet picks up the change within minutes.

Step 5: the actual cutover

Do one final data sync (a last database dump and restore, to catch anything written since step 2), then update your DNS A record to point at the new server's IP. If you're on Cloudflare, this is the same DNS tab you'd use for any record change — and if the domain is proxied, Cloudflare's own edge starts routing to the new origin as soon as the record updates, without waiting on visitor-side DNS caches at all, which is one more reason a Cloudflare-proxied setup makes this kind of cutover smoother.

Step 6: keep the old server alive as a safety net

Don't cancel or destroy the old server immediately. Keep it running (and unchanged) for at least a few days after the cutover — if something surfaces that only shows up under real production load, you can point DNS back at it within minutes while you debug the new server calmly, rather than under pressure with no fallback.

Frequently asked questions

How much downtime is actually normal for this process?

Done this way, effectively none from the user's perspective — worst case, a handful of requests during the final data sync might not reflect a few seconds of last-minute writes, which is why doing that final sync right before the DNS change (not hours before) matters.

What about SSL certificates on the new server?

Issue a fresh Let's Encrypt certificate on the new server before the cutover, using the dry-run hosts-file trick from step 3 won't work for certificate issuance (Let's Encrypt validates against real DNS), so the certificate typically gets issued right after the DNS change — plan for a brief window where you may need to temporarily allow HTTP or accept a short SSL warning immediately after cutover, or use a DNS-01 challenge method that doesn't require the domain to already point at the new server.

Should I migrate the database and application at the same time, or separately?

Together, as one cutover — running the application against a stale database (or vice versa) for any length of time risks data inconsistency. The whole point of steps 1-4 is to make the final cutover in step 5 a single fast action rather than a drawn-out multi-stage process.