Server Migration: How to Move From Another Host Without Downtime
Quick answer
The safe way to migrate a server is to build the new one while the old one keeps running. List what has to move: world files, configs, mods and databases for a game server; files, databases and email for a site; code, .env and data for a bot. Lower your DNS TTL to 300 seconds 24 to 48 hours ahead, test the new server through your hosts file, do a final sync in a short window, switch DNS, and cancel the old service only after a few days of checks.
What should you check before migrating a server?
The riskiest part of a migration is not copying data, it is the things nobody remembers: a cron job, a setting someone changed by hand on the old server, a database that lives somewhere else, or an email forwarder set up years ago. So the first job is writing down everything that runs on the old server.
The second check is timing. Find out when the old service ends and start the new one at least a few days before that. Running both for a short overlap costs a little extra, but it is what lets you roll back if something goes wrong. Make sure you still have access to the old provider's control panel, FTP or SSH, and database tools, since you will need them to take backups.
Finally, be clear about where your domain is registered. If it is registered with the old host, you do not have to transfer it as part of the migration; pointing its DNS records at the new server is enough. A domain transfer is a separate job you can do calmly once the move is finished.
- A list of every service on the old server and its version
- Control panel, FTP, SSH and database login details
- The old service's end date and a few days of overlap with the new one
- Where the domain is registered and where its DNS is managed
- Cron jobs, email forwarders and custom settings
- License keys and API tokens
What do you need to back up for each type of service?
Each kind of service keeps its critical data in different places. The table below sums up what to copy for the services people migrate most often and what tends to be forgotten. Extend it for your own setup; data that plugins store in their own folders is especially easy to miss.
Once you have a backup, check that it opens. A corrupt archive or a half-finished database dump is worse than no backup, because it gives you false confidence. Extract the archive on your own computer, look at the file sizes, and make sure the end of the database dump does not contain an error message.
| Service | Always copy | Often forgotten |
|---|---|---|
| Minecraft | World folders, plugins, server.properties | ops.json, whitelist.json, banned-players.json |
| FiveM | resources, server.cfg, txData | MySQL database, license key |
| Rust / ARK / other survival | Save folder and config files | Oxide/Carbon or mod configs, cluster folder |
| Website (cPanel) | Full backup, or public_html plus databases | Email accounts, cron jobs, DNS records |
| Discord bot | Source code, package.json or requirements.txt | .env file, SQLite database |
| VPS | Application files, database dumps, configs under /etc | Crontab, firewall rules, SSH keys |
How do you migrate a game server?
A game server has three things to move: the world or save files, the config files, and any plugins or mods. Stop the server first so save files are not copied while they are being written. Then pack those folders into an archive and upload it to the new server. Install the same version of the game and of your mod framework on the new side; a save loaded into a different version may refuse to open or be converted in a way you cannot undo.
Servers that use a database take a little more work. Most FiveM servers keep player data in MySQL or MariaDB. Export that database with mysqldump, import it into a database on the new server, and update the connection string in server.cfg with the new host, user and password. If you use txAdmin, move the txData folder as well, since your server profiles and admin accounts live there.
Because the server's IP address will change, you need to tell your players. To avoid this next time, connect a domain to your server: an SRV record for Minecraft or an A record for other games means players can reconnect after future moves without changing anything. On a game panel, uploading the archive and extracting it with the panel's file manager is usually the quickest route.
How do you move a website and its email?
If your old host also uses cPanel, a full backup is the easiest route. Create a full account backup with cPanel's Backup Wizard or Backup tool; it bundles files, databases, email accounts and settings into one archive. According to cPanel's documentation, though, restoring a full backup requires WHM, meaning server administrator access, so you hand the archive to your new host and they restore it. If you would rather do it yourself, you can restore partial backups of the home directory and databases.
Coming from a panel other than cPanel, you go the manual route: download the site files with FTP or a file manager, export the database with phpMyAdmin or mysqldump, then create a new database and user on the new host and import it. For applications like WordPress, remember to update the database name, user and password in wp-config.php. Use the utf8mb4 character set for both the export and the import so that non-English characters, including Turkish ones, survive intact.
Email is the piece people forget most often. Create the same accounts on the new server, copy existing mail over IMAP, and point the MX record at the new server. If you are moving to TheCrewHost web hosting, site migration is free: open a ticket and the support team can restore a full cPanel backup for you.
How do you switch DNS without downtime?
Every DNS record has a TTL, which sets how long resolvers around the world cache it. If the TTL is a day, some visitors will keep reaching the old server for up to a day after you change the A record. To avoid that, lower the TTL on the relevant records to something short such as 300 seconds at least 24 to 48 hours before the move, so the old, longer TTL has time to expire.
At cutover, change the A record, plus AAAA and MX records if needed, to the new server's address. Thanks to the short TTL, most visitors move to the new server within minutes. Once everything has settled, raise the TTL back to a few hours.
Changing nameservers is a different matter. That change propagates through the domain registrar and the TLD's servers and does not follow a TTL you control; it can take hours and occasionally a day. If you want to keep disruption to a minimum, set up every record on the new nameservers in advance, so that visitors reach the right server whichever side they land on during the switch.
How do you move a Discord bot?
A bot is often the easiest thing to migrate, because its state usually lives in the code and a small data file. Pull the source from your Git repository or upload it as an archive, move the .env file separately over a secure channel, and reinstall dependencies on the new server with npm install or pip install. Reinstalling instead of copying node_modules or a virtual environment avoids problems from different operating systems and versions.
If the bot uses a file-based database such as SQLite, copy the file while the bot is stopped. If it uses a remote database, changing the connection details may be all you need. Make sure the Node.js or Python version on the new server matches, or is compatible with, the old one.
The key point is never to run both copies at once. Two processes using the same token will answer every command twice and run scheduled tasks twice. Stop the old bot first, then start the new one. Slash commands are registered to the application, not the host, so they survive the move, and there is no need to reset the token unless it has leaked.
How do you migrate from one VPS to another?
The most reliable way to move a VPS is to set up the new server cleanly and transfer the data and configuration. Provider snapshots are usually tied to that provider's platform and cannot be moved elsewhere, so treat a snapshot only as a safety net on the old server. Choosing the same operating system release on the new server reduces package and configuration differences.
Transfer files with rsync over SSH. A command such as rsync -aHAX --numeric-ids preserves permissions, ownership and links, and can resume if it is interrupted. Do the first pass while the old server is still running; at cutover, stop the services and run the same command again, and only changed files are sent, so the final sync takes minutes. For a few one-off files, scp is fine.
Do not copy a database's data directory while it is running; take a dump with mysqldump or pg_dump instead. Also carry over the list of installed packages, the output of crontab -l, web server and application configs under /etc, firewall rules and SSH keys. Rather than copying SSL certificates, it is usually cleaner to issue new ones once DNS points at the new server.
What does a low-downtime cutover plan look like?
Most of a good migration happens before the cutover itself. The new server is set up, the data is copied once, and everything is tested. At cutover the only jobs left are moving the latest changes and redirecting traffic. The timeline below shows the idea.
You can test without touching DNS. Adding the domain with the new server's IP address to the hosts file on your own computer means only you see the site served from the new server. For a game server, simply connect directly to the new IP. Pick the hour with the fewest players or visitors for the cutover and announce it ahead of time.
| When | What to do |
|---|---|
| T-48 hours | Lower DNS TTL to 300 seconds, start the new service |
| T-24 hours | Take the first full copy, set it up on the new server, test via the hosts file |
| T-0 | Announce maintenance, stop the old service, run the final sync and database dump |
| T+15 min | Switch DNS records or announce the new IP, start the new server |
| T+1 day | Check logs, email, backups and scheduled tasks |
| T+3 to 7 days | If all is well, raise the TTL and cancel the old service |
What should you verify after the move, and how do you roll back?
When the move is done, do not stop at checking that the homepage loads or that you can join the server. Confirm one by one that the contact form sends email, users can log in, player inventories and base or tribe data are intact, and scheduled tasks and backups are running. Reading the logs during the first few days lets you catch a missed error before your players do.
Your rollback plan should be simple: the old service stays untouched until verification is complete. If something serious goes wrong, point the DNS records back at the old address or give players the old IP; with a short TTL this takes effect within minutes. If you do roll back, remember that data created on the new server in the meantime, such as new orders or player progress, may need to be copied back by hand.
If you get stuck on a step, you do not have to work it out alone. TheCrewHost's support team can answer migration questions through tickets, Discord, WhatsApp or phone.
- Do the site and game server load from the new IP?
- Do forms work, and does email send and arrive?
- Are player data, inventories and permissions intact?
- Is the SSL certificate valid?
- Are cron jobs and automatic backups running?
Migrate your server from another host in 8 steps
- 1
Take inventory
Write down every service on the old server, its version, databases, cron jobs, email accounts and license keys.
- 2
Start the new service
Order the new server or hosting plan a few days before the old one ends and install the same software versions.
- 3
Lower the TTL
At least 24 to 48 hours before the move, set the TTL on the relevant DNS records to 300 seconds.
- 4
Make the first copy
Transfer files, saves and database dumps to the new server, and check that archives open and dumps are complete.
- 5
Test without touching DNS
Try the site through your hosts file and the game server through its new IP, and confirm everything works.
- 6
Run the final sync
At the announced maintenance time, stop the old service and transfer changed files and the latest database again.
- 7
Switch traffic
Change the A and MX records or announce the new IP to players; for bots, stop the old one before starting the new one.
- 8
Verify, then cancel
Check logs, email and backups for a few days; if all is well, raise the TTL and cancel the old service.
Frequently Asked Questions
How long will my site or server be down during a migration?
In a well-planned migration, downtime is roughly the length of the final sync: a few minutes for small sites and bots, longer for large game worlds and databases. If the new server was set up and tested in advance and the TTL was lowered, most visitors will not notice. Downtime usually stretches out when a migration is rushed on the last day of the old contract.
Do I have to transfer my domain to the new host?
No. Where a domain is registered and where a site is hosted are separate things, and pointing the DNS records at the new server is all a migration needs. You can transfer the domain later if you want to, but keeping it off migration day stops the two changes from tangling together and makes problems easier to trace.
How will my players find the new IP address?
Announce it in advance on your Discord server, in game and on server lists, and keep the old server running for a few days with the new address in its join message. The lasting fix is connecting a domain to your server. When players join by domain instead of IP, future moves only need a DNS change and nobody has to update anything.
Will I lose email during the migration?
Not if it is done properly. Create the accounts on the new server beforehand, copy old mail over IMAP, and keep checking the old mailboxes for a few days after changing the MX record. While DNS propagates, some messages may still arrive at the old server; as long as you have not shut it down, you can collect them and move them across.
What if my old host does not use cPanel?
Then you migrate manually: download files with FTP or a file manager, export the databases, recreate email accounts and copy mail over IMAP. Panels such as Plesk and DirectAdmin have their own backup tools, but those backups usually cannot be restored directly into cPanel, so moving the content piece by piece is the most reliable approach.
When should I shut down the old server?
Wait at least a few days, ideally a week. In that time DNS caches fully refresh, email that lands on the old address can be collected, and any missed problem has a chance to surface. Before cancelling, take one last full backup of the old server and keep it for a while; sometimes a missing file or setting only turns up weeks later.
