Move a copy of the factory first, then prove the destination loads the right checkpoint. Keep the original playable until that check survives a server restart. Uploading one .sav transfers a world; it is not an automatic transfer of the old server's configuration, credentials or blueprint library.
This guide covers an unmodded PC save moving to an existing native Linux dedicated server. The example destination follows our Ubuntu setup: service satisfactory.service, account satisfactory, HOME /home/satisfactory, installation /home/satisfactory/server. Containers, Windows services and alternative accounts need their actual storage paths. Console save extraction and mod removal are outside this procedure.
Establish a checkpoint before changing hosts#
On the source, stop building and create a uniquely named manual save, such as factory-before-move. Record its session name, playtime and an unmistakable observation: a labelled storage container at the hub with known contents works better than “the factory looks familiar.” Exit the local session after saving. On an old dedicated server, save and arrange a maintenance window before taking its final copy.
Record the game branch and build on both sides. Use a destination build compatible with the save, with matching client/server versions. Do not treat switching a newer Experimental save to an older stable build as a conversion method. Preserve a copy made before any upgrade; a renamed file does not change its internal format.
For Windows PC saves, start at %LOCALAPPDATA%\FactoryGame\Saved\SaveGames, then inspect the appropriate account-ID folder. The save documentation distinguishes these from dedicated-server storage. Do not select whichever account directory happens to appear first. Confirm the chosen file in the game's load list and copy it somewhere outside the game-managed directory.
Discover the destination's storage owner#
Before copying server files, inspect its real unit:
sudo systemctl cat satisfactory.service
sudo systemctl show satisfactory.service \
-p User -p Group -p Environment -p WorkingDirectory -p ExecStart
The upstream service environment reference explains why a service's identity can differ from your SSH login. Confirm any HOME override and the account's home directory; with a running instance, inspect its process environment privately if the unit leaves this ambiguous. Account defaults alone do not prove a wrapper uses them.
For the example installation, native server worlds belong under /home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/server. This is a default resolved against the service account, not a directory relative to wherever you run scp. Verify that known existing saves are there. If this server already contains another factory, preserve its checkpoint and persistent data before replacing anything.
Prefer the game's upload flow#
Start the destination normally and authenticate as its administrator in Server Manager. Under Manage Saves, use the local-save upload action documented in the dedicated-server guide. Select the preserved checkpoint rather than an earlier autosave. Uploading through this interface is an online management operation; it does not require manually copying files into a running data directory.
Once the upload completes, explicitly select and load the intended session and save. Keep players out during this change: loading a different checkpoint replaces the currently running world. A visible file in a list is not evidence that the server loaded it.
If the upload fails, retain the source and inspect the error and server logs before retrying. First distinguish an unavailable management connection from a save rejected during loading. Connection problems belong to the connection checklist; repeated uploads do not repair a firewall or incompatible build.
Use a stopped file copy only when necessary#
For a filesystem transfer, first make a manual save of any destination world being retained. Stop through its service manager and verify that the game process has exited; for this example:
sudo systemctl stop satisfactory.service
sudo systemctl show satisfactory.service \
-p ActiveState -p SubState -p MainPID -p Result
sudo journalctl -u satisfactory.service -n 80 --no-pager
Proceed only with an inactive unit, no remaining game process and no shutdown failure. The unit must already use the game's graceful shutdown method; service guidance specifies SIGINT and warns that shutdown does not itself save. Investigate a forced timeout rather than treating it as a clean checkpoint.
Copy the selected .sav into the verified server directory while stopped. Avoid replacing an identically named destination file: preserve it first or use a distinct filename. Give the copied file to the destination service user/group and ensure that user can read and write it. Do not recursively change ownership of the entire installation to fix one imported file. Start the service, authenticate, then select the save in Manage Saves.
Bring blueprints and verify the move#
PC blueprints are separate files: preserve .sbp and associated .sbpcfg files. Match the internal session name, not a newly invented name based on the save filename. In this Linux example, inspect SaveGames/blueprints/<session> alongside the server directory. Copy the source session's blueprint files with the destination stopped, keep existing destination files separately and restore their service ownership. Reload the save afterwards. An absent directory may simply mean no blueprint has been created for that session yet.
Join with the expected player account. Check the hub marker, progression, inventory and a known blueprint. A fresh character or missing library needs investigation before anyone continues building; do not delete apparently old player data as a first fix. Configure administrator/player passwords and automatic session loading deliberately on the destination. Importing a world does not establish its server identity.
Finally make a new named save, restart gracefully and join again. Confirm the same factory and checkpoint, and that the destination can write subsequent saves. Only then announce the new address and archive the old host. Keep the untouched source copy and a separate recovery backup beyond the first successful session.
