How to migrate a VPS with zero downtime: the method we have been applying for years

Why this matters

Any business that lives online has a recurring nightmare: that the website goes down right when a campaign starts, on a long weekend or the day the big customer decides to come in. And migrating the server is one of the moments where that risk concentrates the most.

The good news is that most migrations can be done without anyone noticing. The bad news is that they require method, not improvisation.

The four-phase method

1. Audit of the current environment

Before touching anything, we list:

• Exact versions of every piece of software (PHP, MySQL, Nginx/Apache, Node.js, etc.).
• System dependencies (PHP extensions, native libraries, APT packages).
• External services calling the server (third-party cron jobs, webhooks, integrations).
• Volume of data on disk and in the database.
• Firewall rules, SSL certificates and current DNS.

Without this map, any migration is a lottery.

2. Parallel replication

We build the new server in parallel, without touching production. We replicate the data:

• Files via rsync -avz --delete, scheduling several passes until the delta is minimal.
• Database with a full dump and, on large databases, binlog replication so the destination is almost up to date.

We test the new website on an internal domain or a tweaked /etc/hosts. We validate every flow: user signup, forms, payments where applicable, external integrations.

3. Cutover plan (with rollback)

This is the secret. Before the cutover:

• We drop the DNS TTL to 5 minutes 24 hours in advance so propagation is almost immediate.
• We write a documented rollback plan: what changes, in what order, and how to undo it if anything goes wrong.
• We notify the customer of the exact moment and the low-risk window.

On cutover day, we run:

1. A final rsync pass with the site in read-only mode (just a few minutes).
2. DNS switch to the new server.
3. Immediate verification: the site responds, the form works, the SSL certificate is valid.

If everything is fine, we move on. If anything fails, we revert the DNS and the website continues working as before on the old server, without anyone noticing.

4. Post-cutover validation

24 hours watching logs, uptime monitoring and metrics. Any odd behaviour is diagnosed live. When we have several green days, we shut down the old server (not before).

Common mistakes to avoid

• Migrating without prior replication: moving live is a coin flip. Always clone first, test, then cut over.
• Forgetting cron jobs: cron jobs on the old server keep firing if you don’t disable them, and can produce duplicates or repeat charges.
• Not testing real forms: sending a test email from the new server isn’t the same as receiving it on the customer’s account.
• Not lowering TTL early enough: if DNS takes 24 hours to propagate, half of the traffic goes to the old site for that long.

How long it usually takes

A standard small-VPS migration is done in 2–3 weeks: one for audit and replication, one for testing, one for cutover and support. Don’t aim to do it over a weekend, except for trivial cases.

Wrap-up

Migrating a VPS without downtime isn’t magic: it’s discipline. The hardest part isn’t technical, it’s the upfront planning. On cutover day you only execute what has already been validated.

If you have a pending migration and would rather have a team with real scars handle it, drop us a line and we’ll tell you how we’d approach yours.