Migrating a VPS Without Downtime — Replication, Cutover, Rollback

Run both servers, replicate forward, flip writes at the data layer, keep the rollback path. KVM VPS from $5.49 list, $3.00 annual-eff. No KYC, crypto only.

Published 2026-08-30 · Updated 2026-10-10 · FYRHost Editorial · 18 min read

Downtime is a cutover problem, not a copy problem

Budget a weekend for a migration and you will spend that weekend planning the copy — the one part that never needed planning. The instinct says a move means stopping the old machine, imaging its disk, booting the new one, and hoping the stack comes up. The real constraint is narrower. Keep both boxes running side by side, let data flow one way until the new machine trails by two or three seconds, and the only customer-visible outage left is the gap between the last replication tick and the write flip.

The pattern works because replication is continuous and one-directional. Files travel with rsync -aAX over SSH, databases stream through their native replication channels, and lag is a number you can read on demand — pg_stat_replication shows it in bytes and seconds for PostgreSQL deployments. While that number stays small, the new box is a live mirror, not a museum piece, and you can restart it, reconfigure it, or rebuild it from scratch without a single visitor noticing that anything is happening at all.

Writes flip at the data layer, not by moving a disk. That layer is whichever switch you control most narrowly: a DNS record, a database promotion, or an application configuration flag that re-points the app at a new database host. Choose one switch, rehearse throwing it, and the cutover becomes a two-minute operation — systemctl stop app on the old side, one config change, one start on the new side — rather than a weekend of dread and cold pizza.

The typical mistake inverts all of this: people migrate by disk image. They shut the old server down, copy a snapshot of the filesystem, boot it elsewhere, and then spend the night discovering what the image never captured — a kernel module the new hypervisor lacks, a hard-coded IP in /etc/network/interfaces, a cron job that emailed logs to a mailbox nobody checks. Every one of those discoveries is cheap during a parallel run and catastrophic during a copy-the-disk cutover.

Which is why the rest of this guide keeps returning to one ordering — build and feed the copy while the old machine still serves, flip the write path in seconds, and hold the old machine until rollback stops being plausible, because every step you can rehearse during the parallel run is a step that cannot surprise you during the cutover itself.

Replicate forward before you touch anything else

The instinct says start at DNS; the right start is a target that already receives data. Stand up the destination box in the location you want, apply the same hardening baseline — keys, firewall rules, unattended upgrades — before any data lands, and treat the fresh machine as a clean rebuild rather than a clone. A migration is the one moment you get a tidy system for free, and most people waste it by faithfully copying years of clutter they should have deleted.

Size that target from evidence, not vibes. Provision it as a Scout at $3.00 on the annual term — 1 vCPU, 2 GB ECC, 40 GB NVMe — and add a tier of headroom if your old box has been swapping. The virtualisation type matters here too: pick KVM so the new machine owns its kernel and swap, a distinction the virtualisation guide covers in depth, because container-based targets reintroduce the exact variance you are trying to escape.

Files move first. One full pass of rsync -aAX over SSH preserves permissions, extended attributes, and ACLs while excluding the virtual filesystems — /proc, /sys, /dev — that only exist on a running kernel. Follow with delta passes using --delete so renames and removals propagate, and read the rsync documentation once before you script it; the flag alphabet punishes guessing more than any other tool in the box.

Databases must never ride the file path. Copy live InnoDB or PostgreSQL data files with rsync while the engine writes and you will produce a copy that boots cleanly, answers reads for hours, and corrupts on the first real transaction. Use the native channels instead — pg_basebackup -R -X stream seeds a streaming replica per the pg_basebackup manual, and lag then shows in pg_stat_replication as a number you can watch fall to single-digit seconds. The streaming replication chapter is the canonical reference for the whole setup.

The failure mode here is seductive because it works — the rsynced database directory usually starts, serves, and passes a homepage check, which is exactly why the corruption waits for the first burst of writes to expose it. Treat replication lag in seconds as the only acceptance test, because a copy that cannot keep up forward is a copy that will diverge the moment you need it most, and divergence at cutover is the one bug no rollback survives gracefully.

The data layer decides when the switch happens

