How Do You Migrate to a New DAM Without Losing Assets, Metadata, or Your Mind?

Commercial interest disclosure: The DAM Republic is a vendor-neutral DAM hub. We do not sell migration services, DAM platforms, or implementation consultancy. This article exists to help practitioners navigate migration decisions independently. Where we link to vendor resources or tools, those links are editorial, not sponsored.

What this article covers: pre-migration auditing, data mapping, phased cutover planning, validation sampling, and post-migration governance for DAM programmes of any size.

What this article does not cover: DAM platform selection (see the TdR DAM Vendor Evaluation Framework), metadata schema design from scratch (see the TdR DAM Metadata Governance resources), or vendor contract negotiation. It also does not cover migrations involving regulated records subject to sector-specific retention law (e.g. healthcare, financial services), where legal counsel should be involved from the outset. The timelines and sample sizes referenced in this article are practitioner estimates drawn from common programme patterns; they are not guaranteed benchmarks and should be calibrated to your organisation's risk tolerance and asset complexity.

The most expensive mistake in a DAM migration is moving everything. Legacy systems and shared drives accumulate years of duplicates, expired assets, superseded brand materials, and files with no metadata at all. Migrating them uncritically means paying to store, index, and maintain content that should have been archived or deleted.

A pre-migration audit has three outputs: a keep list (assets that will migrate to the new DAM), an archive list (assets that have business or legal retention requirements but do not need to be actively searchable), and a delete list (assets that are expired, duplicated, or have no ongoing value). The audit should be done by asset type, not asset by asset: define the criteria for each category at the type level, then apply them systematically.

For rights-bearing assets, the audit is also an opportunity to flag files where licensing or rights metadata is missing or ambiguous. Those assets should be reviewed by a legal or rights representative before migration, not after. Migrating an asset with unknown rights status into a new, more accessible system increases exposure, not reduces it.

Budget for the audit explicitly as a distinct project phase. It is not a task that can be safely parallelised with the technical migration without introducing errors, and compressing it is a common source of post-migration remediation work.

Once you know what is migrating, the next task is defining exactly how it migrates. The data-mapping document is the most important artefact in any DAM migration and the one most often skipped or treated as a technical detail rather than a business decision.

A complete data-mapping document covers every metadata field in the source system. For each field, it records: the source field name and type, the destination field name and type, the transformation rule (if the field values need to be reformatted, split, merged, or translated), and the decision for fields with no destination equivalent. That last category is where migrations go wrong: fields that do not map cleanly are often silently dropped, taking years of tagging work with them.

Common mapping decisions

• Direct map: the source field maps cleanly to a destination field with the same semantics and compatible values. No transformation needed.
• Transform: the source field maps to a destination field but values need reformatting (e.g. a date field in MM/DD/YYYY format migrating to a system that expects ISO 8601 YYYY-MM-DD).
• Concatenate: two or more source fields merge into a single destination field (e.g. separate 'first name' and 'last name' fields merging into a 'creator' field).
• Split: a single source field splits into multiple destination fields (e.g. a free-text 'keywords' field splitting into controlled taxonomy values).
• Archive as note: the source field has no destination equivalent but the value has business value; it is migrated as a free-text note or appended to a description field.
• Discard: the source field has no destination equivalent and no ongoing business value. The decision to discard must be documented and signed off, not assumed.

The data-mapping document should be reviewed by the DAM manager, a representative from the primary user group, and a legal or rights representative for any fields touching licensing, expiry, or talent release data. Sign-off before migration begins is the mechanism that prevents metadata loss from being discovered after the legacy system is decommissioned.

For metadata field standards, the DCMI Metadata Terms specification and the IPTC Photo Metadata Standard (for image libraries) provide stable, platform-neutral vocabularies that most DAM platforms support natively and that simplify field mapping considerably.

A big-bang cutover, where the legacy system is switched off on a Friday and the new DAM goes live on a Monday, is the highest-risk migration approach and the one most likely to produce a support crisis in week one. A phased cutover reduces risk by moving asset classes or business units incrementally, validating each phase before proceeding, and maintaining a parallel-run period where both systems are accessible.

Structuring the phases

Phase the migration by asset type or by business unit, not by volume. Moving all photography first, then all video, then all brand templates is easier to validate than moving an arbitrary file count regardless of type. Each phase should have a defined scope, a validation checklist, a rollback plan, and a go/no-go decision point before the next phase begins.

The parallel-run period

During the parallel-run period, both the legacy system and the new DAM are live. New assets are ingested into the new DAM only; the legacy system is read-only. Users can access both systems, which gives them time to validate that the assets and metadata they rely on are present and correct in the new system before the legacy system is decommissioned. A parallel-run period of several weeks is typical for most migrations; larger or more complex programmes may need longer. Define the duration based on your user base's capacity to validate, not on the project timeline's convenience.

