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.

Le corps de l'article est en anglais. L'interface, le catalogue et la caisse sont traduits.

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.