Cutover is not the art of moving a server; it is the art of re-pointing who accepts writes, and you get three switches for that job — DNS, database promotion, or an application flag. Pick the narrowest one you actually control. If the app already reads its database host from a config value, that flag beats DNS, because it moves one process instead of asking every recursive resolver on the internet to forget an address on your behalf.

The database route is the most deterministic. Set the old primary read-only with default_transaction_read_only = on, wait for replication lag to drain to zero bytes, promote the replica with SELECT pg_promote(), and re-point the application. From last write on the old box to first write on the new one, the window is seconds, and nothing about the switch depends on a client cache you cannot see or a resolver you cannot call.

The DNS route fits stateless stacks: several web heads, no local state, one load-bearing record. Drop the record TTL to 60–300 seconds the day before, then flip the A record at cutover and let recursive resolvers converge within minutes. Verify with dig example.com A against two or three public resolvers, because +noall +answer output shows you the TTL each cache still believes, which is the only propagation truth that exists.

The classic failure is split-brain, and it arrives exactly one clever shortcut later: you flip DNS first and stop the old writes never. Clients holding the cached old address keep writing to the old box while freshly-resolved clients write to the new one, and the data layer happily accepts both — divergent histories that no automatic process reconciles. Always pause writes on the old side before enabling them on the new, even if that costs thirty seconds of 5xx responses.

Keep both switches in the same runbook and the choice becomes situational rather than ideological — database promotion when state concentrates behind one engine, DNS when it spreads across disposable heads, and an application flag whenever the code already supports one, because the cheapest cutover of all is the switch the developers built in advance and left waiting for you.

Drop record TTLs a day ahead, not an hour ahead

A record TTL exists for the day you change the record, not for everyday queries, and treating it as an emergency knob an hour before cutover mostly measures your own impatience. Caches worldwide hold the old answer for the old value; lowering the authoritative number does not reach into those caches and subtract. The record change is instant, but the internet's belief about the record decays on a schedule set weeks earlier.

The mechanism is ordinary caching: recursive resolvers store your answer and reuse it until the TTL expires, then re-query. Some large resolvers also enforce their own minimums, holding answers for hundreds of seconds regardless of a 60-second value you publish, and negative answers follow the SOA minimum under the rules described in RFC 2308. So check what you are actually serving — dig example.com A showing 3600 in the answer tells you the work ahead.

Do the arithmetic in the open. A record at 3600 seconds means up to an hour of split traffic after the flip; at 60, the same convergence finishes in a minute or two for well-behaved resolvers. A day before cutover, lower every load-bearing record to 60–300, bump the zone serial to something like 2026101001 so secondaries transfer, and confirm the SOA reflects the change before you touch anything else.

The typical mistake is lowering TTL during the outage instead of before it, then reading the slow convergence as a provider problem. The second mistake is forgetting the records beyond www: the API subdomain, the mail host, the SPF include, each with its own cached value and its own surprise. Enumerate every record that mentions the old address and shorten all of them in the same sitting, because the one you skip is the one clients still hit at 2 a.m.

Handled a day early, TTL becomes a detail rather than a gamble — the caches drain on your schedule, the flip lands while the answer is already short-lived, and the resolver behaviour you verified beforehand is the same behaviour you diagnose afterwards, which is exactly the kind of boring predictability a cutover plan should be manufacturing on purpose.

Smoke tests decide the cutover, not the dashboard

A green status tile proves one thing: the process is running. The cutover is finished when named critical paths answer — login, checkout, the API auth endpoint, a transactional mail send — and the way to make that a two-minute ritual instead of an improvisation is to rehearse the test script during the parallel run, so cutover night just re-runs something you have already executed twice.

Build the script around the things disk copies and control panels never carry over cleanly. Confirm the TLS chain moved and renewal works with certbot renew --dry-run; diff the job list with crontab -l against the old box; check services are enabled for boot, not merely started, using systemctl is-enabled on each unit — the systemctl manual documents the distinction your future self will care about. The crontab(5) page explains why per-user jobs hide from a root-only inventory.

