What to Verify Before Switching Media Platforms

The safest way to switch media platforms is to treat the migration like a post workflow rather than a file copy. You are moving the working memory of your team. That means clip names and rights notes, review history and access rules, and the folder logic that helps a producer find the right shot six months later. It also means the proxies, captions, and transcripts hanging off each asset. Any vendor can demo a clean sample folder. The question is whether your real library survives the move in a form your editors, assistants, and post supervisors can work in on a live job.

Migration area	Ask the vendor	Prove it in the pilot
Metadata	Will custom fields, embedded metadata, rights notes, captions, transcripts, and technical metadata remain searchable and exportable?	Search for known values and confirm they land in usable fields, not a generic notes dump.
Version history	Will prior versions stay connected to the current asset with comments, approvals, timestamps, and owners intact?	Open a real version stack and confirm reviewers can tell which notes and approvals belong to which cut.
Permissions	How will internal roles, external reviewers, folder access, download rights, expired links, and view-only rules map?	Log in as a producer, assistant, client, and reviewer to confirm each user sees only what they should.
Folder structure	Will the full folder tree, empty template folders, original paths, long names, and duplicate names survive?	Compare the migrated project against the source and confirm assistants can still find assets where they expect them.

Start with one representative project

Don't begin with the whole library, and don't test with a tidy folder someone made for evaluation. Pick one real project that has the normal messiness of your workflow.

Use one real project with the normal workflow mess, not a sanitized sample folder.

A good test project includes:

Camera originals or high-res masters
Proxies or mezzanine files
Multiple cut versions
Review comments or approval notes
Custom metadata fields
Rights or usage restrictions
A nested folder structure
A mix of file types, including stills, audio, captions, graphics, and project files
Internal users, external reviewers, and client access

Any platform can upload files. The pilot exists to prove that the relationships between those files survive:

Which proxy belongs to which master
Which version replaced which edit, and which comments belong to which version
Which folder rules carry meaning for your assistants
Which people should still have access, and to what

Run this pilot early, while you still have negotiating room with the vendor. If the test exposes problems, you want time to change the migration plan, adjust field mapping, or decide that the platform isn't a fit.

Metadata is where migrations break

Most media teams don't realize how much they rely on metadata until it disappears. Filename and upload date move cleanly. The fields that break are the ones your team invented over time. Ask the vendor how the new platform will import and store each type of metadata, how your team will search it, and how your team can export it later. That includes both embedded file metadata and platform-level metadata. The fields worth testing include:

Clip name, reel name, scene, take, camera, shoot date, and timecode
Custom tags, labels, campaign names, show names, and episode numbers
Rights notes, territory restrictions, expiration dates, and talent usage limits
Transcript text, speaker labels, captions, and subtitles
Approval status, air status, legal status, or archive status
Original path, source platform ID, and any unique asset identifier
Technical metadata like codec, resolution, frame rate, audio channel layout, and duration

Ask the vendor to show you exactly where the platform stores each field, how users will search it, and how your team can export it again.

Metadata should stay attached to the asset in structured, searchable form.

For post teams, identifiers matter. Reel names, timecode, and source file names often connect offline edits, proxies, masters, and conform workflows. If the migration flattens, renames, or treats those values as generic tags, the platform may still look organized while becoming less useful for editorial. If your current system has custom fields, ask whether the new platform supports the same field types. A dropdown, a multi-select tag, and a rights window are not interchangeable with each other or with free text. Migrating everything into a notes field preserves the words and destroys the filtering, reporting, and automation built on them.

Version history needs more than the latest file

A lot of platforms can migrate the current version of a file. Fewer preserve the version stack in a way that still makes sense to a producer reviewing a trailer, an episode, or a social cut. Ask how the platform handles existing versions during migration. You want to know whether versions remain connected or become separate standalone files. Test the cases your team actually uses:

Rough cut, fine cut, locked cut, textless, final, and revised final
Client review versions with comments attached
Assets with the same filename uploaded at different times
Versions that changed format, such as ProRes to H.264 review file
Old versions that should remain viewable but not downloadable
Approval states attached to specific versions, not just the asset as a whole

