A Migration Checklist in the Order Things Break

A server migration is a list. Everything on it is small, none of it is difficult, and the ones that go wrong go wrong because a step was done in the wrong order rather than because anything was hard.

This is the list, in the order the steps actually have to happen.

A week before

1. Lower your DNS TTL to 300 seconds.

The step that must be first, because lowering the TTL only takes effect after the old one expires. A record with a 24-hour TTL changed on the day means some players resolve the old address for a full day, connect to nothing, and conclude the server is down.

If you are not behind a domain yet, this is the moment to fix that permanently, custom domains and SRV records covers it, and it costs about ten dollars a year to never have this problem again.

2. Write down what you are running.

Game version, plugin list with versions, Java or runtime version, every config you have edited, every scheduled task, every path referenced anywhere.

Most owners cannot produce this, which turns the migration into an audit under time pressure.

3. Take a backup and restore it somewhere.

Not take a backup — restore one. An untested backup is a hypothesis, and the migration is the worst possible time to discover it is wrong. Game server backups covers doing this properly.

4. Pick your window and announce it.

Use your measured peak-hour chart, not your intuition, and choose the trough. Reading your stats page covers finding the real one: owners are frequently wrong by two or three hours.

Two days before

5. Stand up the new machine and install the same software.

Same versions of everything. Start it with an empty world and confirm it runs.

6. Test the query path from outside your own network.

A server that plays fine and does not answer queries vanishes from every listing at once, and it looks identical to a server that is down. This is the single most common post-migration surprise, and it is usually a query port that was not opened. How game server queries work explains why the ports are frequently different; port forwarding covers the mechanics.

7. Test RCON.

Different address, possibly different firewall rules. Check it now rather than during an incident, RCON explained covers why an exposed port with a default password is worse than no RCON at all, and a fresh machine is exactly where that gets left in place.

8. Announce again, with the time.

The window

9. Stop the old server properly.

Not kill it. Stop it, and let it save. Copying a world from a running server produces a file that is subtly wrong in a way you discover later.

10. Copy the data.

World, player data, plugin data, configs. Use rsync if there is any volume to it, because it resumes and it tells you what moved.

11. Fix ownership.

Files copied as root cannot be written by a service user, and the failure is usually silent; the server starts and cannot save. One command:

sudo chown -R gameserver:gameserver /path/to/server

This single step resolves a very large share of "it worked yesterday" problems. Linux basics for game server owners covers permissions properly.

12. Start it and verify with real data.

Not "does it start". Check a specific player's balance, rank and home against what they had. Check the world is the right one. Check a plugin that stores state has it.

The step people skip is this one, and the failure it catches is a copy that succeeded and dropped a table.

13. Change DNS.

With a 300-second TTL this propagates in minutes.

14. Watch for an hour under real load.

Immediately after

15. Update your listing.

If the address changed, the listing queries something that no longer answers. It will show offline, stop receiving visitors, and record a gap in your uptime history that was a successful migration. Same day. If you do not control the listing, claiming it is a prerequisite.

16. Reconfigure backups on the new machine.

They were set up on the old one. They are not running here. This is the migration mistake with the longest fuse: everything is fine for two months and then something happens and there is nothing to restore.

17. Reconfigure monitoring.

Whatever was watching the old address is watching nothing. Monitoring uptime is what tells you the migration went wrong at 4am.

18. Recreate scheduled tasks.

Restarts, cleanups, mine resets, cron entries. Automating server restarts covers doing it through systemd so it lives with the service.

19. Check every absolute path.

Configs, scripts, backup destinations. A new host frequently means a different directory layout.

20. Say it is done.

Same channel as the announcement, and state explicitly that the address is unchanged if it is. The absence of this message leaves people assuming it is still ongoing.

The week after

21. Keep the old machine.

One month's fee against the ability to go back if something surfaces on day three. Do not cancel on the day.

22. Watch the population.

A migration that lost people shows as a step that does not recover. If it appears, the cause is almost always somebody still resolving the old address or a bookmark that broke.

23. Confirm the listing shows online.

From the listing page, not from your own machine.

24. Then leave it alone.

A migration is not the occasion to also update plugins, change the ruleset or add a mode. One variable at a time — when something is wrong next week you want one candidate rather than five. Updating without breaking things covers the same discipline.

The things people forget

Everybody remembers the world and the configs. These are the ones that surface a week later, when the old machine is already gone.

Cron jobs and timers. Backups, restarts, cleanup scripts, anything scheduled outside the game. These live on the machine rather than in the server directory and they do not come across in a copy of the game folder. A server that migrated cleanly and stopped backing itself up is a common and quiet failure. Automating server restarts covers what is usually in there.

Firewall rules. The old machine had a working set built up over a year of small additions. The new one has defaults.

The database, if it is separate. Plugin data in an external database means the migration has two halves and only one of them is the game directory. Databases for game servers covers moving one without losing rows.

Environment and secrets. API keys, tokens, RCON passwords, webhook URLs. Some are in configs, some are in environment variables, and the second kind is invisible in a file copy. Change the RCON password while you are there. RCON explained.

Whatever else lived on that box. A Discord bot, a web panel, a map download host, a stats page. These were on the old machine because it was convenient, and they are not in anybody's migration plan.

DNS time to live. Lower it a day before, not on the day. A record with a long expiry means some players resolve the old address for hours after you have moved. Custom domains and SRV records covers the mechanics.

Cutting over

The hour itself, and the order that makes it short.

Do the bulk copy while the old server is running. Worlds and content are most of the data and almost none of it changes in the last hour. Copying eighty gigabytes during the outage is why migrations that should take twenty minutes take four.

Then stop the old server, copy only what changed, and start the new one. This is the actual downtime and it is minutes rather than hours.

Start the new server with nobody connected and check it yourself first. Plugins loaded, data present, no errors in the log, query answering from outside. How game server queries work covers why a server can be playable and invisible, which is the failure that gets discovered by absence rather than by an error.

Keep the old machine for a week. Stopped, not deleted. The cost of a week is trivial and it is the only real safety net, because the problems that matter surface on day three rather than during the cutover.

Tell people before, during and after. A silent outage looks like a dead server, and some of the people who find it dead do not come back to check.

What to fix while you are there

A migration is the only time the whole server is in your hands at once, and there are three things that are much cheaper now than later.

Rebuild rather than copy, if the old configuration accumulated years of half-forgotten changes. A fresh install with your world and your deliberate settings removes a category of mystery you will otherwise carry forever.

Drop what nobody uses. Plugins nobody remembers installing, worlds nobody visits, scheduled jobs for things that no longer exist.

Write down what you did. Not for anybody else. For the next migration, which will happen, and which is a different job when you have the list from last time.

The emergency version

When the move is not planned, the host went down, the account was suspended, the hardware died: the list collapses to whatever you prepared in advance:

A domain, so the address can be repointed rather than re-announced. A recent backup you have restored from once. A written list of plugins and versions. Configs stored somewhere that is not the server.

None of those take long. All of them are useless if you start them after the incident, which is the entire argument for testing a change before it reaches players and keeping the list current while nothing is wrong.