Server migration with rsync, calmly

A server move is rarely a copy job, however much the tools suggest it. What separates a calm evening from a fire-drill night is not the copying but the preparation: the list of things that must move, the path they move on, and the point where the old server retires. rsync carries the transport in this picture, and this post shows the rest of the work around it.

The inventory before the first byte

The first work happens on the old server and consists of questions: which services run here? Which ports listen from outside? Which recurring jobs exist, and where do they write? Which accesses are configured, which secrets sit in which files? The answers land in a list the new server gets checked against. That list is the reason prepared moves stay calm: every point on it gets ticked later, and nothing gets discovered that was forgotten.

The invisible parts deserve particular attention: cron entries and timers, own scripts in directories nobody memorized, certificates and their expiry dates, and the configurations patched by hand over recent years that appear in no documentation. Precisely these leftovers otherwise show up as surprises on cutover evening.

The staged data march

The transport itself splits into two movements. The first runs while the old server is still in operation: a full initial pass of the data, allowed to take hours or nights without time pressure. The second happens shortly before the cutover and carries only what changed since. For small volumes that is minutes; for large systems it is the decisive shortening of the downtime.

The rsync options for this work are classic: --archive for the full transfer of permissions, timestamps and ownership, --delete with care for the passes where the target should follow the source, and an exclude list for everything that should not exist on the target anyway: virtual filesystems, socket files, temporary directories. That list belongs in the preparation, not in the moment; whoever improvises it will not find it again when something goes wrong.

The cutover point

The cutover is the only part of a move that tolerates pressure, and so it gets shrunk to minutes. Three preparations precede it: the lifetime of the DNS records was lowered in time so the pointer switch takes effect quickly; the last delta pass is planned through; and the checklist for the new server is ready. Then the sequence runs: stop the old services, pull the final deltas, run the checks, switch the pointers, start the new services.

A rollback plan belongs to the sequence even though it rarely gets used: the old server stays in place as long as the DNS windows of the switch can still reach it. When the new server shows an unexpected quirk in the first hour, the return is the fastest path instead of troubleshooting under pressure.

Verification afterwards

The move is done when the verification declares it done: the inventory lists get worked through, every service is addressed individually, the jobs are watched until the first full cycle completes, and the monitoring confirms it sees the new server and has released the old one. An observation window of days belongs to the transition, not the evening the pointer switched.

Where rsync ends

The honest limit concerns databases: a file copy of a running database is not a consistent state, and databases follow their own transport routes, whether a logical dump during the window or a replication method that builds the new state alongside the old. Mail systems and setups with many live connections deserve their own routes too. rsync carries files, configurations and everything that exists as a filesystem, and on most servers that is the lion's share.

What practice learned about the order

From several moves one small insight has held: the pressure sits almost never in the copying but in the things before and after it. DNS preparation belongs to the most commonly overlooked items: whoever lowers the record lifetime on cutover day waits hours for the internet while the new server stands ready. The lowering therefore happens days ahead, with a value that still looks normal in daily operation and suffices for a fast switch.

The second point concerns communication in the cutover hour. A move changes times and reachability for people who only hear about it afterwards, unless someone announces it. The short note beforehand about who cannot reach what and when saves half the follow-up questions and turns the cutover point into a planned moment instead of a sudden one. Both points cost nothing but planning, and both separate the orderly move from the improvised relocation where everything gets copied and at some point nobody knows which server is the right one.

A thought on repeatability belongs at the end: the value of a clean migration sequence lies not in the single move but in the second move becoming easier. The inventory list is reusable, the sequence is documented, the checklist is written, and the decisions that cost deliberation the first time stand as standards the second time. Teams that accompany moves regularly build from this foundation a small library of templates per server class, and the effort for the next move drops with every instance. That is the difference between a method and a series of lucky accidents that happened to end well.

Whoever wants the transfer path encrypted moves it into a tunnel; the setup is covered in WireGuard site to site in practice. If you are planning a move and want an orderly approach, the DevOps and backup service page describes the matching service, and the contact page is the fastest way to reach us.

Sources

• rsync manual page, https://download.samba.org/pub/rsync/rsync.1.html (accessed 2026-11-03)
• rsync manual page (distribution variant), https://man.archlinux.org/man/rsync.1.en (accessed 2026-11-03)