Migrating a Linux game server to a new VPS

Migrating a Linux game server to a new VPS is mostly about mastering the order of operations. By preparing a verified backup, separating data from the service, and planning the IP address or DNS cutover, you can reduce downtime without improvising.

1. Preparing the migration before shutting down the old server

Start by building an inventory: Linux distribution and version, Ubuntu or Debian, operating system, root or service user, SSH access, file locations, TCP or UDP ports, environment variables, scheduled tasks and any systemd services. Also note the version of the game software, the engine, the extensions and the scripts. This list keeps you from discovering a dependency at the last minute.

Measure the used space and plan a margin on the new VPS. Compare the actual CPU load, RAM, SSD storage and network traffic consumed. A migration is not the right time to change the Linux version, the game engine and the deployment method all at once. Keep an equivalent environment first; optimizations can come after the cutover.

If the server already runs with Pterodactyl, identify the backups, configuration files and persistent data associated with the instance. See the Pterodactyl backups guide to distinguish backup from restoration.

2. Backing up data and configuration

Shut down the game server cleanly before the final backup to avoid copying a world or a database in an inconsistent state. Keep at least the worlds, the configuration files, the plugins or mods, the scripts, the useful logs and the database data if the game uses one.

Keep several copies: a working copy for the transfer and an independent copy that will not be modified during the migration. Check that an archive can be listed and extracted. A backup whose file is present but impossible to restore does not protect the cutover. This backup logic should be part of the usual procedure, not only of the day's operation.

For a dedicated server, the backup strategy, any high availability and reversibility must be defined before the operation. See the dedicated server backup principles to formalize this step.

3. Choosing and preparing the new Linux VPS

A VPS is a virtual server isolated on a physical infrastructure through virtualization. The number of vCPUs, the available RAM, the SSD storage and the bandwidth must match the game server's load. To choose a host, compare the advertised resources, the Linux system offered, root or sudo access, the IP address, backups and reversibility terms. A dedicated server provides reserved physical resources, while a VPS is often suited to a more gradual load.

A VPS plan lets you host a game server in a virtual machine administered by your team. For administrators, SSH access, firewall rules, measurable storage space and accessible logs matter more than a control panel full of useless options. Check what managed services actually cover if they are offered; do not assume a host configures your game for you. The VPS's flexibility comes from this ability to administer its system, its network and its services.

Install the necessary packages, create the service user and prepare the directories with the right permissions. Check that the account has the necessary sudo rights without running the game as root. Open only the ports actually needed for the game and for SSH administration. Before transferring the data, test the connection, storage, memory and network configuration.

If the server saturates the CPU or runs out of memory, increase the virtual server's resources rather than masking the problem with a risky configuration. The Docker installation guide on a VPS can serve as a checkpoint if the service is containerized.

A local firewall must stay readable: document every rule added and keep a backup administration access before changing the network policy. For the choice of machine, compare VPS and dedicated server according to the load, memory and level of control you need.

4. Transferring then testing without changing the DNS

Transfer the files to a temporary directory on the new VPS, then move them into their final path. Preserve owners and permissions; a server that starts with files owned by the wrong user can work partially before producing an error.

Start a test instance on a temporary port or restrict its access to your administration address. Check startup, world loading, plugin loading, log writing, database connections, CPU and RAM consumption, as well as the creation of a new backup. Do not switch players over until these checks are complete.

For a FiveM server, the migration must also cover the resources and configuration; the dedicated FiveM migration guide offers a complementary angle. For a fresh install, check the initial security settings before public exposure.

5. Organizing the cutover and rollback

Announce a short maintenance window, stop the old server and make a final differential or full backup. Repeat the transfer of the changes that occurred since the test copy, then start the service on the new VPS. Check access from an external network, the IP address or domain name, the game ports and the systemd or application logs.

Do not delete the old server immediately. Keep it stopped but intact during the validation period, with its files and configuration. If a critical problem appears, you can temporarily bring the old service back online, restore the DNS if necessary and calmly analyze the gap.

Monitor performance, RAM, CPU, network errors and disk space after the cutover. Discover the Linux VPS plans if you need to adapt the resources, and use the backup and reversibility page to formalize data retention.

Final checklist

• inventory of the Linux distribution, the operating system, the configuration and the dependencies;
• measurement of CPU load, RAM, SSD storage and network ports;
• tested independent backup and last copy made;
• new VPS prepared with user, permissions, packages and SSH access;
• firewall, IP address and connection rules checked;
• test performed before the IP address or DNS cutover;
• maintenance window announced;
• old server kept for rollback;
• monitoring of logs, resources and backups after migration.