How to Migrate From Another DAM Without Losing Metadata

Key Takeaways:

• A DAM migration moves files, metadata, taxonomy, permissions, and usage rights from one digital asset management (DAM) system to another. The files usually transfer without trouble; the metadata is what breaks.
• Metadata survives when you export it separately from the files, map every source field to a target field before you move anything, and validate a pilot batch against the original.
• Plan for the links too. Delivery URLs embedded in websites, apps, and campaigns will break unless you redirect them or migrate on demand.

Most teams switch DAMs for practical reasons: the contract is up for renewal, a merger left them with two systems, or the old platform can’t deliver media fast enough to their sites and apps. Whatever the trigger, the hard part is the same. Copying 200,000 files is a bandwidth problem. Keeping each file connected to its title, product SKU, license expiry date, and campaign tags is a data problem, and it’s the one that decides whether people trust the new system on day one.

This guide walks through a DAM migration in the order you’d actually run it, with a focus on keeping metadata intact. It includes a migration checklist, a planning timeline by library size, and a metadata mapping template you can copy for your own migration.

In this article:

• What Gets Lost in a DAM Migration
• DAM Migration Checklist
• How Long Does a DAM Migration Take?
• How to Map Metadata Between DAMs
• Choosing a Migration Method
• Migrating From Bynder, Brandfolder, Canto, and AEM
• How to Validate a DAM Migration

What Gets Lost in a DAM Migration

Files rarely go missing in a migration. What goes missing is the context around them, because most DAMs store metadata in their own database rather than inside the file. A bulk download from the old system gives you the binaries and leaves most of that context behind.

These are the layers to account for:

• Custom metadata fields. Product IDs, campaign names, regions, and descriptions live in fields specific to your old DAM’s schema. Each one needs an export and a destination.
• Controlled vocabularies. Dropdown and multi-select values (like a list of approved brands or regions) only work if the same options exist in the target system before import.
• Taxonomy and hierarchy. Folders, collections, albums, and sections carry meaning. Some DAMs let one asset sit in several collections, which doesn’t translate directly to a single folder path.
• Rights and expiry data. License terms, talent releases, and expiration dates are often the most important fields to preserve, because losing them creates legal exposure rather than inconvenience.
• Embedded metadata. EXIF, IPTC, and XMP data travels inside the file, so it usually survives. Check whether your old DAM wrote edits back into the file or only into its own database.
• Versions and renditions. Older versions, cropped derivatives, and approval history may not export at all. Decide which ones matter before you start.
• Permissions and users. User groups and access rules need rebuilding in the new system’s model.
• Delivery URLs. Every image or video your website, app, or email templates load from the old DAM’s CDN will break when that account closes.

The embedded metadata inside a file and the descriptive metadata your team added in the DAM need separate handling. The first moves with the file. The second moves only if you export it.

DAM Migration Checklist

Work through the checklist in order: each phase depends on decisions made in the one before it.

Phase 1: Audit and Scope

• ☐ Export a full asset inventory from the old DAM (file name, ID, format, size, folder or collection, created and modified dates).
• ☐ Count assets by type and total storage so you can size the migration.
• ☐ Pull usage or download data to separate active assets from ones nobody has opened in 2+ years.
• ☐ Flag duplicates by file hash or name and decide which copy keeps the metadata.
• ☐ Mark assets with expired rights or retired products for archive or deletion, not migration.
• ☐ List every system that reads from the old DAM: CMS, PIM, ecommerce platform, email tool, creative apps.
• ☐ Confirm the contract end date and how long you’ll keep read access to the old system.

Phase 2: Metadata and Taxonomy

• ☐ Export the old DAM’s metadata schema: every field name, type, and allowed value.
• ☐ Decide which fields to keep, merge, rename, or drop.
• ☐ Build the target schema in the new DAM, including dropdown and multi-select values.
• ☐ Fill in the metadata mapping template for every field you’re keeping.
• ☐ Decide how collections, albums, or sections translate to folders, tags, or metadata in the new system.
• ☐ Map user groups and permissions to the new system’s roles.

Phase 3: Pilot

• ☐ Pick a pilot batch of 500 to 1,000 assets that covers every asset type and every mapped field.
• ☐ Run the pilot with the same method and script you’ll use for the full migration.
• ☐ Compare a sample of pilot assets field by field against the source export.
• ☐ Ask two or three daily users to search for assets they know and report anything missing.
• ☐ Fix the mapping and rerun until the pilot passes.

Phase 4: Migration

• ☐ Freeze or limit new uploads to the old DAM, or plan a delta migration for anything added during the move.
• ☐ Migrate in batches, highest-priority assets first.
• ☐ Log every API response or import result, including failures.
• ☐ Retry failed assets and reconcile counts after each batch.
• ☐ Redirect or replace delivery URLs used by websites and apps.

