How should you sequence a DAM migration cutover?

Migrate metadata first, binaries second, and permissions last. Run the old and new systems in parallel for one complete campaign cycle before decommissioning anything, and set the cutover date with the team that has the heaviest seasonal load rather than with IT.

This order follows reversibility. A wrong binary copy is re-runnable. A wrong metadata mapping silently corrupts search for every asset it touched, and it is usually discovered months later when a specific asset cannot be found. Permissions come last because they depend on both of the other two being settled.

Metadata carries the meaning; the binary is just a file. If your controlled vocabulary does not survive the move, the new system is a very expensive folder tree.

Map fields explicitly rather than relying on an automatic match, and account for the three cases that break automatic mapping: a free-text field in the old system feeding a controlled list in the new one, a single field that encoded two concepts, and a date stored as text. Align to a published schema rather than inventing one. The usual anchors for image workflows are the IPTC Photo Metadata Standard, whose 2024.1 revision was released in June 2024, and Adobe XMP, standardised as ISO 16684-1 (first published 2012, revised 2019). For rights and licensing, IPTC added the Data Mining property in the 2023.1 revision, which is what carries AI training permissions.

• Field mapping sign-off: by the people who search, not the people who migrate.
• Vocabulary reconciliation: decide the merge rule for near-duplicate terms before load, not after.
• A held-back sample: 200 assets loaded first and searched by real users.

Run both systems until one complete cycle of your actual work has passed through the new one. For most marketing organisations that is a quarter; for a seasonal retailer it is a full season.

The reason is that a DAM is exercised by the calendar, not by a test plan. The asset types that break a migration are the ones used once a cycle: the annual report layout, the seasonal campaign master, the regulated product shot with an expiry date attached. A two-week user acceptance test never touches them, so a parallel run is the only test that does.

Rebuild permissions from effective access rather than copying group names. Group names drift over the life of a system: a group called brand-team often no longer contains the brand team, and copying it forward carries a decade of drift into a system meant to fix it.

The practical method is to export who can actually reach what today, agree the intended model against that export, and only then map to groups in the new system. Where the assets carry personal data, the retention side matters too: under GDPR Article 5(1)(e) storage limitation applies to the asset itself, not only to the record about it, so a migration is the moment to apply a retention rule rather than to carry everything across by default.

Check the assets, not the counters. A migration report saying 412,000 of 412,000 objects transferred confirms that a copy loop completed, which is not the same claim as the assets being findable, renderable and correctly attributed in the new system.

Three checks that catch what counters miss. Search for twenty assets by the terms real users would type, not by filename. Render a derivative of the largest and the oldest file formats in the set, because those are where format support gaps appear. And pick ten assets with rights or expiry metadata and confirm those specific fields survived, since rights fields are the most commonly dropped in an automatic mapping and the most expensive to lose.

Can we migrate binaries first to get the bulk transfer out of the way?

You can, and it is often operationally convenient, but only if the metadata mapping is already signed off. The risk is not the order of the copy, it is starting the copy before the mapping is settled and then re-running it against changed field definitions.

How long should the old system stay available after cutover?

Keep it readable, not writable, until one further cycle has passed. Making it read-only at cutover is what stops the two systems diverging while people find their footing.

Who should own the cutover date?

The team with the heaviest seasonal load. If that team cannot absorb a bad week on the chosen date, the date is wrong regardless of what the project plan says.

What is the most common avoidable failure?

Permissions migrated from group names rather than from effective access. Group names drift over years, so rebuild permissions from who can actually reach what today, then reconcile to groups afterwards.