Version history is your accountability record. If a client approved V4 and the platform only shows the latest upload, that approval is gone. If comments from V3 land on V5 with no separation, reviewers reopen notes that were already settled. If renamed files break the stack, assistants spend days rebuilding the history by hand. A usable migration keeps versions linked to each other, keeps the timestamps, and keeps the review context around each one. It should also carry the uploader or owner wherever the old platform exposed that. If the vendor can't preserve all of it, get the specific gap in writing before you commit.

Permissions rarely map perfectly

Permissions are the easiest area to underestimate. On paper both platforms support admins, reviewers, and external users. Underneath those shared labels, the two permission models can behave very differently. Ask the vendor to map your current permission structure into their model before migration, and don't wait until after the files arrive. The mapping should cover:

Internal admins, producers, editors, assistants, legal, marketing, and archive users
External clients, agencies, vendors, freelancers, and reviewers
Folder-level access
File-level access
Share links and their expiration dates
Download permissions
Watermarking or view-only restrictions
Approval permissions
Revoked users and inactive accounts

The hard part is preserving intent. If a client could only view a specific folder, they shouldn't suddenly see the whole project. If a freelance editor had upload rights but not admin rights, that distinction should survive. If legal had access to rights-restricted material but marketing didn't, the migration shouldn't flatten those roles into a single “team member” permission. Be especially careful with inherited permissions. Some platforms apply access from a parent folder down through every subfolder. Others allow exceptions at lower levels. If your existing library depends on those exceptions, the migration can accidentally open or block sensitive material. During the test migration, log in as a few real user types instead of inspecting the admin view. Check the producer view. Then the assistant view, the client view, and the external reviewer view.

Check permissions from real user perspectives, not just the admin view.

Folder structure is more than cosmetic

Folder structure carries meaning. It tells assistants where to drop new media and editors where to find proxies. It tells producers which assets are approved and archive teams how the project was delivered. Ask whether the new platform preserves the full folder tree, including empty folders if your team uses them as templates. Then ask how it handles illegal characters, duplicate folder names, and long paths. A migration can look successful while still damaging the folder logic. Common problems include:

Flattened folder trees
Renamed folders due to unsupported characters
Duplicate folders merged together
Empty template folders omitted
Files moved into generic “Imported” folders
Original paths lost
Sort order changed in a way that disrupts assistant workflows

For post-production teams, the original path stays useful after the move. It traces where an asset came from, rebuilds broken references, and lets you compare the migrated library against the source. If the new platform can't preserve the exact path as structure, ask whether it can preserve it as metadata. This is also where you should test mixed media. A real project folder holds camera media and exports alongside cue sheets, audio stems, and NLE project files. Make sure the platform accepts every file type you actually store, not just the video files it can preview.

Watch for proxy, master, and conform assumptions

A media platform migration isn't the same as moving an NLE timeline, but the same lesson applies: interchange formats and migration tools only carry the data their designers built them to carry. If a vendor says “we preserve everything,” ask what “everything” means in technical terms. For editorial and finishing teams, the risk sits in relationships and references:

Proxy-to-master relationships
Source filename consistency
Timecode and reel metadata
Sidecar files such as captions, LUTs, XMLs, AAFs, EDLs, and CSVs
Review files connected to high-res masters
Watermarked screeners connected to clean exports
Audio stems connected to picture versions

If your team ever conforms, relinks, or references old edits, the migration must not strip the data that makes those jobs possible. The platform doesn't need to be an NLE. It does need to stay out of the way of one. This is another reason to test with a real project, because a sample folder won't reveal whether the migrated library still supports the way your assistants prep, track, and hand off media.

Ask how the migration will actually run

Once the pilot looks good, ask for the migration plan in writing. It should explain how the data moves, how long it will take, and who owns each task. It should also say how your team and the vendor will validate the result. You want practical answers to questions like:

Will the vendor pull from the old platform, receive a drive, or require your team to upload?
Can the migration run incrementally, or does it require a hard cutover?
Who retries failed files, and how?
How does the vendor or platform detect duplicates?
What happens to files that the new platform can't preview?
How will your team or the vendor use checksums or file counts to confirm completeness?
What reports will you receive after each batch?
Can users keep working during migration, or does the library need to freeze?

