How to Migrate a Private Game Server to a New VPS (2026)

Moving your private game server to a new VPS is one of the most nerve-wracking tasks a server admin faces. You built a community, and the thought of losing players to downtime or corrupted save files keeps you up at night. I have been there, and after migrating dozens of game servers across providers, I can tell you that a clean migration is absolutely possible with the right process.

This guide walks you through exactly how to migrate a private game server to a new VPS without losing players. We cover pre-migration planning, the step-by-step cutover process, game-specific save file locations, player notification strategies, and the pitfalls that catch admins off guard.

Whether you are running Minecraft, Valheim, Palworld, Rust, or V Rising, the principles are the same. The difference between a smooth migration and a disaster comes down to preparation, timing, and communication. Let’s get into it.

What You Need Before You Migrate a Game Server to a New VPS?

Pre-migration planning is where most admins either set themselves up for success or create future headaches. Skip this phase and you will forget something critical. I learned this the hard way when I left behind a cron job that ran automated backups, and the new server went three days without saving player data.

Build a Complete Server Inventory

Start by documenting everything running on your current VPS. Open an SSH session and catalog every service, file, and configuration that matters to your game server.

Your inventory should include the game server software and its version number, all configuration files, save files and world data, database servers (MySQL, PostgreSQL, SQLite), cron jobs, firewall rules (iptables or UFW), SSL certificates, and any mods or plugins with their configurations.

Run this command to list all running services so nothing slips through:

systemctl list-units --type=service --state=running

List your cron jobs next. These scheduled tasks are the most commonly forgotten item during migrations:

crontab -l

Check your firewall rules and save them to a file for easy reference:

iptables-save > firewall_rules_backup.txt

Measure Your Data

Before you plan your migration window, you need to know how much data you are moving. A 5 GB Minecraft world transfers in minutes. A 200 GB Rust server with months of player data takes hours.

Check the size of your game server directory:

du -sh /path/to/your/game/server

This number determines how long your rsync operations will take and helps you pick the right maintenance window. Always add 50 percent to your time estimate for safety.

Create and Verify a Full Backup

Before touching anything, create a complete backup of your game server. Do not skip verification. I have seen admins create backups that turned out to be corrupted, leaving them with no safety net when something went wrong.

Create a compressed archive of your entire server directory:

tar -czvf game_server_backup_$(date +%F).tar.gz /path/to/your/game/server

Download a copy to your local machine and extract it to confirm the archive is valid. If your game server uses a database, export it separately:

mysqldump -u root -p --all-databases > database_backup.sql

Test the restore on your local machine or a temporary VPS. A backup you cannot restore is not a backup at all.

How to Migrate a Private Game Server to a New VPS: Step-by-Step

This is the core process. Follow these steps in order, and you will move your game server with minimal downtime and zero data loss. The entire strategy relies on running both servers in parallel, syncing data, then cutting over DNS when everything matches.

Step 1: Provision and Configure the New VPS

Set up your new VPS with the same operating system or a close equivalent. Install all dependencies your game server needs, including runtime environments like Java for Minecraft or .NET for certain servers.

Replicate your firewall rules from the backup file you created earlier. Game servers need specific ports open for both TCP and UDP traffic. Forgetting a port is the fastest way to have players who cannot connect after migration.

Restore your firewall rules on the new server:

iptables-restore < firewall_rules_backup.txt

Install SteamCMD if your game uses it, since many dedicated servers require it for installation and updates:

sudo apt install steamcmd

Step 2: Lower DNS TTL 48 Hours Before Migration

If your players connect using a domain name instead of a raw IP address, lowering your DNS TTL is the single most important step for a smooth cutover. DNS TTL tells caching servers how long to remember your old IP address.

By default, DNS TTL is often set to 24 hours or more. If you cut over DNS with a high TTL, some players will be connecting to your old server for up to a full day after the switch. Lower the TTL to 300 seconds (5 minutes) at least 48 hours before your migration window.

