How to move your server to a new host without losing data

What actually slips through the cracks

The folder with the site or the app copies itself: it's obvious, so it goes first. What gets left behind is everything that lives around it and quietly holds the whole thing together.

The same culprits turn up again and again: system users and their permissions, which have to be recreated on the new box with matching IDs so the copied files still belong to the right owner; scheduled jobs — the cron tasks that back things up at 4 a.m. or fire a reminder every Monday — that sit inside no project folder at all; TLS certificates and their auto-renewal; firewall rules that wave a couple of ports through and slam the door on the rest; environment variables and secrets, which almost by definition never make it into the repo; and the DNS records that aren't the website — mail, subdomains, SPF — which break in silence if you only check the main address.

The pattern never changes: the visible stuff copies itself, and the invisible stuff is what topples the migration three days later, once the Monday reminder has stopped arriving or mail starts bouncing. A proper migration starts by dragging that invisible half into the light.

Take inventory before you move anything

A server is a folder plus a pile of decisions made months ago that nobody wrote down. Migrating well is, in large part, rebuilding those decisions somewhere new — and to rebuild them you first have to find them.

The inventory answers plain questions. What starts on its own when the machine boots? What runs on a schedule whether or not anyone's watching? Which ports are open, and why? What outside services does the machine talk to — a payment gateway, outbound mail, some API — and with which credentials? Which exact versions of each piece are needed for everything to line up the way it does today?

Writing all this down is what separates a migration you can repeat and verify from one you improvise from memory, finding the gaps in production. Once the inventory is complete, building the new server becomes a checklist you tick off.

The order that keeps surprises out

With the inventory in hand, the work falls into a natural sequence. It isn't arbitrary: the order exists so that nothing irreversible happens until the new server has earned your trust. Every step leaves the one before it untouched, in case you have to walk it back.

1. Build the new server: users, services, certificates, firewall rules, and lower the DNS TTL to a few minutes a couple of days ahead.
2. Copy data and configuration; confirm it boots and behaves exactly the same.
3. Does the new one pass a real test? Yes → switch DNS (the TTL is already low). No → you're still on the old one, no harm done.
4. Once all the traffic is on the new server, switch the old one off.

Notice where the decision sits. Everything before that question is reversible — build, copy, verify — and not a single real user has been touched. The one step that genuinely exposes people to the new server is the DNS switch, and it comes after a test that's allowed to say “not yet.” That's the point of no return, which is exactly why it's crossed last, with a net underneath.

DNS comes last, and stays reversible almost to the end

DNS is the internet's phone book: it turns your domain name into the address of the machine that answers. Changing it is what genuinely sends visitors to the new server, so it waits until the end, when there's nothing left to check.

That change isn't instant. Resolvers all over the world cache the answer for a while — the TTL, or “time to live” — and keep sending people to the old server until that copy expires. With a TTL of twenty-four hours, some visitors won't see the change for the best part of a day.

The trick is to set the stage ahead of time. A couple of days out, drop the TTL to a few minutes. Then, on switch day, propagation takes minutes rather than hours — and, crucially, if something goes wrong, pointing back at the old server takes effect just as fast. While propagation runs, both machines are live: some traffic hits one, some the other. That's why the old server stays up and serving, untouched until the logs confirm nobody is reaching it anymore.

What counts as a “real test”

The decision above rests entirely on one test, so it's worth being strict about what “passing” means. The homepage loading proves very little: it proves the server can serve a page, not that the application works.

A real test exercises the paths that actually matter. If people log in, log in. If a form writes to the database, submit one and confirm it lands and is stored. If something runs overnight, trigger it by hand and watch it do its job. If mail goes out, send one and check it doesn't bounce or get filed as spam. If files get uploaded, upload one at full size.

The best move is to test against the real domain before the world finds out. You do that by pointing only your own computer at the new server — editing your machine's hosts file — while public DNS keeps sending everyone else to the old one. You see exactly what your users will see, real domain name and certificate included, without putting anyone at risk. If something grates, you fix it on the new box at your own pace; the public is still happily on the old one.

The data that changes while you copy

The trickiest part of any migration is the data that won't sit still. Copying static files is easy; copying a database that keeps taking orders, messages, or sign-ups while you copy it is where people trip. What you copied half an hour ago is already out of date.

There are a few honest ways to handle it, depending on how much you can pause. The simplest is a maintenance window: give notice, put the site into read-only or take it down for a short spell, take the final copy with the data now frozen, and switch DNS. When pausing isn't an option, copy the bulk while everything's running and then, right before the switch, sync only what's changed since — the “delta” — which is small enough to move in seconds.

Whichever method you pick, the aim is the same: between the “last good snapshot” of the old data and the first visitor who writes to the new one, not a single change should slip through uncopied.

That instant — the final sync pressed right up against the DNS switch — is the one to plan most carefully of all.

The way back

The whole sequence is built to make backing out boring, and boring is exactly the feeling you want. Because DNS was changed last and the TTL is low, rolling back is simply pointing at the old server again — the one that's been sitting there the whole time, running, with its data intact.

It pays to decide in advance which signals trigger that retreat: errors that weren't there before, numbers that don't add up, mail that stops going out. With the criteria agreed beforehand, there's no arguing in the heat of the moment — you just do it. And since nothing was deleted on the old server, going back costs no data, only time.

After the switch: don't kill the old one yet

Changing DNS doesn't close the migration; it opens its final phase. For a few days, watch the new server's logs more closely than usual: the errors that only surface under real traffic, the scheduled jobs the first time they come round, the mail, the peaks at busy hours.

Keep the old server running for a sensible stretch — days or weeks, depending — as a safety net. Only once the logs confirm absolutely nothing is reaching it, and the new one has run a full cycle behaving itself, do you switch it off. And before it goes dark for good, take one last full backup and stash it somewhere separate: the day you need it, you'll be grateful; the day you don't, it cost nothing to keep.