How to Move Plex App Data Without Losing Watch History or Settings

Move the complete Plex server data directory while Plex is stopped, keep the source untouched, and verify the migrated server before deleting or repurposing the old copy.

Plex watch history, metadata, database state, preferences, and other server information live in the server data directory, not in your movie folders. In Docker, that directory is whatever host path or volume you mapped to the Plex configuration path. The safe migration is therefore a state move, not a media-library rescan: freeze writes, copy the right data, preserve ownership, point the container at the new location, and prove the old server identity and viewstate survived.

Protect the source before you move anything

First identify the host path that backs Plex persistent configuration and make a separate backup of it. Do not start by editing the container mount and hoping the new location is correct. Record the current mount, Plex version, server name, media paths, and ownership so you can return to the known-good configuration if the new copy does not start cleanly.

Plex’s server migration guidance explicitly tells users to stop the server before copying its data and notes that migration can have limits, especially across operating systems. It also warns that existing library access granted to other Plex accounts may not always be retained, so shared-user access is a post-migration check rather than something the title should promise unconditionally.

Keep the old data directory read-only or otherwise untouched during the first test. A rollback is easy when the source still exists: stop Plex, restore the original mount, and start the old state. A rollback becomes much harder after you delete the source or let two copies write to the same database.

Stop Plex and copy the complete persistent state

Stop the Plex container and confirm it is no longer writing before the copy begins. Copy the full persistent server data directory to the new storage location. On large libraries, preserve file attributes and consider an archive or filesystem-native copy method that handles the many small metadata files efficiently.

If you are not sure which directory is the real Plex state, use the Plex data-directory reference to distinguish server data from media content. In Docker, the effective location depends on the volume or bind mount you chose, so the container configuration is the final authority for the host path.

After the copy, make the new path owned and writable by the same effective user or group that ran Plex before. A complete copy with wrong permissions can look like data loss because Plex may start against a fresh or partially readable directory. Fix access before you let Plex create new state in the destination.

Point Plex at the new path and verify identity before scanning

Change only the configuration-data mount first; do not simultaneously rename media folders, change network mode, update Plex, and move storage. Start the container and open Plex. The server should appear with the expected name, libraries, posters, watch history, settings, and previous server identity rather than asking you to build a completely new server.

For a NAS migration mindset, the ZimaSpace NAS data migration guide follows the same protection order: back up first, move a defined scope, verify the destination, and only then remove the old copy. That order matters more than whether the move is performed by a UI or a shell command.

Before you run a broad library scan, open several items with known watched/unwatched state and compare them with the source. Check server settings and at least one shared user or managed account. If identity, history, or permissions are wrong, stop here and roll back instead of allowing scans to rewrite more state.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verify persistence across a restart before deleting the old copy

Restart the Plex container and repeat the checks. Confirm that the new mount is still the active host path and that new viewstate changes persist there. Then play an item briefly, stop it, and verify the progress marker survives another Plex restart. That proves the destination is not just readable but is also receiving current writes.

If media paths also changed, migrate those separately and use Plex’s media-location procedure rather than conflating app-state migration with content migration. Keeping the two operations separate makes any failure easier to diagnose and prevents a missing media mount from being mistaken for a lost Plex database.

Delete or repurpose the old app-data copy only after the new location has survived restart and normal use. If shared users or library permissions did not carry over, repair those explicitly after the server state is stable; do not destroy the source just because the core watch history and settings look correct.