Server migrations go wrong in predictable ways: a forgotten cron job, a hard-coded IP address, a certificate that was renewed by a script nobody remembered or a database copied while it was still being written to. Almost all of it is preventable with a written plan. This article is a checklist-driven approach to moving a Linux server to a new host, whether you are changing providers, upgrading hardware or rebuilding on a fresh operating system release.

Begin With an Honest Inventory

You cannot migrate what you have not listed. Before touching the new host, document everything the old server does. Go beyond “runs the website” and capture:

• Installed packages and their configuration files, especially anything under /etc.
• Running services and what starts at boot.
• Scheduled work: cron entries, systemd timers and anything triggered by external systems.
• Data locations: databases, uploaded files, logs worth keeping and local mail.
• Inbound and outbound network dependencies: firewall rules, open ports, allowed IP lists on partner systems, outgoing mail relays and API endpoints that whitelist your address.
• Certificates and how they renew.
• Secrets and credentials, and where they are stored.

A useful exercise is to search for the old server’s IP address and hostname across your configuration and your other systems. You will often find references nobody remembered.

Choose a Migration Strategy

There are two broad approaches. A lift and copy clones the existing system to the new host as closely as possible. It is quick, but it carries along accumulated clutter and any problems with the old setup. A rebuild provisions the new server cleanly, ideally from scripts, and moves only data and configuration across. It takes longer but leaves you with a documented, repeatable setup. For anything you expect to keep for years, the rebuild usually pays for itself.

The Pre-Migration Checklist

Task	Why it matters	Done when
Lower DNS time-to-live in advance	Speeds up the eventual cutover	Change has propagated before migration day
Build and test the new host	Finds missing packages early	Application passes tests on the new host
Copy data with a repeatable sync	Allows a quick final delta copy	Initial sync complete, final sync timed
Verify certificates and renewals	Avoids browser warnings after cutover	Renewal works on the new host
Replicate firewall and access rules	Prevents lockouts and exposure	Rules reviewed side by side
Confirm backups on the new host	A new server with no backup is a risk	A test restore succeeds
Write the rollback plan	Makes failure survivable	Steps and decision point documented

Handle Data Carefully

Static files can be synced repeatedly with a tool such as rsync, so the final copy during the maintenance window is small and fast. Databases need more care. Copying live database files from a running server can produce a corrupt or inconsistent result. Use the database’s own dump or replication mechanisms, and check its documentation for the approach that suits your size and downtime tolerance. Replication to the new host, followed by a controlled switch, is the standard way to shorten downtime for larger databases, though it requires more preparation.

Whichever method you use, verify afterwards. Compare record counts, run application-level checks and confirm that recent data is present.

Plan the Cutover Itself

Pick a window when traffic is low and the right people are available. Announce it if users will notice. The usual sequence is: put the application into a read-only or maintenance mode if consistency demands it, run the final data sync, start services on the new host, test with a hosts-file override or temporary URL before changing public DNS, then update DNS records. Keep the old server running and untouched after the switch so the rollback option stays real.

Remember that DNS caches in resolvers and devices you do not control. Even with a short time-to-live, some clients may reach the old address for a while, so ensure the old server does not accept writes that the new one will never see. Redirecting, proxying or shutting down the application on the old host after the cutover avoids split data.

A Hypothetical Example

A team plans to move a small application server to a different provider. The inventory turns up a weekly report job in cron that emails a partner, and the partner’s mail system only accepts mail from the old server’s IP address. Nobody had written that down. Because the team found it during planning, they ask the partner to allow the new address ahead of time. They also lower the DNS time-to-live two days beforehand, rehearse the database copy on a weekend and schedule the cutover for a quiet evening. When a configuration difference makes one page fail on the new host, they notice during the pre-cutover test through a hosts-file override rather than in front of customers.

After the Move

Keep watching for several days. Check logs for errors that point to missing dependencies, confirm scheduled jobs actually ran, and verify backups executed on the new host. Only when you are confident should you decommission the old server, and even then, retain a final backup for a sensible period. Update your documentation and monitoring so they reference the new host, and remove stale firewall entries and DNS records that point to the old one.

Frequently Asked Questions

How long should a migration take? It depends on data volume, complexity and preparation. The cutover is often short, but planning, building and testing take most of the time. Allow generous preparation rather than promising a specific duration.

Can I migrate with zero downtime? Sometimes, with replication and a load balancer or careful DNS switching, but it adds complexity. Many teams accept a short, announced maintenance window instead.

Should I upgrade the operating system during the same migration? Combining changes makes problems harder to diagnose. If possible, migrate first and upgrade later, or the other way around, unless a rebuild makes a fresh release the natural choice.

What if the new host performs differently? Test under realistic load before the cutover where you can, and compare configuration such as storage type, memory and kernel settings. Check each provider’s current documentation for differences.

When can I delete the old server? After the new one has run through at least one full cycle of your scheduled jobs and backups without issues, and you have kept a verified final backup.

Next Step

Create an inventory document for your current server this week, even if no migration is planned. It doubles as disaster-recovery documentation, and when the time comes to move, you will already have the hardest part done.