Migrate a VPS without downtime

The phrase is used loosely enough to be useless. Pin it down before you plan anything, because the definition you choose changes the amount of work by an order of magnitude.

Zero downtime properly means: no client request fails and no write is lost, at any point, for the whole migration. It does not mean nothing changes — the IP changes, TLS sessions break, long-lived WebSockets reconnect, in-flight SSH sessions die. Those are not outages; they are events a correctly written client survives.

What you actually need depends on the service:

• Static sites and read-only apps. Trivially zero-downtime. Two copies can serve simultaneously for hours with no consequence, because neither of them writes anything.
• Anything with a single database. The hard case, and the one this guide is built around. Two copies must never both accept writes, so there is a moment — measured in seconds if you plan it — where writes must stop everywhere.
• Mail. Genuinely forgiving. SMTP retries for days by design, so a queued message is delayed rather than lost. The risk with mail is not the migration window; it is the new IP, covered further down and in the mail server use case.
• Persistent connections — VPN, game servers, Tor. There is no seamless answer; the tunnel or the session ends and restarts elsewhere. A WireGuard endpoint reconnects on its own once the client’s DNS resolves to the new address, which is a good argument for pointing peers at a hostname rather than an IP.

Write the answer down before you start. “No failed HTTP request; up to 90 seconds where writes are rejected with a 503; mail may be delayed by up to 10 minutes” is a specification you can verify afterwards. “No downtime” is not.

Every server accumulates things nobody documented. The cron job someone added over SSH in 2024. The firewall rule that lets a payment provider’s webhook in. The certificate that renews from a path outside the web root. You will find all of them during the migration whether you look for them first or not; looking first is cheaper.

Run this on the old machine and keep the output somewhere you can read during the cutover:

