Acquia DAM becomes the single source of truth only once downstream systems pull from it. This page records which systems consume approved assets, when each comes into scope, and the integration pattern each one implies — native connector, CDN URL or API. It also records the sources already serving assets today, and how those are migrated and eventually retired without interrupting what depends on them.
Six consuming systems are known today. One has a confirmed date and a confirmed approach; the rest need a date, a workflow walkthrough, or both. An integration pattern can't be chosen for a system until it's clear how that system handles assets today.
| System | Timeline | Integration approach | Workflow walkthrough |
|---|---|---|---|
| padi.comDrupal · incl. WordPress blogs | Nov 2026 | Native Acquia DAM to Drupal connector | Not neededApproach confirmed. Delivery runs through the Web stream. |
| scubadiving.com, club.padi.com, pro.padi.comDrupal | TBDEither part of the PE stream, or separate modernization workstreams. | Native Acquia DAM to Drupal connector | NeededHow PADI Media Group (PMG), club and pro assets are managed and shared across these properties. |
| CommerceToolsStore, B2B & B2C | Feb / May 2027 | API or connector. To be decided during workstream discovery and build. | NeededHow product and category images are managed and served today. |
| Django CMSTravel | TBD | API or connector. To be decided. | NeededHow travel imagery is uploaded, managed and delivered. |
| Learning platformeLearning | TBD | API or connector. To be decided. | NeededHow course assets are managed, stored and consumed by learners. |
| Salesforce Marketing CloudSFMC | TBD | Not defined | Not neededLikely handled by a different vendor. Worth confirming ownership so it doesn't fall between vendors. The assets migrate into Acquia DAM either way. |
Two downstream systems are already served by an existing asset source. Those sources are in scope for migration into Acquia DAM, but migrating the assets and cutting over the integration are separate steps, and nothing is switched off between them.
| Existing source | Serves | Downstream consumer | Interim state | Retires when |
|---|---|---|---|---|
| CloudinaryStore assets | Product and category imagery | Store, B2B & B2C | Continues as-isRemains the serving source for Store. | CommerceTools is integrated with Acquia DAM and consuming from it |
| DomiknowLearning assets | Course and instructional content | Learning platform | Continues as-isRemains the serving source for Learning. | The Learning platform is integrated with Acquia DAM and consuming from it |
| Other sourcesTo be confirmed | To be surfaced during discovery | Not yet known | Assumed liveTreated as live until assessed. | Same principle. No retirement before the dependent system is cut over |
Assets move into Acquia DAM alongside the wider PADI migration, so governance and search live in one place.
Each downstream system is integrated with Acquia DAM and switched to consume assets from it.
The previous source is stood down once nothing depends on it.
Assets held in Cloudinary and Domiknow will be migrated into Acquia DAM as part of the wider PADI asset migration, so that Acquia DAM becomes the single governed source of truth.
Migration alone does not change how downstream systems are served. Each integrated system stays connected to its current source until Acquia DAM is integrated for that system, at which point it is cut over to consume assets from Acquia DAM. No existing source is retired ahead of that cutover, so Cloudinary, Domiknow and any comparable source continue to operate as-is in the interim.
The initial migration is a point in time. Assets keep being added and updated in Cloudinary, Domiknow and any comparable source while each downstream system waits for its cutover, so Acquia DAM starts drifting from the source the moment migration finishes. Three options for handling that delta, until each system consumes from Acquia DAM and the question falls away.
updated_at later than the last run, and again as each consumer cuts over.The delta only needs managing in the window between migration and cutover, and during that window the source stays authoritative for its consumer. Short-lived staleness in Acquia DAM therefore carries little risk, and a final delta run immediately before each cutover closes the gap.
Option 2 earns its cost only where a source has to stay authoritative well beyond cutover, or where near real-time parity is needed sooner. Option 3 is worth holding as a stop-gap for low-volume sources. This is a proposal for PADI to confirm, not a settled decision.