Switching Vintage Story Server Hosts Without Losing Your World

Changing hosts should be a file transfer with a rollback plan, not a test on your only copy of a long-running Vintage Story world. Move a clean, recoverable copy of the world, bring over the server data it depends on, and start the new host on the same game version before inviting the group back.

This guide covers a multiplayer world moving from one hosted or self-hosted server to another. It does not replace the separate steps for uploading a single-player world to a server. If you have not chosen the destination yet, first compare what matters to your group in our Vintage Story server hosting guide.

Check that your group can keep playing#

Vintage Story currently supports PC clients on Windows 10 or newer, macOS 13 or newer, and 64-bit Linux. The official system requirements list no console client. Each person needs their own Vintage Story game account; keep the game’s normal authentication enabled. Do not share one account or try to make a migration easier by disabling authentication.

At the time of this guide, the latest stable release is 1.22.7. Vintage Story 1.22 and newer server builds require .NET 10. Plan the move around the exact release running on the source, not just “stable” or “1.22.” Client and server versions need to be compatible, and the safest first load uses the same release on both servers. The dedicated server uses TCP and UDP port 42420 by default; a hosted panel may show its connection address and port separately.

Mods need the same care as the save. Write down every mod’s name, author, version, and compatibility tag from the official Vintage Story ModDB. Do not use Minecraft or Steam Workshop instructions: Vintage Story’s mod directory is its own ModDB. Server-side and universal mods can be offered to clients when they join; client-side mods may need to be installed by each player. A mod showing up in the server list does not prove that its exact release works with this world and game version.

Inventory the old server before changing anything#

Record the source’s game version, world name, SaveFileLocation, mod list, server address, port, and any planned whitelist or access rules. Save screenshots or notes for settings your group expects to keep. Do this while the existing server still works.

The data you may need is spread across the server’s data directory:

Data	Why it matters	Migration handling
Saves/<world>.vcdbs	Main world database: terrain, builds, inventories, and world state	Copy from a stopped source into the destination’s Saves folder
Matching .vcdbs-wal and .vcdbs-shm, if present	SQLite journal and shared-memory files associated with that database	Keep them with that exact save when they exist; never mix sidecars from another copy
Mods	Server mods required by the world	Install the same compatible mod releases on the destination
ModConfig	Separate settings that individual mods may store	Review and copy relevant files while the game is stopped
Playerdata	Player privilege and access files, including whitelist-related data	Back up both ends, then verify who is allowed in and who has admin roles
serverconfig.json	Server settings and the path to the save	Preserve needed values, but use the destination’s own file and path

The official data-folder reference lists default locations for Windows, Linux, and macOS. A server can use a custom data path, so its actual serverconfig.json and launch setup are more reliable than assuming a default folder. Client-only files such as a player’s local map are not a substitute for the server save.

Make a backup you can recover#

Before changing files, create a backup through the old host’s backup control or the server’s supported backup command, then verify that the backup exists and is readable. The official command reference lists /genbackup [filename], but it warns that its command list is outdated; follow the current command shown by your server or provider. Do not assume a green “backup complete” notice by itself proves that recovery works.

Test a separate copy of the backup before treating it as your safety net. On a disposable destination, restore the copy, point the test server at that restored save, and start it on the same Vintage Story release. Check the startup log for the expected save and load errors. If you cannot test the restore before the move, keep the source running and arrange the backup test first.

I tested this recovery path on October 16, 2026, using the official Linux dedicated-server archive for 1.22.7 and a disposable vanilla world. The server created /genbackup a14-migration-test; the backup passed SQLite’s integrity_check, and a fresh same-version server loaded it to WorldReady. This checks one clean vanilla backup and recovery, not a modded world, a provider’s panel, a client connection, or a save from your server. Keep your original and backup until your own world has passed the checks below.

Stop the source and take one consistent copy#

Tell players when the source will go offline. Save and stop the server through its normal control, then wait until the process has fully exited. A world database is SQLite; copying it while the server is writing can leave the main file and its journal out of sync.

Now copy the world and the matching sidecars, if present, into a separate staging folder. Add the relevant Playerdata, ModConfig, and mod archives from that same stopped source. Do not delete a -wal file because its name looks temporary, and do not pair one database with sidecars from another backup. If files remain after a clean shutdown, preserve the set rather than deciding on your own that one is disposable.

Make a second copy for the destination upload. Keep the untouched original and recovery backup somewhere separate. If the old provider creates an archive, check that it finished downloading and can be opened before closing the old account or server.

Prepare the new host without overwriting its defaults#

Create the destination server and note its game release and data folder. Back up the fresh destination before replacing or selecting a world. Install the source’s exact compatible mod releases first, including required dependencies, and review each mod author’s own notes for other data it needs.