Phase 5: Validation and Cutover

• ☐ Reconcile total asset counts between source and target.
• ☐ Spot-check metadata, rights fields, and permissions on a random sample.
• ☐ Reconnect integrations and test each one.
• ☐ Train users and publish the new taxonomy and naming rules.
• ☐ Keep the old DAM in read-only mode until validation is signed off.

How Long Does a DAM Migration Take?

A DAM migration usually takes somewhere between a few weeks for a small, clean library and several months for a multi-brand enterprise library. Asset count matters less than you’d expect. The number of metadata fields, the state of existing tagging, and the number of connected systems drive most of the schedule.

Use these ranges as planning guidance, not guarantees:

The file transfer itself is often the shortest phase. Audit and metadata mapping typically take 40 to 50% of the schedule, and validation takes longer than teams budget for. Here’s how a mid-size migration of around 200,000 assets might break down:

Two things stretch timelines more than anything else: discovering mid-migration that a field means different things to different teams, and finding integrations nobody listed in the audit. Both are cheaper to catch in Phase 1.

How to Map Metadata Between DAMs

Metadata mapping is a field-by-field record of where each piece of information in the old DAM ends up in the new one. It’s the single document that prevents metadata loss, because it forces a decision for every field before any asset moves.

Start by exporting the old DAM’s schema and a metadata export of all assets, usually as CSV or through the API. Then fill in one row per source field, using columns like these:

Rules That Prevent Metadata Loss

• Create target values first. Single- and multi-select fields reject values that don’t exist in the list, so build every option before importing.
• Normalize formats. Dates, number formats, and casing differ between systems. Write the conversion rule into the template instead of fixing it by hand later.
• Turn collections into metadata. If an asset belongs to three collections in the old DAM, a single folder can’t hold that. A multi-select field or tags can.
• Keep the source ID. Store the old DAM’s asset ID in a text field on every migrated asset. It’s the fastest way to trace and fix errors, and to match assets during a delta migration.
• Archive what you drop. Keep the full metadata export, even for fields you didn’t migrate, in case someone needs them later.

For background on schema design, see the guides on what metadata is and asset taxonomy.

Choosing a Migration Method

The right method depends on library size, how much of the library is in active use, and whether the old system has a hard shutdown date. Most enterprise migrations combine two methods.

Bulk Migration Through the API

A migration script gives you the most control over metadata. For each asset, it reads the row from your source export, applies the transformation rules from your mapping template, and uploads the file with its metadata in the same request. Cloudinary’s Upload API can take a remote URL or a cloud storage bucket as the source, so files don’t need to be downloaded locally first, and it accepts tags, contextual metadata, and structured metadata as upload parameters.

Cloudinary’s migration guide recommends a few script habits worth adopting with any target DAM: test on a separate environment first, set an explicit overwrite policy, store every API response for troubleshooting, and check for duplicate IDs before upload. For teams who’d rather not write a full script, the Cloudinary CLI includes migrate and upload_dir commands for bulk moves.

On-Demand Migration for Live Delivery URLs

If your website or app loads images directly from the old DAM, a bulk move alone won’t fix those links. Cloudinary’s auto-upload feature maps a folder to a remote URL prefix. The first time someone requests an asset through that folder’s URL, Cloudinary fetches it from the old location, stores it, and serves it from then on. Assets nobody requests never get copied, which keeps a long tail of unused files out of the new library.

The tradeoff is timing. On-demand migration only works while the old source is still reachable, so pair it with a bulk migration of your high-priority assets if the old contract has an end date.

Hybrid Migration

Many teams run a hybrid: bulk-migrate the active assets with full metadata, then use on-demand migration as a safety net for anything still referenced from older pages. This keeps the migration batch smaller and the clean-up work focused on assets people actually use.

Migrating From Bynder, Brandfolder, Canto, and AEM

Every DAM stores metadata and structure a little differently, so the export step is where most source-specific problems show up. The notes below cover what to check in four common source systems before you start mapping.

If you’re still deciding whether to switch, our guides to Bynder alternatives, Brandfolder alternatives, and Canto alternatives compare the options.

Migrating From Bynder

Bynder stores custom metadata as metaproperties, each with a defined list of options. Its CSV metadata export runs from the Asset Bank and can export metadata without downloading the files, but the feature has to be enabled by Bynder’s customer support before admins can grant the permission. Two details matter for mapping: the CSV only includes columns for metaproperties that at least one selected asset uses, and it doesn’t include asset URLs. Export in batches, merge the files, and check that every metaproperty you expect appears as a column.

