DAM migration checklist

How to use the DAM migration checklist

The DAM migration checklist is a gate document that the migration lead runs at three points: before the first batch, after every batch, and at cutover. Each item has one owner and one piece of evidence. An item without evidence counts as open.

Copy the lists into a tracker with four columns: item, owner, evidence and status. The checklist follows the method in the DAM migration plan, which sits inside phase 2 of the DAM implementation. Owner names match the roles in the implementation plan.

Before migration: scope and inventory

The scope and inventory items confirm that every source is known, owned and sized before any file moves.

1. Every source is listed: shared drives, the old DAM, cloud storage, agency servers, the PIM, the CMS media library and personal folders (owner: migration lead).
2. Every source has a named business owner who decides on cleanup (owner: DAM owner).
3. File count, volume and file types are recorded per source (owner: migration lead).
4. Available metadata is recorded per source: folder paths, embedded IPTC or XMP fields and old DAM fields (owner: taxonomy owner).
5. Rights records are located per source, with the count of assets that have none (owner: legal and rights).
6. The migration volume in the contract or statement of work matches the inventory (owner: DAM owner).
7. Storage for the migrated volume plus renditions fits the contract allowance (owner: DAM owner).
8. The notice period and end date of the old DAM contract are known (owner: DAM owner).

Before migration: cleanup decisions

The cleanup items confirm that only useful, owned and traceable assets enter the new DAM.

1. Cleanup rules are written and signed off by each content owner: migrate, archive or delete (owner: migration lead).
2. Exact duplicates are found by file hash, and a written rule chooses the surviving copy (owner: migration lead).
3. Near-duplicates, such as the same photo in two crops, are reviewed or handled by rule (owner: content owners).
4. Superseded versions are removed unless the version history has legal or regulatory value (owner: content owners).
5. Work files, temporary exports and system files are excluded (owner: migration lead).
6. An archive location and a retention rule exist for out-of-scope files (owner: IT and integration owner).
7. Assets without rights records carry a "Rights unknown" flag in the migration manifest, sized in advance with the Rights Exposure Estimator (owner: legal and rights).
8. Personal data in files and embedded metadata, such as GPS location in EXIF fields, has a handling rule (owner: legal and rights).

Before migration: mapping, configuration and test

The mapping and test items confirm that the target is ready and that a sample migration works for real users.

1. The metadata schema is frozen and signed off (owner: taxonomy owner).
2. The metadata mapping table lists source field, target field, conversion rule and default for every field in scope (owner: taxonomy owner).
3. Folder-path rules are written and tested on real paths from every source (owner: taxonomy owner).
4. Source values are normalised to the controlled vocabulary through a signed-off synonym table (owner: taxonomy owner).
5. Rendition profiles exist for every channel in scope (owner: DAM manager).
6. Permissions and the restricted status for rights-unknown assets are configured and tested (owner: DAM manager).
7. Migration scripts or vendor tools have run on a sample in the test environment (owner: IT and integration owner).
8. A test migration covers every source and asset type, with 1,000 assets as the DAMSelection rule of thumb for a mid-sized library (owner: migration lead).
9. Users from each main team have searched the test migration and their findings are fixed (owner: DAM manager).
10. The batch plan sets order, size, dates and validation windows (owner: migration lead).
11. The issue log, its severity levels and the escalation route are agreed (owner: migration lead).
12. Every team has received the migration timeline, the freeze window and the read-only date (owner: DAM owner).

During migration: batch execution

The batch execution items confirm that each batch runs from a complete manifest and leaves a traceable record.

1. The batch manifest lists every file with its source path, SHA-256 checksum and target asset type before the batch starts (owner: migration lead).
2. Uploads to the sources in the batch are frozen, or new uploads go to the new DAM only (owner: DAM manager).
3. The batch runs in the agreed window, and the run log is stored (owner: IT and integration owner).
4. Load errors are logged with file ID, error type and retry result (owner: IT and integration owner).
5. A daily status goes to stakeholders with batches done, assets loaded and open issues (owner: migration lead).

During migration: validation and issues

The validation items confirm that every asset in the batch arrived intact, described and correctly restricted.

1. The asset count in the DAM matches the manifest, with every gap explained (owner: migration lead).
2. SHA-256 checksums match for every file (owner: IT and integration owner).
3. Every required field is filled or carries the agreed default (owner: DAM manager).
4. No value sits outside the controlled vocabulary (owner: taxonomy owner).
5. Every master file has its renditions (owner: DAM manager).
6. Product links, versions and collections exist as listed in the manifest (owner: DAM manager).
7. Every rights-unknown asset carries the restricted status (owner: legal and rights).
8. Content owners have found 20 known assets through search, as the DAMSelection rule of thumb sample (owner: content owners).
9. Embedded IPTC and XMP metadata survived ingest on a sample of files (owner: taxonomy owner).
10. Every open issue has an owner, a severity and a fix date (owner: migration lead).
11. Critical issues are fixed and the batch is re-validated before the next batch starts (owner: migration lead).
12. The taxonomy owner signs off the batch in the tracker (owner: taxonomy owner).

The checksum items rely on the Secure Hash Standard. A matching SHA-256 digest at source and target shows that the file content is unchanged after transfer.

After migration: cutover

The cutover items confirm that the organisation switches to the new DAM as its single source without breaking links or integrations.

1. The freeze window and read-only date were announced two weeks ahead, as the DAMSelection rule of thumb (owner: DAM owner).
2. The delta migration has run and passed every validation item (owner: migration lead).
3. Integrations point to the new DAM and the first syncs passed the cases in DAM integration testing (owner: IT and integration owner).
4. Old public asset URLs redirect with permanent HTTP 301 redirects to the new asset or rendition (owner: IT and integration owner).
5. The redirect map from old URL to new asset ID is stored with a named owner (owner: IT and integration owner).
6. Intranet pages, templates and shared bookmarks that pointed to old drives are updated (owner: champions).
7. Users have received the launch message with login, training dates and support channel (owner: DAM owner).
8. The DAM go-live checklist is complete (owner: DAM owner).

After migration: decommissioning and follow-up

The decommissioning items confirm that old systems close on schedule and that the migration leaves a measured baseline.

1. Old sources are read-only on the published date (owner: IT and integration owner).
2. A final export of retained content from the old DAM, with metadata and audit history, is archived (owner: IT and integration owner).
3. Notice on the old DAM contract is served within its notice period (owner: DAM owner).
4. Access to old sources is removed on the decommission date (owner: IT and integration owner).
5. The rights review queue has a deadline, and unconfirmed assets move to the archive on that date (owner: legal and rights).
6. Metadata completeness and duplicate rate are measured as the first post-migration baseline (owner: DAM manager).
7. A lessons-learned review feeds the governance backlog (owner: DAM owner).
8. The final migration report records counts per source, cleanup totals, open issues and sign-offs (owner: migration lead).

Migration sign-off template

The migration sign-off template records the evidence behind the gate 3 decision on one page. Fill it from the tracker and the final migration report.

Checklist items teams skip

DAMSelection assessment: four checklist items get skipped most often, and each one causes cost after go-live. Give these four items a named owner at mobilisation.

• Owner per source: without a business owner, cleanup decisions stall and the migration lead migrates everything by default.
• Rights records: assets without a rights flag become unrestricted and easy to share in the new DAM.
• Redirects: websites and partner pages that embed old asset URLs break on the decommission date.
• Old contract notice: a missed notice period renews the old DAM for another term while the new one is live.