Move a Palworld Server to Another Host

There are usually three reasons to change machines: the current one is undersized, the place you were running it is going away, or it sits too far from everyone who plays. Whichever it is, what actually moves when you move a Palworld server to another host isn't the machine — it's one set of save files. What that set looks like and what makes it complete is in the backup and restore guide; this picks up from there and covers the "to another machine" half.

Which kind of move is this

Two different jobs get called the same thing:

• Dedicated server to dedicated server. That's this article. Both ends lay the files out the same way, so the directory travels as-is.
• A save from the in-game hosted world (invite code) to a dedicated server. Different location, different file layout — the steps below don't carry over. Out of scope here.

Three things to do before you copy

1. Match the versions. Install the same server build (Steam app 2394010) on the new machine, start it once so it generates its directories and ini files, then stop it. Both machines should be on the same build, and moving day is the wrong day for one side to update. Save formats change with versions occasionally, and a world written by a newer build may not open on an older one. How to tell which build is current, and the order to update in when one side is behind, is in updating a Palworld dedicated server without losing the save.

2. Stop the old server. Copy while it's running and you get a half-written file. Migration is stricter than a backup here: nobody should be able to get in until the copy is done, because any progress made in the meantime is progress you're about to throw away.

3. Take a complete set. The unit you move is this one directory:

Pal/Saved/SaveGames/0/<WorldID>/

What has to travel with the save directory

All of it. Level.sav (the world itself), LevelMeta.sav, WorldOption.sav, and every file under Players/. What each one holds is in the table in the backup and restore guide.

The most common migration failure lives right here: trimming the copy down to Level.sav because it's the only file anyone talks about. The world opens fine afterwards, so the move looks like it worked — the damage only shows up once people log in.

The other half is what isn't in that directory. Server name, passwords and the multiplier settings live in the ini files, not in the save. Those need collecting separately, which is the section after next.

Player data and guild data are one set

Each .sav under Players/ is one player's character — levels, stats, inventory — and the filename is that player's UID.

Guild membership and base ownership aren't in there. They're recorded inside Level.sav, by UID. So "this base belongs to that person" lives on the world side, "who that person is" lives on the player side, and the only thing joining them is the UID.

Which gives one rule: both sides have to come from the same moment. Mix copies and you get exactly what you'd expect:

• Leave out Players/ entirely and everyone comes back new, with bases owned by UIDs that no longer resolve
• Leave out one player's file and only that person comes back new, while the guild roster still lists their old UID
• Take Level.sav from an older backup and anyone who joined in between drops out of the guild

Copy the directory in one go instead of picking files out of it. And the move isn't finished when the server starts — it's finished when each player has logged in once and confirmed their character, guild and bases are all there.

Three things to change on the new machine

One: the server name that selects the save directory. The new machine generated its own <WorldID> on first start, so it won't match the directory you brought. Which one gets loaded is decided by DedicatedServerName= in:

Pal/Saved/Config/LinuxServer/GameUserSettings.ini

Either point the setting at your directory's name or rename the directory to the one the new machine generated — one or the other, never both. Change both and they disagree, at which point the server decides there's no save and generates a fresh world. The backup and restore guide goes through that trap in detail. On a Windows server the path says WindowsServer instead of LinuxServer.

Two: ports and the public address. PublicPort= and PublicIP= in PalWorldSettings.ini, the -port= launch option, and the firewall. The new machine's IP is different by definition, so an old value left in PublicIP= publishes the wrong address to the community list. Keeping the same port number as before means the only thing your players have to relearn is the IP.

Three: the rest of PalWorldSettings.ini. The displayed server name, the server password, the admin password, the XP and gather rates. None of that is in the save, so a move that skips this file comes up with the world intact, the server renamed to the default, and no password on it.

What your players have to do

The address changes, so everyone has to touch something once.

• Give them the new IP:port — one field, one colon, written together. If someone can't get in, the order to check things in is the connection troubleshooting guide
• The old address is still sitting in their recent-connections list. Clicking it out of habit now leads somewhere empty
• Anyone who found you through the community list has to search the name again, and a freshly started server takes a few minutes to appear there
• Xbox and PS5 friends have to find it in the list again too; when they can't, that's in the same guide
• If you brought the ini across, the password is unchanged. If you changed it, send it with the address

Getting back to the old machine

Don't tear the old machine down the same day. Leave it until the new one has been through a scheduled restart and a backup cycle and people have played on it for a day. That's where the ability to roll back comes from.

Rolling back is short: stop the new server, start the old one exactly as it was, tell everyone the old address again. If you never touched a file on the old side, this is a few minutes of work.

What you must not do is leave both machines open at once. Let players onto both and each accumulates its own progress, and there is no way to merge two worlds — one side has to be thrown away whole. So a migration isn't "try the new one and switch if it's good"; it's "close one side, move, and reopen the closed side if it didn't work".

Common questions

Do players keep their levels and Pals after a server migration?

Yes, if you moved the whole <WorldID>/ directory including Players/ — levels, inventory, captured Pals and base ownership all come across. Move only Level.sav and the world survives while everyone returns as a new character.

The new machine doesn't load the save you brought

When the new server comes up on a fresh world, DedicatedServerName= in GameUserSettings.ini doesn't match the directory you copied under SaveGames/0/, and your world is still sitting next to the new one. Making the two match is covered in the backup and restore guide.

Can I move a save from an in-game hosted world to a dedicated server?

This article covers dedicated server to dedicated server. A save from the in-game hosted mode is stored somewhere else and laid out differently, so the steps above don't carry over to it. The world itself does come across — what breaks is the host's character, because co-op keys it to a fixed ID a dedicated server doesn't recognize. Our co-op to dedicated server save converter rewrites that ID in your browser, so the character, guild and pals come with it. The same tool runs the other way too, turning a world off your dedicated server back into a co-op save.

Can I leave the old server running during the move?

No. With both accepting connections the progress splits, and there's no way to merge it back afterwards. Stop the old side before you start copying, and only start it again if you're rolling back.

Moving in to hosted

The hard part of the sequence above isn't any one step. It's that you only ever do it once, so there's no chance to get good at it, and the thing at stake is the world. Directory names, two files joined by nothing but a UID, an ini that quietly reverts to defaults if you leave it behind — the mistakes mostly surface after people log in, not while you're working.

Moving in to a dedicated Palworld server from KeepWorlds takes the file handling out of it. On the server detail page in the Console you upload a dedicated-server save archive (.zip or .tar.gz); we validate it, put it in place, and restart the server. Only the world save is imported and your current settings stay as they are, so the server name, password and the rest are fields in the form — what each one does is in every option explained. The preparation is unchanged, though: it has to be a complete directory taken after a stop. A save from the in-game hosted mode goes through the converter above first — what you upload here is always a dedicated-server world.