When people move a media library to a new server, they nearly always try to tidy it up at the same time. We’ve done it too, and we’d advise against it.
The reasoning goes: new server, fresh start, so this is the weekend to rename everything and get rid of the duplicates. What tends to happen is that by the end of the day you can’t find the 1080p copy of a film that played fine on the second television, because it looked like a duplicate of the 4K one and you deleted it. Or the folder you called old is now next to one called old-old, and nobody remembers which is which.
So do less at the start. The only thing you need to find out in the first pass is whether the new catalogue understands the library you already have. You can tidy it later, once you can see what it got wrong, and the tidying will go faster for it.
Treat the files as the archive and the catalogue as the index
Your folders and media files are the thing you should be protecting. A media server builds an index around them: artwork, metadata, playback history and a much easier way to find something to watch. That index can be rebuilt. A file you accidentally replaced with a smaller encode can’t.
Before connecting a new server, make sure you still have an independent backup of the files that matter. Then leave the existing folder structure in place for the first pass. Don’t move a library between drives, rename hundreds of items and change server software in the same afternoon. If something looks wrong, you’ll want to know which change caused it.
Use stable, final paths and give the server account read access to them. A NAS share that appears under a different drive letter every other reboot is a support problem waiting patiently for you, and it will still be there after the migration.
Start with the files that tend to cause trouble
Don’t begin with the whole library just because the scan button is there. Pick a small, awkward sample instead: a film with an ordinary title, one with a remake, a television episode, a large remux, a title with external subtitles and something with two cuts or resolutions.
The names don’t have to contain every detail from the encode. They do have to tell a human being what the item is. Title and year do most of the work for films; a season and episode marker does the same for television.
Films/
The Thing (1982)/
The Thing (1982) - 2160p HDR.mkv
The Thing (1982) - 1080p SDR.mkv
TV Shows/
Andor (2022)/
Season 02/
Andor (2022) - S02E03 - Harvest.mkvIf an item still looks ambiguous, pause there. Check the year, the edition and the actual file before telling a server to match it. A clean catalogue with a few items waiting for review will always beat a confident-looking catalogue built on the wrong film.
A duplicate is sometimes the sensible copy
There’s a particular kind of tidying that always feels productive: deleting the file that seems redundant. Be careful with that instinct.
Do you need both the 4K and the 1080p? Often you do. The 4K HDR source might be perfect in the living room, while the lighter 1080p copy is the one that plays directly on an older screen or over a less forgiving network. An extended cut, a theatrical cut and a version with a different language track each answer a different question, and none of them is a failed duplicate.
Keep the distinction visible in the filename, where future-you will find it. Director's Cut, Extended, 2160p HDR, 1080p SDR and a meaningful audio-language suffix will usually be enough. Future-you should be able to see why that file exists without reading a technical report.
Scan, look, then press Play
After the sample looks right, expand the scan. Keep an eye on uncertain matches, whatever the success rate says. The titles that will need attention are normally the ones with a generic name, a missing year, a foreign release title or a strange edition marker.
Then test playback. Pick the same awkward sample and try the things a library actually has to survive: resume, the source selector, subtitles, one direct-play route and one route that has to adapt to a different device. A successful scan only proves that the server can read the folders. It doesn’t yet prove that it can give the household the version of the film they expected.
Quven’s ordinary scans build a catalogue from the folders you choose and leave the source media in place. Multiple physical sources can sit under one title, and Alternate editions lets the viewer choose the version to play. That’s useful, but it isn’t a license to stop checking the library. The server can group and label files; only you know whether the 70 GB copy is there because it’s precious or because you forgot it existed.
Bring the watch history with you
The files are the easy part of a migration. What people actually miss is the record of what they had already seen: the series they were three episodes into, the film they finished last winter, the playlists somebody built over years. Nobody wants to spend an evening retyping it.
If the old server is Plex or Jellyfin, Quven can read it directly. From the desktop app or the web client, point the import at the existing installation; Quven finds its database, shows you what it’s about to bring over, and then transfers watched state and playlists. Titles are matched by catalogue identity, so a library you’ve already reorganised will still line up. This needs Quven 1.1.4 or later (1.1.5 on macOS), and it reads the old server without modifying it, so you can run the import while the previous setup is still standing.
Two things worth knowing before you start. It brings watch state and playlists, not artwork choices or server settings, which belong to the new server anyway. And a title the old server never matched correctly has nothing to attach its history to: correct the match in Quven first, then import.
Keep the way back open for a while
Leave the previous setup alone until the new one has survived a few ordinary evenings. You’re looking for mundane confidence: somebody can find a series, the right episode starts, a subtitle file turns up, and nobody asks where the old version went.
Once that’s true, you can improve names or remove genuinely unnecessary files in small, reversible batches. A good migration is the moment when the library becomes easier to live with, and the history already stored on the disks comes along with it. Perfect folders can come later, or never.
For a fresh naming structure, read how to organise films and TV shows. To understand what the server is choosing at playback time, read why native playback changes server load.
Frequently asked questions
Do I have to rename my files first?
No, and the first pass is the worst moment to try. Leave the folder structure where it is and let the new catalogue tell you what it understood; renaming and switching servers in the same evening leaves you with nothing to compare against.
What should be ready before I connect the new server?
An independent backup of the files that matter, stable final paths, and read access for the account the server runs as. A share that appears under a different drive letter every other reboot will be a support problem long after the migration is over.
Where do I start the first scan?
On a small awkward sample: a film with an ordinary title, one with a remake, a television episode, a large remux. If those come out right, the rest will.