Keep the rehearsal honest with numbers. Fifteen named checks take about four minutes to run by hand; log each result into a file so the cutover run is a diff against a known-good baseline rather than a memory test. During a week of parallel running you can afford two full rehearsals plus one surprise drill at an inconvenient hour, which is precisely when forgotten dependencies — the nightly export, the backup hook, the mail relay credential — tend to introduce themselves.

The failure that repeats across every migration story is the same shape: the site works, the team celebrates, and at 03:00 the nightly job fails because a key in /etc was excluded from the sync, or outbound mail silently blackholes because SPF and rDNS still describe the old address. None of those appear on a dashboard; all of them appear in a rehearsed checklist, which is why the checklist exists.

Write the checks once, run them twice during the parallel window, and the cutover stops being a leap of faith — it becomes the third execution of a script with a track record, and the only new variable on the night is which of the fifteen lines fails first, a question you will already know how to answer because you have answered it before.

Rollback is a feature you build before day one

A migration without a budgeted rollback window is a bet, not a plan, and the premium on that insurance is embarrassingly small. Keep the old box alive for a full week after the flip and the worst case costs you one more billing cycle on a small plan; the alternative costs a restored-from-nothing scramble in front of the users who noticed first. Rollback is not pessimism — it is the difference between an incident and an outage.

The mechanics stay boring on purpose. With writes flipped at the data layer, going back is mostly reversing the switch: re-point the app or the record, pause new-side writes first to avoid split-brain, and accept that a few minutes of post-flip transactions may need manual reconciliation if replication was not running in reverse. Keep the old machine a Scout at $3.00 on the annual term and the insurance runs about $0.70 a week — cheaper than the pizza consumed while deciding whether you need it.

Before the box can ever be decommissioned, capture its final state. Snapshot before you touch anything — snapshots ride VPS and storage plans as a checkout add-on, and a pre-decommission snapshot converts a slow discovery into a restore. Export database dumps separately from the snapshot, because formats outlive platforms, and pull a copy of /etc plus the job schedules so the tombstone record of the old machine fits in a directory, not a filing cabinet.

The failure cuts both ways. Decommission the same afternoon and you have sawn off the branch you were standing on; let the old plan renew forever and you pay rent on a ghost until someone audits the invoices. Set the kill date at cutover, in the runbook, next to the rollback steps — a date you chose while calm beats a decision made during the first incident, when every option feels equally defensible.

Treated this way, rollback stops being the embarrassing appendix of the migration plan and becomes its spine — the reason you can move fast on cutover night is that going back is one rehearsed switch, one restore command, and one week of rental, which is a price you will never regret prepaying and always regret owing in an emergency.

Special cases: mail, certificates, and hardware-tied state

Three things refuse to follow the generic playbook, and each breaks in a specific, known way: mail, TLS automation, and anything licensed to hardware. You can plan for all three in an afternoon, or meet them one at a time during the first week on the new box, when every deviation reads as a migration failure instead of the known quirk it actually is.

Mail is the hardest because IPv4 cannot travel with you — addresses are allocated per network, so reputation stays behind. On the new IP, set rDNS with the provider, align SPF, DKIM, and DMARC records, and expect deliverability to dip for days while receivers re-learn the sender; big mailboxes throttle new addresses on principle. Migrate the mail queue early — flush postqueue -f or the equivalent before the flip — and watch bounce logs, not just inboxes, during the first 48 hours.

TLS is easier but still its own step. Either carry /etc/letsencrypt across intact, accounts and all, or reissue from scratch on the new box; either way, prove the renewal path with certbot renew --dry-run before cutover, because a certificate that cannot renew is a time bomb with a 30-day fuse. The Certbot documentation covers moving the lineage, and five minutes there beats a browser-padlock incident report later.

License servers sometimes bind to a MAC or a machine UUID, and this is where KVM quietly earns its keep: the NIC address is yours to set, with ip link set dev eth0 address 52:54:00:ab:cd:10, so a license that checks the first three octets can survive the move unchanged. Read the license terms first — some vendors reissue for free, some charge, and one or two will notice and lock, which you want to learn during the parallel run.