Use the destination’s serverconfig.json as the starting point. Do not replace it wholesale with the old server’s file: it can contain an absolute path that only exists on the source machine, as well as source-specific port and access settings. Set the destination’s SaveFileLocation to the uploaded file’s actual path, or choose the file through a verified world selector. The official server configuration reference documents this setting.

Bring over only the settings you intend to keep. Preserve the destination’s network and authentication setup, then check the whitelist, player roles, admin access, bans, and password separately. Dedicated servers use whitelist mode by default. Keep it enabled and confirm each player’s exact in-game account name. A saved access file is useful, but it does not replace checking that the right people can enter the new service.

Start the copy and check the world before cutover#

Start the destination with the same game release as the source. Watch its console or logs until it reports that the world is loaded. If it creates a fresh world, stop immediately; check the selected filename and the destination-local SaveFileLocation before trying again. Do not let players build in a blank replacement while you are still diagnosing the path.

Before sending the new address to the whole group, inspect a few known places and chests, a returning player’s inventory and location, and the server’s world name and settings. Confirm that important modded blocks load without missing-content warnings. Check the destination’s whitelist and admin roles with the owner account. Then have a regular player connect using their own account and confirm the group can reach the new address and port. That client check is a separate final step; a server process reaching “world loaded” is not proof players can connect.

If you self-host, verify that the firewall and router allow the server’s actual port on both TCP and UDP. The default is 42420, but use the port displayed by the destination. If the source and destination share an address, do not point everyone at the new port until the server is ready and the old one is stopped.

Keep a rollback path while players return#

Keep the source world, downloaded archive, and verified restore copy until the new host has passed the world, mod, access, and player-join checks. Tell the group which address to use and where to report a missing build or inventory. Once they have played on the destination, avoid reopening the old save as if it were current; that creates two diverging copies.

If the destination shows a new world, stop it and correct SaveFileLocation or the selected world before loading again. If it reports missing blocks or items, stop and compare the exact content mods and versions with the source. If access is wrong, review Playerdata, whitelist mode, roles, and account names instead of disabling authentication. If the world fails to load, keep the failed destination files together for diagnosis and restore only from the verified backup as a complete matching set.

Do not upgrade Vintage Story or its mods during the same cutover. Once the migrated world is confirmed, make another verified backup, then plan any update separately. That leaves you with a clear rollback point if a later version or mod change has a problem.

Let support handle the transfer if you prefer#

You can also choose a host that will move the files for you. Game Hosting offers free world migration from another host on every plan: open a support ticket and provide a ZIP of the world or the old host’s login details. If you share credentials, support deletes them after the move and asks you to change that password. Keep your own source copy and backup until you have checked the destination world, mods, and player access.

For Vintage Story, the Game Hosting panel has a world list and world selection control, a ModDB manager, version selection, player and whitelist controls, and three backup slots. Restoring a panel backup requires the server to be stopped and replaces the active world/settings, so verify the backup and recovery before you depend on it. Review current Vintage Story server plans and availability if you want support to handle the transfer.

Frequently asked questions#

Do I need to move the whole server folder?

No. Inventory the world database, matching SQLite sidecars if present, mod files, relevant ModConfig, and player access data. Use the new host’s own server configuration and path. Copying an entire install or stale config can bring across the wrong absolute save path or network settings.

Can I move from Windows to Linux or macOS?

The game supports Windows, macOS, and Linux PC clients, and the server data-folder guide lists platform-specific locations. Keep the world and its relevant server data together, use the new machine’s paths, and test with the same Vintage Story release. This guide’s actual restore test used Linux only; it was not a cross-platform test of a customer’s world.

Will players keep their characters and claims?

The main world save contains world state and player inventories, while the separate Playerdata folder stores privileges and access-related files. Move the consistent source data and check player inventory, claims, roles, and whitelist on the destination. Do not infer that access settings survived just because the terrain loaded.

What should I do if I only have a backup from the old host?

Ask the old provider which Vintage Story version produced it and whether it includes the world and matching data needed for recovery. Test a separate copy on a disposable server before replacing the live destination. Keep the original backup unchanged until the restored world and player access have been checked.

Quick answers

Can I move a Vintage Story world from one host to another?

Yes. Stop the source server, make and verify a backup, then move the closed world database and the matching server data. Start the destination on the same Vintage Story version first, check that it loads the expected world, and keep the original copy for rollback.

Do I only need to move the .vcdbs file?

The .vcdbs file is the main SQLite world save. Also inventory matching -wal or -shm sidecars, Playerdata access files, ModConfig, and the exact server mods. Copy the database and any sidecars from one stopped, consistent snapshot.

Will my whitelist and admin settings move too?

Playerdata contains player privileges and whitelist-related files. Bring the relevant files over only after backing up the destination, then verify player names, roles, bans, and whitelist access on the new server. Keep Vintage Story authentication enabled.

Should I update Vintage Story during the move?

Keep the old and new server on the same release for the first migration check. Make another verified backup before testing a game or mod update; treat that upgrade as a separate change with its own rollback copy.