Moving a live server without breaking it
Most migrations fail at the cutover rather than the copy. Copying bytes is a solved problem. What follows is how the rest is done, what costs nothing, and where we stop.
The free migration window
One migration per instance inside the first 14 days. After that it is billable engineer time, quoted before anything starts.
Every new account gets migration help at no charge for 14 days from the first paid invoice. That covers as many instances as you ordered, up to 2 hours of engineer time each, which in practice is far more than almost anybody uses.
The window exists because the alternative is you losing a weekend to it and concluding that changing hosts is not worth the trouble. Doing it properly costs us less than losing the account in month two.
Larger fleets get a plan rather than a stopwatch. Tell us how many instances, what they run and where they are now, and a written sequence comes back with a rollback point at every step.
The 7-day refund runs alongside this. Migrate on day one, decide on day six that the latency is not what you needed, and the coin goes back in the asset you paid with.
What we will do, and what we will not
Access works one way. You add a key we generate for the job to the source machine, we use it, and you remove it once the cutover is done. The key is per-migration and never leaves the operator workstation. Where your current host will not permit that, a block-level copy pushed from your side into a waiting target is the fallback.
We do not need your control panel password at the old provider and will refuse it if offered. Nobody here wants the ability to act as you somewhere else, and an engineer holding a customer credential is a liability with no upside attached.
We will
Copy filesystems or whole block devices, stage the target instance, tune the receiving kernel and disks, run the delta syncs, sit on the cutover with you, and stay on the ticket until DNS has settled.
We will not
Debug your application, rewrite your configuration for a newer distribution, move a licence tied to somebody else’s hardware, or take a password. Access happens through a temporary key you revoke afterwards.
We would rather not
Move a database by copying its files while it is running. That works until it does not, and the failure turns up weeks later as quiet corruption. Use a replica and a promotion instead.
File-level or block-level
Two ways to move the bytes. The right one depends mostly on whether you want the same operating system waiting for you on the other side.
| Consideration | File-level, rsync | Block-level, dd over SSH |
|---|---|---|
| What moves | Files, permissions, extended attributes | The whole device, byte for byte |
| Downtime | Minutes, one final delta sync | Hours, or a booked window |
| What you boot into | A current image you chose | Exactly what you had, cruft included |
| Changing distribution | Fine, that is the point of it | Not possible |
| Bootloader risk | None, the target already boots | Real, and the console is how you fix it |
| Large sparse disks | Handled well | Copies empty space unless you plan for it |
| When to pick it | Almost always | Legacy machines nobody dares rebuild |
A third option exists and is often fastest: do not migrate at all. Stand the service up clean from your configuration management, restore a database dump into it, and throw the old machine away. Where your infrastructure is reproducible this is a two-hour job with no copy step in it.
The sequence
Seven steps, in this order. Skipping the fifth is how people end up serving from two machines at once and only noticing on Monday.
- 01
Order the target and let it settle
Same size or larger, in the city you actually want. Run your monitoring against it while it is empty for a day and confirm the latency and disk figures match what the plan page claimed.
- 02
Lower the TTL first
Drop the record to 300 seconds at least 48 hours before the cutover, so the old value has expired everywhere by the time you need to change it. This step is worthless if it happens late.
- 03
Take the cold copy
The bulk of the data, moved while everything is still live on the old machine. It takes as long as it takes and nothing is waiting on it.
- 04
Bring services up on the target
Same versions, same configuration, still receiving no traffic. Databases restore here, from a dump rather than from a file copy.
- 05
Test the target by address
Override the hostname locally with a hosts entry and use the site properly for an hour. Log in, write something, upload something, send a mail if it sends mail.
- 06
Freeze, final delta, switch
Stop writes on the source, run the last sync, verify a checksum on something that matters, then change the record. The frozen period is usually under five minutes.
- 07
Keep the source for a week
Powered on, serving nothing, still paid for. It is the cheapest insurance you will ever buy, and the one thing you forgot to copy always surfaces on day four.
DNS, and testing before you commit
A cutover is a DNS change, and a DNS change is never instant whatever the TTL says. Some resolvers round up, some corporate networks cache for a day, and a small number of clients pin an address for the life of a process. Plan on serving from both machines for 24 hours.
Running both is easier than it sounds when the application is stateless. Where it is not, make the old machine read-only at the moment of the switch rather than turning it off, so a stale client gets an obvious failure instead of writing into a database nobody will ever read again.
Before you touch DNS
A hosts entry pointing at the new address is the only honest test there is. Certificates, redirects, absolute URLs and hard-coded addresses all break here, in front of you, rather than in front of your users.
Certificates first
Issue on the target before the cutover using a DNS challenge, so something valid is already in place when the first request lands. An HTTP challenge cannot work until the traffic has already moved, which is too late.
Mail is the exception
Reputation does not travel with the data. A new address sends from zero history, so warm it over a fortnight, keep SPF, DKIM and DMARC valid on both machines through the overlap, and expect the first week to be slow.
Rollback is a TTL, not a rebuild
While the source is alive and the TTL is still low, undoing the switch takes one record change. That is the entire reason steps two and seven are not optional.
Migration questions
Yes, quoted in writing before anything begins, and usually a modest figure. Nothing starts until you have agreed the number.
Yes, block-level, into a licensed image at €22 a month. Reactivation happens against the new hardware and occasionally needs one reboot to settle down.
Then we cannot help directly, and neither can you. Export whatever the panel will give you, rebuild on a clean image, and treat the whole episode as a lesson about panels that own the machine.
Usually under two hours onto a 10 Gbit/s port, often a good deal less. The constraint is almost always the old provider’s upload rather than our download.
Yes, and it is easier because both ends are ours. Snapshot, restore in the new city, test, switch. Moving an instance between our own locations carries no charge.
You change the record back, because the source is still running and the TTL is still 300 seconds. That is the plan rather than a contingency, and it is why the last step exists.
Tell us what you are moving
Instance count, the old provider’s port speed, total data, and whether anything is a database. A written plan comes back the same working day, and if the honest answer is to rebuild rather than copy, that is what it will say.