Key takeaways
- Audit rights and licensing status for every asset before decommissioning begins: assets with unknown or expired rights must be quarantined, not migrated.
- Migrate in prioritized waves based on asset value and usage frequency, not alphabetical order or folder structure.
- Institutional metadata - custom fields, taxonomy terms, and workflow history that exist only in the legacy system - must be exported and preserved before the system is switched off.
- A formal decommission record, including the closure date, the disposition of every asset class, and the name of the accountable owner, is a compliance and audit requirement in regulated industries.
- User communication and training on the new system must precede the legacy system shutdown, not follow it.
Executive Summary
Why Legacy DAM Decommission Is the Most Underrated Phase of Any DAM Program
Every DAM implementation plan has a detailed section on platform selection, migration tooling, and go-live. Almost none of them have an equally detailed section on what happens to the system being replaced. The legacy DAM is treated as a problem that solves itself once the new system is live: users will stop using it, IT will switch it off, and the vendor contract will lapse. In practice, none of those things happen cleanly without deliberate management.
Assets with unresolved rights status migrate into the new system and become a compliance liability. Institutional metadata accumulated over years of use is lost when the system is switched off. Users who were never properly transitioned keep uploading to the legacy system for months after go-live, creating a parallel and unsanctioned asset library. And the legacy system contract, which nobody remembered to terminate, keeps billing the organization for a system nobody is supposed to be using.
A structured decommission process prevents all of these outcomes. It takes more time and planning than most organizations budget for, but it is substantially less expensive than the remediation work that follows an unmanaged shutdown.
What This Guide Does Not Cover
This guide focuses on the organizational and governance process for sunsetting a legacy DAM. It does not cover the technical configuration of specific DAM platforms, migration tooling selection, or API-based migration approaches. Platform-specific migration documentation is available from your DAM vendor.
This guide does not provide legal advice on data retention, rights management, or contract termination. Organizations in regulated industries should engage their legal and compliance teams before finalizing their decommission plan. The retention periods and compliance requirements referenced in this guide are illustrative; actual requirements vary by jurisdiction, industry, and contract.
The timelines and cadences in this guide - audit durations, parallel running windows, communication lead times - are practitioner conventions. They are not published industry standards or guaranteed timelines. No industry body has set mandatory benchmarks for these figures in the context of DAM migrations. Treat them as starting-point estimates and adjust to your organization's context.
The DAM Republic is a vendor-neutral resource hub. We do not sell DAM software, receive referral fees from vendors, or have a commercial interest in which platform you choose or migrate to.
Frequently Asked Questions
What is the biggest risk when sunsetting a legacy DAM?
The biggest risk is migrating assets with unknown or expired rights. If rights metadata was not consistently maintained in the legacy system, those assets arrive in the new system with the same compliance gap. The second biggest risk is losing institutional metadata: custom taxonomy terms, workflow history, and usage data that exist only in the legacy system and are not exported before shutdown.
How long does a legacy DAM decommission typically take?
There is no published industry benchmark for DAM decommission timelines. Practitioners working on mid-size libraries commonly report four to nine months from audit kick-off to formal closure, with rights remediation being the primary variable. Treat any timeline estimate as a starting point and adjust based on your library's rights complexity and team capacity.
Should we run the legacy DAM and the new DAM in parallel during migration?
Yes, for a defined and time-limited period. Running both systems in parallel for four to eight weeks after the new DAM opens is a widely used approach: the new system takes all new uploads, the legacy system is read-only. The risk of a longer parallel period is that it normalizes dual-system working and delays full adoption of the new platform.
What happens to assets that cannot be migrated because of rights issues?
Assets with unresolvable rights issues should be quarantined in a documented archive, not deleted and not migrated. The quarantine record should note the asset identifier, the nature of the rights issue, the date of quarantine, and the name of the person who made the quarantine decision. ISO 16175-1:2020 section 5 provides a relevant framework for records disposition decisions in system transitions.
How do we communicate the legacy DAM shutdown to users?
A three-stage communication plan is widely used: an announcement at least 60 days before shutdown naming the date and the new system; a training session at least 30 days before shutdown; and a final reminder seven days before the legacy system goes read-only. After shutdown, redirect any legacy system URLs to the new system or to a closure notice page.
Do we need to keep any data from the legacy DAM after it is decommissioned?
Yes. At minimum, retain a full metadata export in a non-proprietary format such as CSV or JSON, a list of every asset identifier and its disposition (migrated, quarantined, or deleted), and the decommission record itself. ISO 16175-1:2020 provides a process framework for managing records through system transitions. Actual retention periods vary by jurisdiction, industry, and contract; consult your legal and compliance team.