Can You Preserve Watched History During a Media Server Migration?
Yes, watched history can be preserved when the migration carries the user database, media identity, and compatible application state into the new server.
Copying movie files alone does not move played flags, resume positions, favorites, user accounts, or per-track choices. Those records live in the media server’s persistent database and are linked to user and media identifiers. The safest route is a complete same-platform instance migration with a consistent stopped backup, matching versions, stable container paths, and an isolated restore test before the destination becomes the active server.
Define Whether You Are Moving an Instance or Changing Platforms
A same-application migration from one host to another can usually preserve the complete server state. A move from Plex to Jellyfin, Emby to Jellyfin, or another platform requires an export, sync service, plugin, or API-based translation because the databases use different schemas and identifiers.
Jellyfin users have requested an easier export for accounts, watch history, and user settings precisely because user data is not a simple media-folder copy.
Choose one route before beginning: full-instance restore for the same media server, or a documented watch-state transfer for a platform change. Do not combine both by partially copying one database into a newly scanned destination.
Back Up the Complete Persistent Server State
Inventory the configuration, database, users, plugins, metadata, certificates, scheduled-task settings, and container environment. Record the running application version, image tag, database location, and all persistent mounts.
Watched state may include more than a boolean. A Jellyfin discussion identifies fields such as played status, play count, playback position, last played date, favorites, and selected streams in the user-data records.
Back up the whole supported persistence set instead of exporting only one table unless no full restore path exists. A partial database transplant can preserve one field while breaking user IDs, media references, schema expectations, or newer migration history.
Stop the Server or Use a Database-Consistent Snapshot
Prevent playback, scans, metadata refreshes, and user changes while the final backup is created. Stop the media-server process before copying SQLite files unless the storage and application support a consistent online backup method.
A Jellyfin backup discussion warns that copying active SQLite files may capture an inconsistent state because the database may be in use during an ordinary filesystem backup.
Record checksums and file sizes after the service stops, then keep the source server unchanged until the destination passes verification. Do not let both servers write to the same database or watch-state sync target during the cutover.
Keep Application Versions and Upgrade Direction Controlled
Restore into the same application version first when possible. Confirm that plugins, database schema, and container paths match before upgrading the destination.
Database migrations can be one-way, and a restored instance may fail when its recorded migration state disagrees with the actual schema. A current Jellyfin issue documents a restored migration-state conflict.
Start the restored server without public client access, read its migration log, and take another snapshot before any upgrade. Never test a newer release against the only copy of the database and then expect the old server version to reopen it.
Preserve Stable Media Paths and Item Identity
Keep the same container-visible paths even if the host disks change. For example, remap a new storage pool to the existing /media/movies and /media/tv paths rather than teaching the destination entirely new library roots.
Changing paths can create new media records or leave stale entries beside the restored ones. A Jellyfin issue connects removed library paths with persistent stale metadata and duplicate continue-watching behavior.
Verify one movie and one episode by file path and internal item identity before launching a full scan. If the destination sees every file as new, stop and correct path mapping before watch-state links are diluted across duplicate records.
Keep Users and Their Identifiers Consistent
Restore users with the database rather than recreating accounts manually under the same display names. A visible username is not proof that the destination user has the same internal identifier.
Manual history restoration commonly targets the user-data table, but the records depend on both user and media references. Moving library locations without losing metadata has therefore required careful path and database handling rather than a blind rescan of moved files.
After restore, log in as each representative user and compare watched flags, in-progress items, resume positions, favorites, audio choices, and subtitle choices. Do not judge success from the administrator account alone.
Use a Sync or Export Route for Cross-Platform Moves
When the source and destination applications differ, export history through a supported plugin, API tool, or neutral service such as a watch-tracking platform. Test a small sample before syncing the full library.
Match users and titles explicitly, and treat episodes, editions, alternate cuts, and renamed files as potential identity conflicts. A movie title alone is too weak when several years or versions share the same name.
Keep an export of the source history even after the first import succeeds. The transfer should be repeatable or auditable so missing users and mismatched titles can be corrected without starting the migration again.
Run an Isolated Restore and Cut Over Only After Verification
Start the destination on a temporary port with scheduled scans, webhooks, and external sync disabled. Verify users, library counts, watched totals, resume positions, playlists, collections, and several randomly selected titles.
The ZimaSpace NAS data migration workflow provides the broader rule: preserve the source until the copied state has been verified from the destination.
The migration is complete only when the restored instance survives restart, paths remain stable, representative users retain their history, and new playback updates the destination correctly. Keep the source offline but recoverable until the new server has passed several days of normal use and a fresh backup.
Recommended products
Support & Tips
More to Read
Why Does a Docker Volume Restore Recreate File Contents but Drop Extended Attributes?
A volume-restore diagnosis covering xattr inventory, tar and Rsync options, namespaces, destination support, privileges, labels, app metadata, and tests.
Why Does a Running Container Keep Its Old Memory Limit After the Compose File Changes?
A memory-limit diagnosis covering live cgroups, restart versus recreation, Compose fields, hard and soft limits, parent scopes, swap, and runtime heaps.
Why Does Restarting a Reverse Proxy Invalidate Every Session for One Self-Hosted App?
A session-loss diagnosis covering restart scope, cookie ownership, secret rotation, cache-backed sessions, sticky routing, auth gateways, and recovery.
