Moving to a new host: a step-by-step migration checklist
Moving a server, a website or a bot to a new host is easy to do badly and straightforward to do well. Most migration disasters come from the same few mistakes: no backup, no test before switching, DNS changed too early or old services switched off too soon. This checklist keeps you out of those traps, whether you are moving a game world, a WordPress site or a Node.js bot.
Before you begin
Decide what you are moving and why. Write down everything that makes up the service:
- Files: application code, worlds, uploads, configs.
- Data: databases and their users.
- Settings: environment variables, secrets and API keys.
- Network: domain names, DNS records, ports and certificates.
- Scheduled jobs: cron entries, panel schedules and backups.
- Dependencies: versions of the language, game, plugins and packages.
If you cannot list it, you cannot be sure you have moved it.
Phase 1: prepare
- Choose the destination and check that it fits the load. See How to choose the right plan and How to choose a server location.
- Lower your DNS TTL a day or two ahead, to 300 seconds, so the switch takes effect quickly. See DNS records explained.
- Take a full backup of the old service and store it somewhere other than the old server. See The 3-2-1 backup rule.
- Note the exact versions of everything. Moving to new versions at the same time as new hardware makes problems hard to diagnose. Change one thing at a time.
- Tell your users when you plan to move, and how long it may take. See Uptime and maintenance windows explained.
Phase 2: build the new home
Set up the destination while the old one keeps running.
- Create the server and secure it. For a VPS, follow Basic security for a new VPS, including SSH keys and a firewall.
- Install the same runtimes and software at the same versions.
- Create database users, folders and service definitions. See Run your own program as a systemd service.
- Copy configuration, then adjust paths and addresses.
Phase 3: copy the data
For files, rsync is ideal because you can run it repeatedly and it only sends changes. See How to back up your VPS with rsync:
rsync -avz --progress user@old-server:/path/ /path/
For databases, create a dump on the old server and import it on the new one. See MariaDB or PostgreSQL.
For a game server, download the world through SFTP and upload it to the new server. See Connect with SFTP and Upload a Minecraft world. Stop the old server before the final copy so the data is consistent.
Phase 4: test before switching
This is the step most people skip. Test the new host without touching the real address:
- Use the server's IP address, or a temporary hostname, to open the site or connect to the game.
- For websites, edit your computer's hosts file so the real domain points to the new IP only on your machine.
- Click through key pages, log in, upload a file, send a test email, run a bot command.
- Read the logs for errors. See How to read your server logs.
- Check performance under realistic load.
Fix problems now, while nobody is affected.
Phase 5: the final sync and the switch
- Pick your quiet hour.
- Put the old service into maintenance mode, or stop it, so no new data is written.
- Run the final copy of files and databases.
- Start the new service and test again quickly.
- Change DNS to the new address. With a low TTL, most users move within minutes.
- Watch both servers' logs. A few stragglers will still hit the old one until caches expire.
Do not edit DNS before the data is ready. Pointing people at an empty server is the classic mistake.
Phase 6: certificates, mail and the details
- SSL certificates need to be issued for the new server. See How to set up an SSL certificate and Fix renewal problems.
- Email records (MX, SPF, DKIM) must continue to point at the right place. See SPF, DKIM and DMARC.
- Webhooks and API callbacks that use the old address must be updated.
- Bot tokens and keys should be moved safely and, ideally, rotated. See Environment variables and keeping your bot token safe.
- Scheduled tasks and backups must be recreated. See Schedule tasks with cron.
- Monitoring and alerts should point at the new host.
Phase 7: keep the old one for a while
Do not delete the old server immediately. Leave it available for at least a week, after confirming:
- Everything works on the new host.
- New backups have run successfully, and you have tested a restore.
- Nobody still uses the old address.
- The old data is archived if you may need it.
Then cancel the old service. If it involved a plan with us, see Cancel a service and Refund policy explained before you do.
If something goes wrong
Because the old server still exists, you can point DNS back and try again. That safety net is the main reason for the earlier steps. If you need help, include your plan, what you moved and the errors you saw in a clear request. See How to write a support request.
Summary checklist
| Step | Done? |
|---|---|
| Listed everything to move | |
| Lowered DNS TTL | |
| Backed up the old service | |
| Built and secured the new host | |
| Copied data | |
| Tested before switching | |
| Final sync and DNS change | |
| Certificates, mail, webhooks updated | |
| Kept the old host for a week |
Still stuck? Open a ticket on Discord - run /ticket in any channel, pick a department, and include your Server ID or Invoice ID so we can jump straight in.