This gives DNS resolvers worldwide time to pick up the new shorter TTL. When you finally change the IP, propagation happens in minutes instead of hours.

In your DNS management panel, edit the A record for your game server domain and set TTL to 300. Wait a full 48 hours before proceeding to the cutover step.

Step 3: Install Game Server Software on the New VPS

Install the same version of your game server on the new VPS. Version mismatches between your save files and the server software cause corruption and failed loads. Check your current server version before installing.

For Steam-based game servers, use SteamCMD to download the server files. Here is the command pattern:

steamcmd +login anonymous +force_install_dir /path/to/server +app_update APPID validate +quit

Replace APPID with your game’s Steam application ID. For example, Palworld dedicated server uses App ID 2394010. Do not start the server yet. You just need the base files in place.

Copy over your configuration files manually at this point. Configuration files are small and transfer instantly, and having them in place before the data sync means your server is ready to launch the moment data transfer completes.

Step 4: Initial Data Sync with rsync

This is where the magic happens. rsync over SSH is the most reliable method for transferring game server data between VPS instances. It handles large files efficiently, preserves permissions, and supports delta transfers so subsequent syncs only copy what changed.

Run your initial rsync from the old server to the new server while the old server is still running. This is a background sync, so players keep playing without interruption:

rsync -avz --progress /path/to/game/server/ user@new-vps-ip:/path/to/game/server/

The -a flag preserves permissions, ownership, and timestamps. The -v flag gives verbose output so you can monitor progress. The -z flag compresses data during transfer to save bandwidth.

For large servers, run this initial sync the day before your migration window. This copies the bulk of your data while the server is live, so your final sync during maintenance only transfers the delta changes that happened since.

Step 5: Final Delta Sync During Maintenance Window

Now comes the actual migration moment. Schedule a maintenance window during your lowest-traffic time, typically early morning on a weekday. Announce it to your players at least 48 hours in advance.

During the maintenance window, shut down the game server on the old VPS first. This ensures no new save data is written during the final sync. Use the proper shutdown command for your game to avoid corrupting save files:

systemctl stop game-server

Run the same rsync command again. Since the initial sync already copied most data, this delta sync only transfers files that changed since then. For most servers, this completes in seconds to a few minutes.

rsync -avz --delete /path/to/game/server/ user@new-vps-ip:/path/to/game/server/

The --delete flag removes files on the destination that no longer exist on the source, ensuring an exact mirror. Verify the file counts match after the sync completes:

find /path/to/game/server -type f | wc -l

Step 6: Database Migration (If Applicable)

If your game server uses a database for player accounts, economy data, or plugin storage, you need a separate migration step. Database files copied via rsync while the database server is running risk corruption.

For MySQL or MariaDB, shut down the database, export a fresh dump, and import it on the new server:

mysqldump -u root -p --single-transaction --routines --triggers game_database > final_db_dump.sql

Transfer the dump file to the new server and import it:

mysql -u root -p game_database < final_db_dump.sql

For PostgreSQL, use pg_dump:

pg_dump -U postgres game_database > final_pg_dump.sql

For SQLite databases used by many game mods and plugins, simply copy the database file after stopping the game server. Verify the file is not locked before copying.

Step 7: DNS Cutover

With data fully synced and the game server running on the new VPS, it is time to update DNS. Change the A record to point to your new VPS IP address.

Because you lowered the TTL to 300 seconds two days ago, most DNS resolvers pick up the change within 5 minutes. Some stubborn resolvers may take longer, which is why you keep the old server running.

Verify the DNS change propagated using dig:

dig your-game-domain.com +short

The output should show your new VPS IP. Check from multiple DNS resolvers to confirm propagation:

dig @8.8.8.8 your-game-domain.com +short

Step 8: Post-Migration Verification

Start the game server on the new VPS and connect yourself before announcing it to players. Check that your character, inventory, and world state are intact.