systemctl list-unit-files --state=enabled --no-pager   # what starts at boot
ss -tulpnH | awk '{print $1, $5, $7}' | sort -u         # what listens, and which process
crontab -l; ls -la /etc/cron.d/ /etc/cron.*/            # scheduled work
systemctl list-timers --all --no-pager                  # systemd timers people forget
dpkg --get-selections | grep -v deinstall > pkgs.txt     # or rpm -qa
ls -la /etc/letsencrypt/live/ 2>/dev/null               # certificates and their paths
ip route; ip -6 route; nft list ruleset 2>/dev/null     # routing and firewall
getent passwd | awk -F: '$3>=1000'                      # real users and their homes
du -sh /var/lib/* /srv/* /home/* 2>/dev/null | sort -h  # where the data actually is

Then add the four things no command will tell you:

• Every DNS record that points at this server, including the ones you forgot: a bare A, a www, an MX, an SPF record with the IP in it, a _dmarc, a subdomain for a staging box, and any AAAA. Export the whole zone.
• Every third party that has your IP written down. API allowlists, database firewalls, partner VPNs, payment webhooks, an SMTP relay that only accepts your address. These break silently and often hours later. This is the single most common post-migration surprise.
• Every credential the machine holds, and where it came from — because you are about to decide which ones to rotate rather than copy.
• The rollback trigger. Which specific observation makes you abort and point DNS back? Decide now, while calm.

Freeze deployments for the duration. A migration is hard enough without a colleague pushing a schema change into the middle of it.

There are only three approaches, and providers who sell “free migration” are simply doing one of them for you.

1. Block-level clone. dd the whole disk from the old machine’s rescue mode into the new one’s. It is exact, it is the only method that preserves a LUKS container without re-encrypting, and across providers it is usually a mistake. A disk image carries the old host’s bootloader configuration, its network-interface naming, its virtio driver set, its cloud-init datasource and often a kernel built for its hypervisor. It boots into a black console on the new host and you debug it over a VNC session. Reserve it for moving a disk you cannot rebuild — an encrypted volume, or an appliance you have no install media for — and expect to fix the boot path by hand from rescue mode afterwards.

2. File-level copy onto a fresh OS. Install the same distribution and release on the new server, then rsync the data and the configuration you actually chose — /etc selectively, /srv, /var/lib, /home — and let the new machine keep its own kernel, initramfs, network config and identity. This is the right default. It is fast, it is resumable, and it leaves behind exactly the host-specific cruft you do not want.

3. Rebuild from configuration. If the server is already described by Ansible, a Dockerfile or a Nix expression, deploy that onto the new machine and copy only state. This is the cleanest of the three and the fastest to verify, because the target is reproducible rather than inherited. It is also the only one where you find out that your configuration management has drifted from reality — which is worth knowing on a Tuesday afternoon rather than during an incident.

In practice most migrations are method 2 with a bit of 3: rebuild the services, copy the state. The rest of this guide assumes that.

This is the section people skip and then regret. Your migration’s risky window is not how long the copy takes — it is how long the internet keeps sending traffic to the old IP after you change the record. That number is set by the TTL that was already published, and you cannot shorten it retroactively.

If your A record has a 3600-second TTL, a resolver that fetched it one second before your change will keep answering with the old address for another hour. If it is 86400 — a default at more registrars than you would hope — that is a day.

So, in order:

• T− 48 h. Lower the TTL on every record that will change to 300. You must do this at least one full old-TTL ahead, so that every cached copy of the old, long TTL has expired before the move.
• T− 24 h. Verify against the authoritative nameserver, not your local resolver, which may be lying to you from cache:
  dig +noall +answer @ns1.example-dns.net example.com A. The TTL in that answer is what you published; dig example.com A against your ISP shows what it has cached.
• Also lower the negative-caching TTL if you will be adding records: it is the last field of the SOA, not the record TTL, and it governs how long a resolver remembers that a name did not exist.
• Leave the NS records alone. Changing nameservers at the registrar is a slower, separate operation governed by the TLD’s glue TTL, typically 24–48 hours. Never combine a nameserver change with a server migration; do one, verify, then the other.

Raise the TTL back to something sane — 3600 or more — about a week after the migration. A permanent 300-second TTL means every resolver on earth re-queries your zone twenty times more often than it needs to, and it makes your DNS provider a much sharper single point of failure.

If your domain is registered somewhere you would rather it were not, do the registrar move as its own project, well before or well after this one. The reasoning is in the mistakes guide.

rsync copies files. A running database is not a set of files; it is a set of files plus everything the engine is currently holding in memory and in a write-ahead log. Copy the directory of a live PostgreSQL or MySQL instance and you get a snapshot that is internally inconsistent in a way that may not surface for weeks. It is the classic way to migrate successfully and lose data anyway.

Three correct options, in ascending order of effort:

Dump and delta. Take a consistent logical dump while the server runs — mysqldump --single-transaction --routines --triggers on InnoDB, or pg_dump -Fc — load it on the new machine, and then, at cutover, stop writes and apply the difference. For a small database, skip the delta: freeze, dump, load, done in under a minute.

# PostgreSQL, compressed custom format, streamed straight to the new host
pg_dump -Fc -Z6 appdb | ssh -C new-host 'pg_restore -d appdb --clean --if-exists'

# MySQL/MariaDB, consistent snapshot of an InnoDB database
mysqldump --single-transaction --quick --routines --triggers \
  --master-data=2 appdb | ssh new-host 'mysql appdb'

Replication. Configure the new machine as a replica days in advance, let it catch up, and at cutover simply stop writes, wait for the replica to reach zero lag, and promote it. This is the only genuinely zero-freeze option, and it is worth the setup for anything where a 30-second write freeze is unacceptable. --master-data=2 above records the binlog coordinates you need to start replicating from that dump.

Filesystem-consistent copy. If the database is stopped, its files are just files. For a small service, stopping MySQL for 40 seconds and rsyncing /var/lib/mysql is legitimate, simple and safe — as long as it really is stopped, and you check that it is.

The same reasoning applies to anything else with in-memory state: flush Redis with SAVE and copy the RDB rather than copying it live; drain job queues before the freeze rather than copying them mid-flight; stop Postfix and let the queue empty, or move /var/spool/postfix with the service down.

Here is the whole trick, and it is the reason a migration can be genuinely zero-downtime without replication, floating IPs or anything exotic.

The problem: when you change DNS, some clients move immediately and some keep using the old IP until their cache expires. If both machines are live and writable during that window, you have two databases diverging — split brain, and the losing half’s writes are gone.

The solution: never let the old machine serve stale data — make it a proxy instead. The order matters, and it is this:

1. Stop the application on the old server. It is now serving nothing.
2. Run the final delta — rsync of changed files, database dump or replica promotion. This is the freeze, and it should be seconds.
3. Start the application on the new server. It is now the only writable copy in existence.
4. On the old server, replace the application with a reverse proxy pointing at the new server’s IP.
5. Only now change the DNS record.

From step 4 onward, every client is served by the new machine — the ones that resolved the new address directly, and the ones still hitting the old IP through the proxy. Nobody sees stale content, nobody writes to the wrong database, and the DNS TTL stops being a source of risk. It becomes a matter of when you can retire the proxy, not whether people are getting the right answer.

The proxy stanza is one block:

server {
  listen 80; listen 443 ssl;
  server_name example.com www.example.com;
  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
  location / {
    proxy_pass https://198.51.100.10;      # the NEW server, by IP
    proxy_set_header Host              $host;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_ssl_server_name on;
  }
}

Two details that catch people out. Keep the old certificate valid on the proxy — it is still terminating TLS for the clients that reach it. And make sure your application reads the client address from X-Forwarded-For, or every visitor arriving via the proxy will be logged and rate-limited as the old server’s IP. If you run a site whose logs you care about, that distinction matters.

Retire the proxy once traffic to the old IP has stopped — typically a few hours after a 300-second TTL, occasionally a day for badly behaved clients with hard-coded addresses. The access log on the old machine tells you exactly when.

A file-level copy is a chance to leave things behind on purpose. Some of these are correctness problems; some are privacy problems; all of them are easier to handle now than later.

• SSH host keys (/etc/ssh/ssh_host_*). Copying them means the new machine presents the old machine’s fingerprint. Convenient — no client warning — and exactly wrong: it is a durable identifier linking the two servers, and it silently defeats the check that would have told you something changed. Let the new host generate its own and update your known_hosts.
• /etc/machine-id. A globally unique identifier that systemd, D-Bus and a surprising amount of telemetry key on. It should differ. Copying it can also confuse systemd-journald into refusing to read its own logs.
• Provider agents and cloud-init state. Monitoring daemons, metadata agents and vendor apt repositories from the old host will keep trying to phone an endpoint that no longer knows them, and occasionally reconfigure your network from a datasource that is not there. Remove them; do not migrate them.
• Anything under /etc/ you did not deliberately choose. fstab, resolv.conf, hostname, hosts, network interface definitions and udev rules are host-specific. Copying fstab with the old machine’s UUIDs is the single fastest way to make a server unbootable.
• Credentials the old provider could have read. If the old host held your disk unencrypted — and unless you set up full-disk encryption, it did — then every API token, database password, TLS private key and SSH private key on that disk has been readable by someone with hypervisor access for as long as it was there. Migrating away is the natural moment to rotate all of them. Reissuing a certificate costs nothing; a leaked key costs a great deal.
• Identity residue. Shell history, ~/.gitconfig, ~/.ssh/config with old hostnames, backup scripts containing the old provider’s account name, and log files full of your home IP. If part of the reason you are moving is to stop your infrastructure being attached to a verified identity, copying those forward undoes the exercise. A no-KYC server that is full of the previous host’s account references is no-KYC only in the billing sense.

An rsync that excludes the right things is short enough to read:

rsync -aHAX --numeric-ids --info=progress2 \
  --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run \
  --exclude=/tmp --exclude=/mnt --exclude=/media --exclude=/lost+found \
  --exclude=/boot --exclude=/etc/fstab --exclude=/etc/machine-id \
  --exclude='/etc/ssh/ssh_host_*' --exclude=/etc/hostname \
  --exclude=/etc/resolv.conf --exclude=/etc/network \
  --exclude=/var/lib/mysql --exclude=/var/lib/postgresql \
  /srv /home /var/www new-host:/

-aHAX --numeric-ids preserves hard links, ACLs and extended attributes, and keeps numeric ownership rather than remapping it through the new machine’s user database — which matters the moment the two systems disagree about which UID is www-data.

You are not only moving files. You are moving to an address with no history, and a handful of systems in the world care about that far more than they care about your content.

Mail is the sharp edge. A brand-new IP has no sending reputation, and several large receivers treat that as mildly suspicious for the first few weeks. Before you send anything from it: set reverse DNS to a hostname that forward-resolves back to the same address, publish SPF and DKIM for the new IP, check it against the major blocklists, and ramp volume gradually rather than moving a mailing list on day one. If the old IP was warmed, that warmth does not transfer. On our side rDNS is yours to set from Server → Network → Reverse DNS and propagates in about five minutes, with no requirement that you already control the forward record — set it before your first outbound message, not after.

Allowlists are the silent one. Every partner API, managed database, corporate VPN and payment webhook that has your old IP written into a rule will keep working for exactly as long as the old server answers, and then stop. Grep your inventory for these and get the new address registered before the cutover, in parallel with the old one where the other side allows two entries.

Check the address before you commit to it. A recycled IPv4 address occasionally arrives with someone else’s history attached — an old blocklist entry, a geolocation database that still places it in the wrong country, a firewall rule at a service you use. Ten minutes of checking on day one is far cheaper than discovering it during the cutover. We hold destroyed addresses for a 24-hour cooldown before returning them to the pool precisely so that a freshly allocated address is not one that was in someone’s DNS a minute ago, but no provider can erase an address’s reputation elsewhere on the internet.

Geography changes too. If you are moving jurisdiction as well as host — which, for most people arriving here, is the point — remember that latency, geo-restricted APIs and the legal analysis all move with the machine. The jurisdiction pages cover the legal side; the practical side is that you should measure latency from where your users are before you pick a region, not after.

The whole point of the dual-run cutover is that you can test the new server, in production, under its real hostname, before a single visitor is sent to it. Use that.

curl --resolve forces a hostname to a specific IP for one request, TLS and virtual hosts included, without touching DNS:

curl -sS --resolve example.com:443:198.51.100.10 https://example.com/health -i | head -20
curl -sS --resolve example.com:443:198.51.100.10 https://example.com/ -o /dev/null -w '%{http_code} %{time_total}s\n'

For clicking around in a browser, add a line to your local /etc/hosts pointing the hostname at the new IP — and remember to remove it afterwards, or you will spend an afternoon convinced DNS is broken when it is only your laptop.

Verify at minimum: the TLS chain serves the right certificate for every hostname, including the ones you forgot; the application connects to its database as the new machine and not through a leftover hostname pointing home; cron jobs and timers are enabled and their next run is correct; file ownership survived the copy; log rotation works; and the service comes back after a reboot you deliberately trigger. That last one catches more problems than everything else combined, because it is the difference between “it runs” and “it starts”.

Rollback. Because the old server was turned into a proxy rather than destroyed, rolling back is: stop the proxy, start the old application, point DNS back. That is genuinely fast — but only if the database has not diverged. Once the new machine has taken writes, rolling back means losing them or merging by hand, so the honest rule is: the window in which rollback is free ends the moment the first write lands on the new server. After that, roll forward and fix.

Keep the old machine, powered on and read-only, for a week. It costs a few dollars. It is the cheapest insurance in this entire procedure.

When the access log on the old machine has been quiet for a day, the migration is finished and the last job begins.

In order: remove the DNS records that still point at the old address; revoke the API tokens, SSH keys and application credentials that lived there, particularly any you decided to copy rather than rotate; take a final image of the disk if you might want it, because there is no undo; then destroy the server rather than leaving it to expire quietly. On our platform destruction overwrites the disk with zeros and closes the billing entry immediately; the IPv4 goes back to the pool after a 24-hour cooldown and the routed IPv6 /64 returns at once. Other providers behave differently, and “the account lapsed” is not the same as “the data is gone”.

Now the part that is worth being clear-eyed about: what you cannot delete. Whatever you did on the old server, that provider still holds its own records of the relationship — the account, the payment instrument, the identity documents if it asked for them, the IP addresses you connected from, and the invoices it is legally required to keep for years in most jurisdictions. Destroying the server ends the data on the disk. It does not retract the KYC file, and no support ticket will.

That asymmetry is the honest reason many people migrate in the first place, and it is worth stating the limit as plainly as the benefit: moving to a host that never asked who you are stops the collection going forward. It does not undo what a previous host already collected. If that matters to you, the useful conclusion is that the sooner you stop adding to the file, the smaller it stays — and that the next migration is easier to keep clean than this one was. What we hold is documented in the privacy notice, and what we do when someone comes asking is documented in the legal-process guide and the canary.