Use a staged migration: preserve Plex state, prove the new media paths, validate the destination, and keep the old server untouched until cutover passes.
A new home server can be faster and cleaner while still losing watch history, server identity, artwork, permissions, or remote access if the move is treated as a media copy. Start by freezing the working source and locating its full application state. Then build the destination around verified storage paths and permissions, test it without destroying the original, and stop the migration whenever expected state is missing.
Freeze the Source Before You Copy Anything
Stop treating the old server as a live source of truth once the migration window begins. Record the Plex version, server name, library paths, container or service configuration, account state, and the location of the full Plex data directory. Keep the original host intact until the destination passes every validation check.
A migration can preserve the media files and still lose watch state stored in server data. Copying media alone is therefore not the same as migrating the server.
Create a rollback point before the first change: a verified copy of app state plus a written way to restart the original host. If you cannot return to the old server without modifying its database or paths, the migration is already riskier than it needs to be.
Preserve Plex State Separately From the Media Library
The durable Plex data directory carries the database, preferences, metadata, artwork, indexes, and other operating state. The media library is a second dataset with its own capacity and backup plan. Copying them as separate units makes it easier to prove which part failed if the new host starts empty or cannot find files.
Watch-history migrations depend on the Plex database, which is one reason user-facing state must be protected before the destination rescans anything.
On containers, also record the host-to-container mapping for `/config` and every media path. On a native install, record the platform-specific data location. Do not let the destination launch repeatedly against a blank directory while you are still deciding where the real state belongs.
Make Destination Media Paths Deliberate
A database can migrate successfully and still point to media locations the new operating system or container cannot access. Keep paths identical when practical, or plan the path change explicitly so Plex is not asked to rediscover the entire library under a surprise mount structure.
If the full server state is not preserved, migration of watched history can become a separate recovery task after the libraries are rebuilt.
Before starting Plex on the destination, mount the storage and confirm the service account can read several real files from every library. If those file-level tests fail, fix storage and permissions first. A Plex rescan cannot repair a missing mount.
Start the Destination in an Isolated Validation State
Bring up the destination without immediately making it the only server your household depends on. Disable or postpone aggressive scans and background jobs until you know the migrated state opens correctly. Verify server identity, library counts, users, playlists, collections, watch status, and several random media items.
Use an explicit validation phase before cutover: compare server identity, library counts, users, collections, watch state, artwork, and representative playback. The destination should match expected state, not merely load the web interface.
If the destination presents a fresh setup wizard, missing libraries, or empty artwork, stop rather than creating replacements. Re-check the data-directory mapping and ownership. Every new write to an unintended blank state makes it harder to distinguish migration data from destination-generated state.
If only one class of state is wrong—such as artwork, permissions, or a single library path—repair that boundary and repeat the same validation set. Do not convert a partial mismatch into a full rescan unless the migrated database itself is proven unusable.
Cut Over Only After Playback and Recovery Both Pass
A successful migration cutover requires local Direct Play, any required transcode, remote access, a second user, a library change, a reboot, and a verified backup of the migrated state.
A safe Plex migration workflow keeps application state, media paths, permissions, and rollback in the same cutover decision. Retire the source only after that complete path passes.
Only after the destination survives the full test should the old server be shut down for good. Keep the source backup through at least one normal maintenance cycle. If a later scan or update exposes missing state, you still have a known-good recovery point rather than a second reconstruction project.
Support & Tips
More to Read

Can Plex Share a GPU With Another Docker Container?
Plex and another container can often access the same GPU, but you must test driver support, device mapping, video-engine load, memory, and recovery behavior.

How to Tell Whether a Plex Error Comes From the Client or Server
Reproduce the same item on another client, compare the session path, then collect server evidence only after scope tells you where the failure actually...

How to Configure Plex Cache and Transcode Temporary Storage
Protect persistent Plex state while placing transcode temp files on suitable local storage, then verify cleanup, free space, and restart behavior.

