Exit strategy and asset portability

What DAM data portability covers

DAM data portability covers ten layers of data, from original files to AI-derived tags. Years of tagging, rights records, approvals and product links sit in the metadata and relationships around each file. DAMSelection assessment: those layers cost far more to rebuild than the files cost to copy, so an export of files alone loses most of the library's value.

Fact: the European Commission states that the data covered by EU Data Act switching includes input and output data, including metadata, generated by the customer's use of the service. The Act applies from 12 September 2025 and covers SaaS. DAMSelection assessment: the DAM contract lists each layer by name, so no layer falls outside the export.

Why DAM exits fail

DAM exits fail on four predictable problems: embedded delivery links, proprietary metadata structures, lost history and transfer volume. Each one can be spotted during selection, long before the exit starts.

• Embedded delivery links. Websites, apps, marketplaces and partner portals can point straight at the DAM's public CDN URLs. When the contract ends, those links break across every channel at once.
• Proprietary structures. Metadata exported as one flat text field, or relationships stored only in the vendor's internal IDs, need a manual rebuild.
• Lost history. Approval records, rights history and version trails can stay behind, which matters in regulated industries and in rights disputes.
• Volume and time. Large libraries take days to move, and the retrieval window in the contract may be shorter than the transfer.

Worked example: a 40 TB library moved over a sustained 1 Gbit/s connection takes about 3.7 days of continuous transfer. At an effective 50% of that rate the move takes about 7.4 days, before checksum checks and re-imports. Plan the retrieval period with that arithmetic in hand.

Exit questions for the RFP

DAM exit questions belong in the RFP, so every shortlisted vendor answers them in writing before the demos. Written answers become evidence for the scoring matrix and a reference point for the contract. The exit strategy is one of the Selection Route tasks that starts at the shortlist checkpoint and ends at signature.

Ask each vendor to provide:

1. The documented export method for files, metadata, relationships, versions, rights and history, with a documentation URL.
2. The formats used for each layer and a sample export file.
3. Whether a full export runs through self-service tools or needs vendor services, and at what rate.
4. Whether exported image files carry IPTC and XMP metadata written back.
5. Support for a custom delivery domain and redirects after contract end.
6. The notice, transitional and retrieval periods in the standard contract.
7. Any switching charges or early termination penalties, disclosed in writing before signature.
8. The deletion process after exit, including backups, and the form of the deletion certificate.

Score vague or missing answers as weak evidence. The demo red flags guide lists the export test to run live in the demo.

Test portability before signature

A DAM portability test during the proof of concept shows what an exit will deliver, while the buyer still has a choice of vendor. An export that fails in a sample of 1,000 assets will fail at 1,000,000.

Run the test in seven steps:

1. Load 500 to 1,000 assets covering every asset type, with full metadata, rights, relationships and two or more versions each.
2. Request a full export through the documented export method or API, without vendor engineering help.
3. Compare file counts and checksums between the import set and the export.
4. Open the metadata export and check every field, value and controlled vocabulary against the schema.
5. Check that IPTC and XMP fields are written back into the exported image files.
6. Rebuild collections, product links and versions from the export, using the asset IDs.
7. Time the export and extrapolate to the full library volume.

Record the result as evidence in the scoring matrix under API and extensibility. A vendor who needs professional services to complete the test has shown the exit cost in advance. The proof of concept guide explains how to fit the test into the wider evaluation.

Contract the exit

The DAM exit belongs in the contract, with scope, format, timing, cost, assistance and deletion written down before signature. Fact: Chapter VI of the EU Data Act sets switching rules for data processing services, including SaaS. Under Article 29, switching charges, including data egress charges, end from 12 January 2027.

Fact: Article 28(3)(g) GDPR requires a processor to delete or return all personal data at the end of the service, at the controller's choice. The 60-day retrieval period in the table is a DAMSelection rule of thumb for libraries above 10 TB. The contract clauses checklist covers the surrounding terms, including AI-derived data and termination assistance.

Keep the exit open during the contract

A DAM exit stays open when the buyer protects portability every year of the contract. Vendor lock-in builds slowly through custom fields, embedded links and undocumented integrations.

Six habits keep the exit open:

• Run one test export per year and compare it with the previous year.
• Keep the metadata schema documented outside the DAM, with field definitions and vocabularies, for example in the Metadata Model Builder.
• Write IPTC and XMP metadata back into files on download, so key fields travel with each asset.
• Serve delivery URLs from the buyer's own domain, so a future DAM can take over the same links.
• Keep a mapping of asset IDs in the PIM and other connected systems.
• Track renewal dates and start the Renewal Radar playbook 180 days ahead.

DAMSelection assessment: delivery URLs on the buyer's own domain remove the most visible exit risk, because channel links stay intact when the platform behind them changes. Confirm during selection that the vendor supports a custom delivery domain.

Run the exit

A DAM exit runs as a migration project with a fixed timeline, starting long before the notice date. The migration plan and the metadata mapping guide cover the receiving side in detail.

DAMSelection rule of thumb for the timeline of a mid-sized library:

1. Nine months before contract end: decide to leave and start selecting the replacement.
2. Six months before: sign with the new vendor and map metadata between the two schemas.
3. Four months before: run a trial export and import of 10% of the library.
4. Three months before: give notice under the contract.
5. Transitional period: run the full export, the delta exports and the import.
6. Retrieval period: check counts and checksums, switch delivery URLs, and confirm deletion.

The replatforming guide covers when a replacement is justified, and the migration checklist covers the steps on the new platform.