Verify these items specifically: world save loaded correctly, all plugins and mods loaded, player data is accessible, database connections work, admin permissions are intact, and server performance is acceptable.

Check server logs for errors immediately after startup:

journalctl -u game-server --since "5 min ago"

Have a few trusted players or staff members connect and test gameplay before opening the server to everyone. They can confirm that everything feels right from a player perspective.

Step 9: Keep the Old Server Running and Decommission

Do not shut down the old server immediately. Keep it running for 48 to 72 hours after the DNS cutover. Players on DNS resolvers with cached old IPs will still find a working server, and you have a fallback if something goes wrong on the new VPS.

Set the old game server to read-only mode or display a message redirecting players to the new connection details. After 72 hours, verify that zero players are connecting to the old server, then decommission it.

Game-Specific Save File Locations and Transfer Methods

Every game stores its save files differently. Knowing the exact location on your VPS is critical for a successful migration. Here are the most common private game servers and where their data lives.

Minecraft Server Save Files

Minecraft Java Edition stores world data in the server root directory. The world folder contains all chunks, player data, and entity data. Your server.properties file holds server configuration.

Key paths to transfer: the world folder (or whatever you named your world), server.properties, ops.json, whitelist.json, and the mods folder if running Forge or Fabric.

For servers with multiple worlds or worlds managed by plugins like Multiverse, transfer every world directory. Plugin data lives in the plugins folder, and each plugin may have its own data subdirectory with SQLite or YAML files.

Valheim Save Files

Valheim dedicated servers store world data in a specific hidden directory. The world files contain all terrain modifications, buildings, and player bases.

Save location: ~/.config/unity3d/IronGate/Valheim/worlds/

Transfer both the .db and .fwl files for your world. The .db file holds the actual world data, and the .fwl file contains world metadata. Do not separate them.

Palworld Save Files

Palworld dedicated server saves live inside the Steam server installation directory. The save folder contains player data, base data, and all captured pals.

Save location: /Pal/Saved/SavedGames/0/

Palworld saves are notoriously finicky. After transferring, you may need to use a save fix tool to remap player IDs if players had characters on a different server before. Always back up the original save folder before running any fix tools.

Rust Server Save Files

Rust stores server identity, player data, and blueprints in the server identity directory. Each identity is a separate folder under the Rust server installation.

Save location: server/server.identity/

Transfer the entire identity folder. Key files include the .sav file (world state), Player.persistant.db (player database), and the cfg folder for server configuration.

V Rising Save Files

V Rising dedicated servers store save data and settings in the save-data directory. Two critical configuration files control server behavior.

Save location: save-data/

Transfer ServerGameSettings.json and ServerHostSettings.json along with the auto-saved world data. These JSON files control gameplay rules and server connection settings respectively.

Player Notification Strategy: How to Keep Your Community During Migration

None of the technical steps matter if your players leave during the transition. Communication is what keeps your community intact. The admins who lose players during migration are almost always the ones who said nothing until the server went dark.

Communication Timeline

Start notifications one week before the migration date. Post an announcement on Discord, your server website, and any social media channels you use. Include the date, the expected downtime window, and reassurance that all player data is preserved.

Send a reminder 48 hours before, again 24 hours before, and one final notice 1 hour before the maintenance window opens. Players appreciate knowing exactly what to expect.

Notification Template

Use this template as a starting point for your announcements:

“Server Migration Scheduled for [Date] at [Time UTC]. Expected downtime: [Duration]. All player data, builds, and progress will be preserved. We are moving to better hardware for improved performance. Connection details will remain the same if you use our domain name. Join Discord for live updates during the migration.”

Handling Connection Changes

If players connect via domain name, no action is needed on their end. DNS handles the redirect automatically. This is why using a domain name from day one is so valuable.

If players connect via raw IP address, you need to communicate the new IP clearly. Post it on Discord, pin the message, update your server listing descriptions, and send it as a direct server message before shutdown. Some server browsers cache the old IP, so players may need to re-add the server manually.

