Migrating a VPS Without Downtime — Replication, Cutover, Rollback

Run both servers, replicate forward, switch writes at the data layer, keep the rollback path. Downtime shrinks to the final sync, not a weekend.

Published 2026-08-30 · Updated 2026-09-29 · NulNet Editorial

The pattern

The old and the new server run side by side while data flows one way: forward, continuously, until the new box trails by seconds. Reads and writes switch at the data layer — DNS, database promotion, or an application flag — not by moving a disk. Total customer-visible downtime compresses into the seconds between the last sync and the write flip. Everything else in a migration that hurts — the copy, the config drift, the surprise dependencies — happens while the old machine is still quietly serving.

Steps

1. Provision the target in the destination location and apply the same hardening baseline — keys, firewall, unattended upgrades — before any data lands.
2. Replicate without pause: rsync over SSH for files, native replication for databases, or application-level sync where the stack has one, until lag reads in seconds.
3. A day ahead, drop record TTLs to 60–300 seconds so caches expire quickly when the switch comes.
4. Cutover: pause writes on old → final sync → point writes at new → smoke-test the critical paths → let recursive resolvers converge.
5. Leave the old box alive through a rollback window and snapshot it before decommissioning; the snapshot is the exit door.

Where NulNet fits

The checkout makes parallel-run migrations cheap on both ends: order the target, sync, cut over, then keep or kill the source. Snapshots ride VPS and storage plans as a checkout add-on, so the pre-cutover state is one restore away. Billing stays crypto-only and identity-free on both sides of the move — which is the point for migrations from providers whose onboarding starts with a passport scan. Storage tiers from 1 TB NVMe ($30 list, $24 annual-eff) also work as the replication target itself.