Match this symptom
The destination starts a clean map or asks for new accounts even though the source Multiplayer save was copied to the new PC or host.
The answer first
Stop before the fresh server saves more state. Project Zomboid selects its configuration, save, and account database with -servername under a specific -cachedir. Restore the complete owner-named set and launch with the exact source identity, not just the Multiplayer folder.

Preserve the accidental new identity
- 1Use console quit if available and wait for the Java process to exit.
- 2Copy the newly generated Server files, Saves/Multiplayer folder, db file, and log into quarantine.
- 3Preserve the source export and last known-good backup unchanged.
- 4Save both source and destination startup commands for comparison.
Compare the identity pair
- Exact -servername value, including spelling and capitalization used by the file family.
- Exact -cachedir value; without one, Windows normally uses the user's Zomboid cache.
- Windows service account, whose profile can change the default cache root.
- Build/branch and StartServer64.bat location.
Restore more than the map
Copy <servername>.ini, SandboxVars and spawn Lua files under Server; the complete Saves/Multiplayer/<servername> directory; and db/<servername>.db from one stopped snapshot. Include native backups, logs, and the exact WorkshopItems/Mods records. A map without its database can restore terrain while losing accounts, whitelist, bans, or access levels.
Launch the recovered identity privately
- 1Use the exact source server name and explicit destination cache root.
- 2Check the startup log for the intended INI, save, and Workshop/mod lists.
- 3Join with a known account and verify map location, character, ownership, and admin access.
- 4Run console save, then quit, restart, and confirm persistence.
Prevent profile-dependent data loss
Keep -cachedir explicit in the managed startup definition so switching from an interactive user to a Windows service cannot silently select another profile's Zomboid folder. Back up by owner name and cache root together, and test the restoration process before the next host move.
Trace the fresh world to the exact selector
Compare the first destination log with the source log and note the resolved cache directory, server name, save path, database path, and port. If the service account's profile created a second Zomboid folder, its timestamps will normally align with the first failed destination start. Preserve it as evidence; deleting it before correcting the service can cause the same empty identity to be generated again with no clue why.
Once the source identity is restored, confirm that the files changing during console save are inside the intended explicit cache root. Then stop with console quit and ensure the database timestamp advances consistently with the world. This write-location check is stronger than seeing a familiar map once, because a server can read copied chunks while writing accounts or subsequent state into a different owner-named family.
