Palworld Dedicated Server Migration: Files and Cutover

Moving a Palworld dedicated server means moving the complete active world, then proving the new server loads it before your group switches addresses. Match the server builds, stop the source before copying, and keep an independent rollback copy until players confirm the destination after a restart. If you would rather hand off the file transfer, Game Hosting offers free support migration from another host; its support team handles the move through a ticket.

Plan a cutover and keep one world authoritative#

Pick a quiet window, tell players when the source will stop, and choose one person to verify the destination. Before downtime, record the source server build, operating system, active mods, public address, configured game port, and the value of DedicatedServerName. Ask the destination host which build it can run and how it accepts a dedicated-server save. A same-build move reduces variables, but Pocketpair does not publish a host-to-host migration guarantee or compatibility matrix.

Before cutover	Record or confirm
Source	Build, OS, active WorldGUID, settings, mods and their versions
Destination	Matching build, expected save path, file-upload method and restart controls
Group	Maintenance window, tester, new address and rollback decision

Make a small inventory before downtime: world GUID, server build, OS, active mods and versions, address and port, plus the settings you plan to carry over. Keep credentials out of that note and in a password manager. This separates the world copy from the connection details you will hand to friends, and makes a new default or missing mod easier to spot.

Do not treat a fresh destination world as proof that the migration worked. Keep the old server and its files available until the new world passes the acceptance checks below. If the source is a co-op world rather than a dedicated server save, stop here: that requires host-character conversion, covered in the co-op-to-dedicated transfer guide.

Stop the old server and preserve a rollback copy#

Tell connected players the shutdown time, save, and stop the source before you copy any files. Palworld’s official admin command reference documents /Save and /Shutdown [Seconds] [MessageText]; admin commands require the server’s admin password. Use the server’s own supported control panel or in-game command route, and confirm that its process has stopped before copying.

Make a separate copy of the complete active world folder and the settings you will need. Store it outside the source server directory and keep the original untouched. If you only download a few files or copy while the server is writing a save, you may have an incomplete checkpoint. A backup that exists is useful only if you can identify which world it contains and keep it separate from the destination files.

Copy the complete active world and its settings#

For a dedicated server, copy the entire selected directory below Pal/Saved/SaveGames/0/, not only Level.sav. The folder name is the world’s GUID. The save-location guide explains how DedicatedServerName identifies the active folder and how to distinguish it from the server’s public display name.

Also save the active PalWorldSettings.ini, GameUserSettings.ini, and a record of the mods and versions in use. The world folder holds more than one file; selecting a single file by its name or newest timestamp is not a reliable way to identify the active world. Keep settings separate from the world archive so you can reapply them deliberately rather than assuming paths and defaults transfer between machines.

A host panel may expose the server files through a file manager, an archive download, or its own upload flow. Follow the provider’s instructions for that panel and confirm the archive contains the intended WorldGUID folder before proceeding. Do not assume every host accepts the same directory layout or that a successful upload notice means the game loaded the save.

Point the destination at the copied WorldGUID#

Prepare the destination server and start it once so it creates its own configuration and directory structure. Stop it again before replacing any generated world files. Move the copied world directory into the destination’s active SaveGames/0/ location, preserving its GUID folder name. Then set the destination’s DedicatedServerName to that same GUID in its GameUserSettings.ini.

Match the folder and selector
The folder beneath SaveGames/0/ and the DedicatedServerName value must identify the same world. Do not replace it with the friendly server name players see in the browser; those are separate settings.
ini
```
DedicatedServerName=<WorldGUID>
```
Keep the source selector as a reference
Compare the destination file with the source copy, then confirm the destination points to the directory you uploaded. Do not delete the original source folder as a shortcut for selecting the world.

If the destination starts a new world, stop it and check the selector and folder name before anyone plays. A successful process start only proves the server booted; it does not prove the expected campaign loaded.

Reapply settings and account for different file layouts#

Palworld’s official configuration guide lists the active settings file under Pal/Saved/Config/WindowsServer/PalWorldSettings.ini on Windows or Pal/Saved/Config/LinuxServer/PalWorldSettings.ini on Linux. Those directories appear after the server starts once. Editing DefaultPalWorldSettings.ini does not apply the settings. Copy the active settings file as a reference, then check the destination’s own active configuration path and re-enter the values you intend to keep.

Windows and Linux use different paths and server executables. File names are case-sensitive on Linux, so check capitalization instead of pasting a Windows path into a Linux panel. Docker paths depend on the image’s volume mapping: use its configured host-side mount, not an example path from a different container. This guide does not validate a Windows-to-Linux or Docker migration; keep that as a separate compatibility question for the image and build you plan to run. After the move, the Palworld update guide shows how to patch through the destination’s existing install method.

Reinstall only the mods and dependencies supported by the destination setup, and compare versions with your source record. If the provider cannot confirm the required mod files or build, keep the source intact and resolve that gap before the group switches. The file copy alone cannot prove that a modded world will load correctly.

Test the world and a restart before changing the address#

Treat destination acceptance as a required test, not a formality. Join from a client outside the server machine’s local network if you can, and have a player who used the old world check the result. Confirm the day count, expected bases, guild access, character, inventory and important Pals. Then save and restart the destination, reconnect, and check that the same state remains. One connection to an empty world is not a pass.

Check the loaded world
Compare several concrete details with your source notes: day, a known base, the expected guild and the returning player’s character and inventory. Ask a second player to join if that is part of the group’s setup.
Check persistence after restart
Save and stop the destination, start it again, and repeat the same checks. If a base, player, mod or setting is missing, stop the destination and restore from the untouched source copy while you investigate.

Change the address only after acceptance#

Once the group accepts the destination, share its new IP address or hostname and the configured port. Pocketpair’s requirements page lists UDP 8211 as the default game port. If your source used another port, or the destination host assigns a different one, use the actual destination value; do not assume UDP 27015 is required for every Palworld server.

If you use a hostname, dynamic DNS can keep its record pointed at the new address; tell players it may take time for cached details to refresh. Ask one friend to connect using the new address before you invite the full group. Keep the old server stopped after the cutover so players do not split across two authoritative copies. Do not cancel or wipe the source until you have a separate copy and a migration the group accepts.

Let support handle the move to a managed host#

If your next destination is a rented server, Game Hosting’s Palworld support can move a world from another host for free. Its published terms say to open a support ticket and provide a world archive or access to the old host; change any shared old-host password after the move. This is a support-led service, not the co-op-only “Bring my world” panel conversion, and it is not proof that every source build or mod set will import unchanged. Confirm the target build and mod path with support before you schedule the cutover.

Quick answers

How do I move a Palworld dedicated server to another computer?

Stop the source cleanly, copy its complete active world folder and settings, then point the destination at that same WorldGUID. Test the destination and its restart before changing the address or retiring the source.

Do players lose progress when a Palworld server changes IP?

An address change does not rewrite the save, but players can land on a new or wrong world if the destination import is incomplete. Verify the correct world and player data on the destination first.

Can I move a self-hosted Palworld world to a provider?

Yes, but confirm the provider’s dedicated-save import process before cancelling the old service. Game Hosting says its support can move a world from another host for free.

What should I check before shutting off the old server?

Join the destination remotely, check the expected day, characters, guild, bases and Pals, then save, restart and check again. Keep the source copy until the group accepts the destination.