Metaproperty options map cleanly to single- or multi-select fields in most target DAMs. Recreate the options list first, then import. Bynder’s Asset Report dashboard can export a full asset list to CSV, which is useful for reconciling counts after migration.

Migrating From Brandfolder

Brandfolder organizes assets into sections (each asset belongs to one) and collections (an asset can belong to many), with tags, custom fields, and (on some accounts) labels on top. The biggest structural difference is that a Brandfolder asset can contain several attachments, like a logo asset holding PNG, SVG, and EPS versions. Most target DAMs treat each file as its own asset, so decide whether attachments become separate assets linked by a shared ID or whether you keep only the primary file.

Brandfolder stores each custom field as a key-value pair on a single asset. Admins can set up controlled custom fields with predefined values, but keys added without controls tend to drift, with the same key holding different spellings across assets. Profile every distinct value for each key before you map it to a controlled list. Exports usually run through the Brandfolder API by listing each section’s assets and attachments.

Migrating From Canto

Canto admins can export metadata for the whole library, a folder, or an album to CSV from the Settings page, and a separate folder tree export captures the folder and album hierarchy with paths. Canto’s metadata CSV format separates multiple values in keywords, tags, and custom fields with semicolons, so check your export and split those fields on semicolons rather than commas. Albums usually translate best to a multi-select field or tags in the target DAM, since one asset can sit in several albums.

Migrating From Adobe Experience Manager Assets

AEM Assets exports metadata to CSV at the folder level, including subfolders if you select that option. Collections can’t be exported this way, so capture collection membership separately through the API or a custom report. AEM metadata schemas can be complex, with multi-value properties marked by type in the CSV header, so expect more cleanup in the mapping step. Very large hierarchies may hit an export cap, so split exports by folder. AEM-hosted renditions and Dynamic Media URLs embedded in sites need a redirect or on-demand migration plan.

How to Validate a DAM Migration

Validation proves that what arrived matches what left. Run it after the pilot and again after each production batch, not only at the end, so errors don’t compound across thousands of assets.

1. Reconcile counts. Compare asset totals by type and by top-level folder or collection between the source export and the target system. Every gap should match an entry in your error log or your exclusion list.
2. Check metadata field by field. Pull a random sample of 1 to 2% of assets (at least a few hundred) and compare each mapped field against the source export. Script this using the source ID you stored on each asset.
3. Check rights fields on every asset. Usage rights and expiry dates carry legal risk, so validate them in full rather than by sample.
4. Run real searches. Ask daily users to find 10 to 20 assets they use often, using the terms they’d normally type. Failed searches usually point to a tag or keyword mapping problem.
5. Test permissions. Log in as a user from each role and confirm they see what they should and nothing more.
6. Test integrations and URLs. Confirm the CMS, PIM, and ecommerce connections pull the right assets, and crawl key pages for broken image and video links.

Once validation passes, keep the old DAM in read-only mode for an agreed period before shutting it down. That gives you a fallback if someone reports a missing asset or field after go-live.

For what happens after cutover, including governance roles and metadata audits, see the guides on DAM implementation and DAM governance.

Moving to a New DAM With Your Metadata Intact

A DAM migration succeeds or fails on metadata. Files are easy to copy, but titles, tags, rights, and collection membership only survive if you export them separately, map each field to a destination before the move, and validate against the source after it. A pilot batch, a stored source ID on every asset, and a plan for live delivery URLs prevent most of the problems teams discover after go-live.

Cloudinary supports bulk migration through the Upload API and CLI, on-demand migration with auto-upload, and structured metadata with validation, so you can move a library and keep the media on your sites loading throughout. Contact our team to plan your DAM migration.

Frequently Asked Questions

How Long Does a DAM Migration Take?

A small library of under 50,000 assets with a simple schema typically takes 3 to 6 weeks. Enterprise migrations with hundreds of thousands of assets, several brands, and connected systems often take 4 to 9 months, with most of that time spent on audit, metadata mapping, and validation.

What Happens to Folder Structures During a DAM Migration?

Folders can be recreated as they are, but it’s often better to redesign them. Single-parent folders work for ownership or region, while collections and albums that let one asset sit in several places usually translate better into tags or multi-select metadata fields.

How Do You Handle Duplicate Assets When Migrating DAMs?

Find duplicates during the audit by comparing file hashes or file names and sizes. Choose one copy to keep, merge the useful metadata from the others into it, and record the discarded IDs so you can redirect any links that pointed to them.

Can You Migrate to a New DAM Without Downtime?

Yes, if you run both systems in parallel. Keep the old DAM read-only, migrate in batches, run a delta migration for anything added during the move, and use redirects or on-demand migration so websites keep loading media while URLs change.