Copying data is solved; sequencing is what fails. Lower the TTL two days out, sync in two passes so the window moves only a delta, replicate rather than copy databases, and rehearse the whole cutover once a week early. Plus the six things that always break.
Migrating to a dedicated server is one of the few infrastructure jobs where the technical work is easy and the sequencing is what fails. Copying data is solved. Cutting traffic over without losing a write, without a stale DNS cache sending customers to a machine you already turned off, and with a way back if the new box misbehaves — that is the part worth planning. What follows is the order that works, and the two rehearsals that make it boring.
Inventory what the old machine actually does. Not what the documentation says. Run ss -tlnp for every listening service, crontab -l for every user plus /etc/cron.d, and check for systemd timers. The forgotten cron job that emails an invoice on the 1st is the classic post-migration incident.
Drop your DNS TTL first. Set it to 300 seconds at least 48 hours before the cutover, so every resolver has expired the old value by the time you need to move. Doing this on the day is the single most common cause of a migration that drags for two days — some resolver somewhere is still holding a 24-hour record.
Prepare the destination properly. Same OS major version unless you are deliberately upgrading; changing distribution and machine at once means you cannot tell which one broke it. Harden before it carries traffic, not after — securing a new dedicated server is a 20-minute job on an empty box and a nervous one on a live one.
Verify the hardware before you trust it. Check the disks report the size and model you ordered, that the array is in the layout you asked for, and that the uplink delivers its guaranteed rate — verifying port speed takes five minutes and is much better done now than during the cutover window.
Never a single copy. Two, and the second one is short.
Pass one, days before, with everything running:
rsync -aHAX --numeric-ids --delete \
--exclude=/proc --exclude=/sys --exclude=/dev \
/srv/ root@new-server:/srv/
This moves the bulk while nobody is waiting. It will take as long as it takes.
Pass two, during the window, with services stopped:
rsync -aHAX --numeric-ids --delete /srv/ root@new-server:/srv/
Because pass one did the work, pass two moves only the delta and finishes in minutes. That difference is what turns a four-hour outage into a fifteen-minute one.
Databases do not migrate this way. A file copy of a running database is a corrupt database. Use replication: set the new server up as a replica, let it catch up, verify replication lag is zero, then promote it during the window. For MySQL that is binary log replication; for PostgreSQL, streaming replication. Both reduce the cutover to a promotion and a connection-string change.
The order matters and each step has a verification:
curl --resolve yourdomain.com:443:NEW_IP https://yourdomain.com/health exercises the real vhost and TLS path without touching DNS.--numeric-ids exists because UIDs differ between installs. Without it, a fresh distribution's different user numbering silently reassigns every file.nf_conntrack_max, file descriptor limits and TCP buffers are defaults, not your tuned values — and if you tuned them for a reason, the reason still applies. Linux 10 Gbps tuning covers the ones that matter at high rates.Do the whole cutover once, a week early, against the new machine, with DNS untouched. Sync, promote a replica, start services, run your health checks through --resolve, then throw the state away and re-sync.
It costs an evening and it converts every unknown into a known: how long the delta sync takes, whether the certificates work, whether the application starts cleanly against a database it has never seen, which config file still points at the old address. Migrations that go badly are almost always migrations nobody rehearsed.
If the new machine is also a change in scale — more disks, a faster uplink, a different CPU class — verify the new capability under load before you need it. A 1 Gbps guaranteed box behaves differently from the VPS it replaced, and the time to discover a misconfigured NIC is not during the window.
How long does migrating to a dedicated server take? The preparation is days; the actual downtime window is 15 to 30 minutes if you did two-pass syncing and lowered your TTL beforehand. A single-pass migration on a large dataset can run for hours.
Can I migrate with zero downtime? For read traffic, effectively yes. For writes, you need either a brief pause or an application that tolerates dual-writing. Most teams find a 15-minute window far cheaper than the engineering required to avoid it.
Should I upgrade the OS at the same time? No. Migrate first, upgrade later. Two changes at once means you cannot bisect a failure.
What if something breaks after the cutover? Point DNS back. That is why the old machine stays running untouched for a week and why the TTL stays low until you are confident.
Do I need to reinstall the OS on the new machine first? Only if the delivered image is not what you want. If it is not, reinstalling over IPMI is quicker than adapting to someone else's defaults. If you would rather not run the cutover alone, ask us to schedule it — we have done a few.
Your provider polls the port every five minutes, sorts the samples, throws away the top five percent and bills the rest. That is 36 free hours a month. Here is how to compute your own billed rate before the invoice arrives, and when a flat unmetered price beats it.
The BGP session is the easy step. What decides whether your route reaches anyone is the LOA, the IRR objects, and a ROA whose max length is not quietly authorising somebody else to originate your more-specifics.
A broken AAAA record does not take a site down, it makes it slower for everyone who has IPv6. The prefix you get, the static configuration to prefer, the three things that break it, and how to prove it works.