None of these are reasons to avoid migrating; they are reasons to schedule the awkward 10 percent deliberately — mail with a warm-up calendar, certificates with a proven renewal path, licenses with a vendor conversation already done — so the smooth 90 percent of the move is not judged by the three components that were always going to need their own week of attention.

What a no-KYC checkout changes about the timeline

The mechanical work of a migration is provider-independent; what changes with this catalog is the latency around the edges. Provisioning is measured in seconds rather than days — a VPS comes up about 60 seconds after credit lands, and dedicated metal within 2–4 hours — so the traditional first week of a migration plan, waiting for the destination to exist, simply disappears from the schedule.

Payment latency is the other scheduled wait, and the nineteen supported coins differ enough to matter: BTC settles after 2 confirmations in 10–60 minutes, XMR after 10 blocks, USDT on TRC-20 after 19 blocks in 1–3 minutes, XRP after 3 ledgers with no destination tag, DOGE after 3 blocks, BNB after 15, DASH and ADA after 3 each. Pick the rail for the timeline you want, fund the account, and the parallel run starts the same afternoon instead of the same fiscal quarter.

Identity is where the migration usually changes character. Signup is an inbox or a token plus a 12-character password, with no passport scan, and arrival traffic here mostly flows from mainstream clouds for exactly that reason — billing and jurisdiction, not benchmarks. Locations number 40 across four continents, with published premiums of +20% in Iceland and Norway, +35% in Switzerland, and +15% in Luxembourg, Cyprus, and Panama; abuse is handled under each facility's jurisdiction, and the AUP bans attacks, spam, and phishing outright.

The mistake runs in the opposite direction from the old one: people budget a week for onboarding at a KYC provider, then try to compress the data work into the same week. Invert it. Onboarding here costs minutes, so spend the saved time extending the parallel run — the token-only signup guide covers the credential side — because replication time, not provisioning time, is where migration reliability is actually manufactured.

Fast onboarding does not speed up the data; it removes the excuse for skipping the data work — the target can exist for days before cutover at trivial cost, which means the rehearsals, the TTL changes, and the rollback drill all become calendar items you control rather than delays someone else's sales process imposed on your timeline, and that control is the real upgrade.

The migration, in the order to run it

Hour zero: provision the target in the destination location and harden it before data arrives — keys, firewall, unattended upgrades, the rebuild script that documents the stack. Choose KVM so the new box owns its kernel, confirm the size against measured usage rather than hope, and record the choice in the runbook, because the target you build in the first hour is the machine you will debug in week one and the machine you will defend in the post-mortem you are quietly trying to make unnecessary.

Day one: start replication and watch it learn the workload. Files flow with rsync passes that preserve attributes and exclude virtual filesystems; databases seed through their native channels until pg_stat_replication reports lag in single-digit seconds; schedules for the nightly jobs get rebuilt from the old crontabs while everything is still reversible. Nothing on this day is irreversible, which is the entire point of the day — every command you run should be one you would be comfortable running twice.

Day before cutover: drop every load-bearing record to a 60–300 second TTL, re-run the fifteen-line smoke script end to end, and rehearse the switch itself once in daylight — pause writes, drain lag, promote or re-point, run the checks, roll back on purpose. A rollback you have deliberately performed is a tool; a rollback you have only read about is a rumor, and rumors make poor reading at 2 a.m. over a production database.

Cutover minute: pause writes on the old box, wait for lag to hit zero, throw the switch you rehearsed — database promotion, application flag, or the record flip — and run the same fifteen checks before announcing anything. Then watch logs rather than dashboards for the first hour, because logs show the errors users have not reported yet, and the first hour after a write flip is when forgotten dependencies traditionally introduce themselves with a cron-shaped chime.

Week one: hold the old machine as the rollback door, reverse the switch if the data demands it, and snapshot the old box before any decommissioning thought becomes a decommissioning act — the snapshot is the exit door, and it costs minutes to make. Set the kill date in the runbook at cutover time, and when it arrives, decommission without ceremony; the backup and restore guide explains what a proper final export looks like, and the VPN endpoint guide covers the proxy-in-front trick if any client truly cannot survive the address change that no provider can carry across networks.