For large media libraries, time estimates need to include more than bandwidth. API limits and throttling cap the real transfer rate, and small-file overhead punishes high file counts. Transcode or proxy generation, metadata import, and human review each add their own pass over the library. A 200 TB library made of huge camera files behaves differently from a 20 TB library with hundreds of thousands of thumbnails, sidecars, and small exports. File count can be as painful as file size.

Define the cutover in human terms

The technical migration may finish before the team is ready to work in the new platform. Plan the cutover around active productions, delivery deadlines, and client approvals. For many teams, the cleanest path is a phased move:

Migrate and validate one completed project
Migrate a small group of active projects
Freeze changes in the old platform for a defined window
Move the remaining library in batches
Keep the old platform read-only for a short overlap period

The overlap period matters because it gives assistants and producers time to compare projects, catch missing metadata, and answer the inevitable “where did this go?” questions without blocking active work. Don't let both systems stay editable for too long, though, because that creates split-brain problems where comments, versions, and approvals live in two places. If you need an overlap, make the rules clear: one system is the source of truth, the other is reference-only.

Know what happens if you leave later

A platform switch is also the moment to ask about your next exit. That may feel premature, but it's much easier to negotiate and understand export terms before you sign than when you're already trying to leave. Ask what your data looks like on export, including the structure and context around the media files.

Exit terms should produce an organized export, not loose disconnected files.

The exit discussion should cover:

Original media export
Proxy and preview file export
Folder structure export
Metadata export format
Version history export
Comment and approval history export
User and permission export
Rights data export
Captions, transcripts, and sidecar files
Audit logs or activity history
Costs for bulk export, storage retrieval, or support
Timeline for account access after cancellation

If the answer is “you can download your files,” keep asking. That is fine for a simple storage bucket and nowhere near enough for a production media library. You need to know whether the exported data drops into another system or arrives as a pile of files plus a few CSVs that only make sense after weeks of cleanup. Also ask whether the platform keeps any proprietary-only data. AI tags, review annotations, and approval states can be useful inside the system and hard to move out. That doesn't automatically make the platform a bad choice. It does tell you which parts of your workflow become platform-dependent.

Making the decision

A media platform is ready for your library when it can prove four things with your real project:

Metadata shows up in usable, searchable fields
Version history remains intelligible to whoever reviews it next
Permissions preserve intent for every user type
Folder structure comes out intact

If any of those fail, you pay for it in migration cleanup, weaker search, and manual reconstruction by the people who are already carrying too much of the workflow. Slower editorial prep, confused approvals, and rights exposure come with it. The best vendor conversations are specific. Bring one messy project. Ask them to migrate it. Open it as different users. Search for known metadata. Compare the version stack. Check the folder tree. Export the result. Then decide based on what survived.

FAQ

Run a pilot migration with one real project that reflects your normal workflow. It needs version stacks, review comments, and custom metadata, plus nested folders and real user permissions. A clean sample folder won't reveal whether the new platform can preserve the relationships your team depends on. Aspect provides complimentary migration from any cloud or local platform and preserves metadata, folder structure, rights, and version history.

It depends on how the vendor maps it. Filename and upload date are usually simple. Everything your team built by hand needs testing: custom fields, rights data, and approval states, along with timecode and reel names. Ask where each field will land, whether it stays searchable, and how it can be exported later.

Version history preserves the context behind approvals, comments, revisions, and delivery decisions. If only the latest file migrates, producers and reviewers may lose the record of what changed, who approved which cut, and which comments applied to each version.

Not always. Two platforms can use the same labels, such as admin, member, and reviewer, and still run very different permission models underneath. The goal is to preserve intent: who can view, who can download or upload, and who can approve. Test by logging in as different user types, not only as an admin.

Ask how the media itself exports, then how the context around it exports: folder structure, version history, and comments. Cover permissions, rights data, captions, transcripts, and audit history in the same conversation. Then ask what bulk export costs, which data is proprietary, and how long you keep account access after cancellation.

Run a pilot on one real project. It should carry version stacks, live permissions, and custom metadata, along with review notes, rights fields, and mixed media types. Aspect supports migration from cloud or local platforms and preserves metadata, folder structure, rights, and version history as part of its supported migration.