Server migration without downtime
Nobody changes servers for fun. The reason is usually one of four: the hosting provider raises the price or shuts the service down, the hardware is old, the current capacity is no longer enough, or the operating system version has gone out of support and security patches have stopped arriving.
The migration itself is routine work. It goes wrong when it is done in a hurry and without a list — because a server almost always runs more things than anyone remembers at first.
What breaks in a bad migration
The most visible problem is downtime: the site is offline for hours because copying the data took longer than expected. But the expensive damage is the part you do not notice straight away.
Email stops arriving, because the SPF record still points at the old server's IP. The messages do not bounce — they quietly land in spam and the customer assumes you never replied.
The certificate expires, because the Let's Encrypt renewal stayed on the old machine and nobody notices until the browser starts showing a warning.
Scheduled jobs never run. Backups, invoice generation, data exchange — cron jobs live in no repository, and they do not get moved because nobody knows they exist.
Backups keep running from the old machine. The most dangerous mistake of them all, because it is discovered only when something actually needs restoring.
How a migration runs, step by step
1. Inventory
Before touching anything, write down what really runs on the server: the web server and its virtual hosts, the databases and their versions, application services, cron jobs, firewall rules, SSL certificates, the mail configuration, access keys and backup destinations.
This list is the most important part of the whole job. Every later surprise comes from something that did not make it onto it.
2. The new server is ready before, not during
The new machine is set up in parallel while the old one keeps serving. Migrating in place — upgrading the old server into the new one — is the only option with no way back.
The same logic applies to securing the server: the new machine is hardened properly at the start, not later.
3. A trial run before touching DNS
Copy the data across and start the application on the new server, pointing the domain at the new IP through your own machine's hosts file. That way you see exactly what a visitor will see — before anyone else sees it.
This is where missing PHP or library modules, wrong file permissions and database encoding differences show up.
4. Lower the DNS TTL days in advance
If the record's TTL is 24 hours, the switchover takes a full day. Drop the TTL to something like five minutes a couple of days before the move, and the switch becomes near-instant. Raise it back once the migration has succeeded.
That single step is the difference between "a migration with no downtime" and "a site that was half-working all day".
5. Sync the data twice
The first full sync is done calmly, in advance. Immediately before the switchover you run a second one covering only what changed — which keeps the real closed window down to minutes rather than hours. For the database that means a final dump taken at a moment when writes are briefly paused.
6. The old server stays up
Do not delete the old machine on switchover day. Keep it running for at least a couple of weeks, but closed for writes. It is the cheapest insurance available.
7. After the move
Check: the certificate and its automatic renewal, email deliverability (see the guide to reliable email delivery), that cron jobs actually fire, that a backup is created AND that a restore has been tested, monitoring and alerts, and the logs over the first 24 hours.
What gets forgotten most often
In practice the list is short and always the same: cron jobs, SPF and DKIM records, firewall exceptions for other systems' IPs, the backup destination, certificate renewal and log rotation. If those six have been checked, the migration is very probably healthy.
When to hand it over
A migration is exactly the kind of work where experience pays the most — not because it is difficult, but because the cost of a mistake shows up weeks later. If the server runs something whose downtime costs money, the move and the ongoing Linux server management are worth handing to someone who does this regularly.
What a maintenance contract normally covers is set out in a separate post: what a Linux server maintenance contract includes. If the thing being moved is a website or an online store, it usually comes with website and online store maintenance too.