For Steam server browser listings, the new server appears as a separate entry. Tell players to search for your server name again and re-favorite the new listing.

Use Discord for Live Updates

Create a dedicated migration-updates channel on Discord. Post progress in real time during the maintenance window. Players who see active communication feel reassured. Silence breeds panic and sends players looking for other servers.

Post updates at each major step: starting maintenance, data sync complete, server starting on new VPS, verification complete, and server open to players. Most migrations take 30 to 90 minutes of actual downtime with proper preparation.

Common Migration Pitfalls and How to Avoid Them

Even experienced admins make mistakes during migration. Here are the most common pitfalls I have seen across hundreds of server migrations, and how to avoid each one.

Forgotten Cron Jobs and Scheduled Tasks

Cron jobs are the number one forgotten item. Automated backups, restart scripts, log rotation, and update checkers all live in crontab. Without them, your new server silently loses functionality.

Always export and review crontab before migration. Copy every entry to the new server and adjust paths if the directory structure changed.

Firewall Rules Not Transferred

Players cannot connect if the right ports are not open. Every game has specific port requirements, and many need both TCP and UDP on the same port number.

Document every firewall rule before migration and replicate them exactly. Test connectivity from an external machine before opening the server to players.

File Permission Issues

rsync preserves permissions when run with the -a flag, but if the user account on the new VPS has a different UID, ownership can mismatch. The game server may fail to write save files or read configurations.

After rsync, verify ownership matches the user running the game server:

chown -R gameuser:gameuser /path/to/game/server

DNS Propagation Delays

Even with a lowered TTL, some DNS resolvers ignore TTL values and cache longer. This is why keeping the old server running for 72 hours matters. Players on stubborn resolvers keep connecting to the old server and do not experience downtime.

Database Sync Gaps

If your game server writes to a database while rsync is running, you end up with inconsistent data. Always stop the game server and database before the final sync. Use database dumps rather than file copies for live databases.

Mod and Plugin Version Mismatches

Mods and plugins update independently of the game server. If you install the latest mod versions on the new server while your save files were created with older versions, you can get compatibility errors. Match mod versions exactly, then update after confirming the server works.

Migration Timeline: How Long Each Phase Takes

Time estimates help you plan your maintenance window and set player expectations. These are based on typical game server sizes in the 10 to 100 GB range.

Provisioning and configuring the new VPS takes 1 to 2 hours. Lowering DNS TTL requires a 48-hour wait but zero active work. Installing game server software takes 30 to 60 minutes depending on download speeds.

The initial rsync of your full data set takes anywhere from 30 minutes for a small server to several hours for large worlds with extensive player builds. Schedule this the day before migration.

The final delta sync during maintenance typically takes 1 to 10 minutes since it only transfers changes. Database migration adds 5 to 15 minutes for most game databases.

DNS cutover and propagation takes 5 to 30 minutes with a properly lowered TTL. Post-migration verification takes 15 to 30 minutes of testing before opening to players.

Plan for a total maintenance window of 60 to 120 minutes. Most of that is verification and testing, not actual data transfer. A well-prepared migration feels fast to players because the heavy lifting happened beforehand.

FAQs

Conclusion

Migrating a private game server to a new VPS without losing players comes down to three things: thorough preparation, a structured cutover process, and clear communication with your community. The technical steps of inventory, backup, rsync, and DNS cutover are proven and reliable when followed in order.

The admins who succeed are the ones who start early, lower their DNS TTL 48 hours ahead, run an initial data sync while the server is still live, and keep players informed at every stage. The ones who fail usually skipped the inventory, forgot to lower DNS TTL, or said nothing to their community until the server went dark.

Use this guide as your migration checklist. Take your time with each step, verify your data after every transfer, and keep that old server running for 72 hours as your safety net. Your players will barely notice the move, and you will come out the other side with a faster, more reliable game server.