The parallel-run period is also the primary change-management window. User training, feedback sessions, and support resources should be concentrated here, not deferred to after cutover. Adoption problems that emerge during parallel run are recoverable; adoption problems that emerge after the legacy system is gone are not.

Migration validation is the step most often compressed under project pressure, and the compression is almost always regretted. A migration that moves files without validating metadata completeness, file integrity, and rendition accuracy has not been validated; it has been counted.

Stratified sampling

Validate using a stratified random sample: select assets across asset types, source systems, and metadata completeness levels, then check each sampled asset for file integrity (a checksum or hash comparison against the source file), metadata completeness (every mapped field is populated with the correct value), and rendition accuracy (thumbnails, previews, and derivatives are correct). Set your sample size and failure thresholds based on your programme's risk tolerance; the key is to define them before migration begins, not after results come in. Any failure rate above your defined threshold should trigger a full review of that asset class before cutover is confirmed.

Quarantine and remediation

Assets that fail automated migration should be quarantined in a dedicated holding area with a clear status flag, not silently dropped from the migration. Each quarantined asset needs a manual review decision: remediate and migrate, archive outside the DAM, or delete. The quarantine list should be reported to asset owners before the legacy system is decommissioned.

Post-migration audit

Schedule a post-migration audit at 30 and 90 days after cutover. The 30-day audit checks for user-reported findability issues and metadata gaps that sampling did not catch. The 90-day audit checks search success rates, tag usage patterns, and whether any shadow metadata practices have emerged (users adding workaround tags because the migrated taxonomy does not match their mental model). Both audits feed directly into the ongoing metadata governance programme.

Migration readiness checklist

• Pre-migration asset audit completed with keep, archive, and delete lists signed off
• Data-mapping document completed and reviewed by DAM manager, user representative, and legal
• Rights and licensing fields flagged for manual review where metadata is missing or ambiguous
• Phased cutover plan documented with scope, validation checklist, and rollback plan per phase
• Parallel-run period defined with duration based on user validation capacity
• Validation sampling framework defined with sample size and failure thresholds agreed before migration begins
• Quarantine process defined for assets that fail automated migration
• User training and communication plan running in parallel with technical workstream
• Post-migration audits scheduled at 30 and 90 days

DAM migration is a change-management event as much as a technical one. The teams that get it right treat both dimensions with equal seriousness from the start.

How long does a DAM migration typically take?

Migration timelines vary significantly by asset volume, metadata complexity, and the number of source systems involved. A focused migration of under 50,000 assets from a single source with clean metadata can complete in a matter of weeks; enterprise migrations spanning multiple legacy systems, inconsistent metadata, and large video libraries routinely run many months. The audit and data-mapping phases alone tend to account for a substantial share of total project time. These are practitioner estimates based on common programme patterns, not guaranteed benchmarks.

What is a data-mapping document in a DAM migration?

A data-mapping document is a structured record that lists every metadata field in the source system, its equivalent field in the destination DAM, the transformation rule applied (if any), and the decision for fields with no destination equivalent (migrate as a note, archive, or discard). It is the single most important migration artefact and should be reviewed and signed off by both the DAM manager and a legal or rights representative before migration begins.

How do you validate a DAM migration without checking every asset?

Use a stratified random sample: select a representative sample of assets across asset types, source systems, and metadata completeness levels, then verify file integrity (checksum or hash comparison), metadata completeness, and rendition accuracy for each sampled asset. A sample in the low single-digit percentage range, stratified by type, is a common starting point. Any failure rate above a defined threshold should trigger a full review of that asset class before cutover. Set your own threshold based on the risk tolerance of your programme.

What happens to assets that cannot be migrated automatically?

Assets that fail automated migration (due to corrupt files, unsupported formats, or metadata that cannot be mapped) should be quarantined in a dedicated holding area, not silently dropped. Each quarantined asset needs a manual review decision: remediate and migrate, archive outside the DAM, or delete. The quarantine list should be reported to asset owners before the legacy system is decommissioned, so nothing is lost without a deliberate decision.

How do you handle rights and licensing data during a DAM migration?

Rights and licensing data is the highest-risk metadata category in any migration because errors can create legal exposure. Map rights fields explicitly in the data-mapping document, involve a legal or rights representative in the field-mapping review, and flag any asset where rights metadata is missing or ambiguous for manual review before it is made available in the new DAM. Do not assume that a rights field populated in the source system is accurate; the migration is an opportunity to audit and correct.