DAM implementation & rollout plan: phases, roles and launch checklist

Why it matters

A DAM is usually bought to fix a cross-team problem: assets that cannot be found, unlicensed images reaching publication, brand inconsistency, work redone because nobody knew it existed. The purchase does not fix any of this. The implementation does, and it is where most of the risk sits.

Independent evidence on DAM implementations specifically is thin. No independent, freely accessible study of DAM implementation success rates or durations was found, so this guide gives no such figures. What is available points in a consistent direction:

• The software does not bring the operating model. AVP, a DAM consultancy, notes that the operating model a DAM needs (roles, governance, processes, measurement) is not included with DAM software and has to be designed by the organisation R10.
• Timelines are hard to forecast. A 2023 Code4Lib Journal case study of a university library's move to an open-source repository describes a project that started in December 2017 and launched in August 2021, timed to the end of the previous system's contract with some planned features still missing; the authors write that "timeline forecasting is difficult" R12. That case involved custom development, so its duration is not typical of a SaaS DAM, but its lesson applies to any project.
• Users resist changes to familiar tools, even good ones. Google researchers describe change aversion as discomfort when something familiar is replaced by something unfamiliar, and report that a planned change-management framework produced clearly more positive user reactions than earlier launches without one R8.
• Phasing works for DAM too. W.L. Gore's enterprise DAM librarian, speaking at a marketing-technology conference, described a phased rollout that started with one division and a deliberately minimal first release (upload, search, download) presented to users as a first version, not the final product R11.

Public-sector delivery guidance reaches the same conclusion from a different angle: the UK Government Digital Service (GDS) structures every new service as discovery, alpha, beta and live, and advises keeping a legacy service running until its replacement reaches the live phase R3 R15.

Core concepts

Related glossary terms: single sign-on (SSO), SCIM and usage rights.

Recommended practices

1. Run a short discovery after the purchase

Selection gathers requirements to compare products (choosing a DAM). Implementation needs more detail: which teams come first, which assets they need on day one, which fields they filter on, who approves what, which tools must connect.

Borrow the shape of a public-service discovery R1:

• Users and journeys: interview or observe each main group (contributors, searchers, approvers, external partners), including their accessibility needs and the tools they already use.
• Constraints: contracts, legal or regulatory rules, legacy systems, existing processes. Separate hard constraints you must work with from soft ones that should be changed rather than reproduced.
• Existing assets and tools: where assets live today and roughly how many there are, so migration waves can be sized.
• Riskiest assumptions: list the assumptions that would sink the project if wrong (for example "the CMS connector supports our page builder" or "contributors will fill five mandatory fields") and plan how to test them early. GDS uses alpha precisely for this, with prototypes simple enough to be thrown away R2.
• Baseline: measure the current situation (time to find an asset, requests to the DAM or brand team, user satisfaction) before anything changes. AVP recommends surveying users before implementation for this reason R10. Method: KPIs guide, practice 4.

Output: a one-page implementation charter (goals, scope of the first release, waves, roles, risks, success measures) signed by the sponsor.

2. Set up governance before configuration, not after launch

Configuration choices are governance decisions in disguise: who may create a field, who approves a new vocabulary term, who can share outside the organisation. Decide them first.

AVP's operational model groups DAM governance into five pillars: policies (collection, curation, lifecycle), standards (metadata, taxonomy, classification and how they change), permissions, rights and security, roles and responsibilities, and issue and change management R10. A practical minimum before the pilot:

• a governance group (sponsor, DAM product owner, metadata lead, representatives of the first waves, legal or rights where relevant) with a meeting rhythm;
• a decision log for schema, taxonomy and permission choices;
• a change process for the schema, treated like a release (metadata schema guide, practice 10);
• a written collection policy: what belongs in the DAM, what does not, and when assets are archived or deleted.

3. Configure the foundations in a deliberate order

Some settings are cheap to change later (a homepage banner); others are expensive once assets and integrations depend on them. Configure the expensive ones first and test them before inviting users:

1. Identity and access. Connect SSO, define roles and groups, and plan provisioning (permissions guide). Engage IT early: identity-provider changes often have their own lead times.
2. Metadata schema and vocabularies. Asset types, mandatory fields, controlled lists (metadata schema guide, taxonomy guide). Keep mandatory fields few.
3. Naming and IDs (file naming guide).
4. Rights and restrictions: rights fields, expiry behaviour, who may download restricted assets (rights guide).
5. Upload paths and workflows: upload forms, review and approval steps, notifications. Model the current process, then simplify it; do not automate every exception on day one.
6. Integrations needed by the first wave only (CMS, design tools, PIM). Each integration has its own test plan (API integration patterns).
7. Look and feel, portals and sharing last.

Use a non-production environment for configuration and tests where the platform offers one, and keep configuration documented (screenshots or exports) so that decisions survive staff changes.

If personal data is involved (photos of employees, customers or event attendees, model releases), check with your data-protection officer whether a data protection impact assessment is needed. The UK regulator, the ICO, requires one before processing that is likely to result in high risk and recommends doing one whenever in doubt R6 Unverified (guidance under review after the Data (Use and Access) Act at the access date; other jurisdictions have their own rules).

4. Test with real assets and real tasks before the pilot

Before any user sees the system, run an internal acceptance round with the implementation team:

• load a representative sample of assets (every file type, the largest files, restricted and expired assets, assets with special characters);
• run five to ten scripted tasks per role: upload with correct metadata, find a specific asset, request and approve, share externally, download a restricted asset (it should fail);
• test permissions with test accounts for each role (permissions guide, practice 12);
• check accessibility of the user-facing parts (search, upload form, portal) against WCAG with the help of users with disabilities. W3C's Web Accessibility Initiative recommends evaluating early and often during implementation and building accessibility into each stage rather than auditing at the end R5.

AVP recommends exactly this order: validate the configuration with the implementation team first, then with real users R10.

5. Pilot with a team that has real pain and real work

Choose a pilot group with three properties: a clear, current need; assets that are reasonably well understood; and people willing to give feedback. Gore started with a division that already knew where its assets were, had begun using naming conventions and had strict regulatory and rights requirements; designing for the strictest rights case first gave a baseline that later divisions could also use R11.

During the pilot:

• give the pilot group a minimum viable release, say so clearly, and explain what is coming next R11;
• give them a direct feedback channel and a named contact;
• watch real use: searches with no results, abandoned uploads, support requests;
• fix, re-configure and re-test in short cycles. GDS describes private beta as the time to learn from a small group of invited users and to make sure support staff can handle users who struggle, including in unexpected ways R3.

Write exit criteria before the pilot starts, for example: the pilot team uses the DAM for all new assets in scope; mandatory fields are filled for at least an agreed share of uploads; no open blocking defects; support requests are falling; the pilot team would recommend the DAM to the next wave.

6. Roll out in waves, each with its own exit criteria

After the pilot, add teams, regions or use cases in waves. Each wave repeats a short cycle: local discovery, configuration adjustments, migration of that wave's assets, role-based training, launch, hypercare, review.

Gore's talk also suggests separating division-specific requirements from enterprise-wide ones before phasing R11. Vendor guidance warns that configuring every team at once multiplies unresolved governance gaps R14; the same logic is behind GDS's staged move from private to public beta R3.

7. Migrate in waves aligned with the rollout

Migration is a project in its own right. Two implementation-specific points:

• Migrate what the wave needs first. Recent, in-use, brand-critical and legally required assets go first; older material can follow in a later batch, or stay in a read-only archive. One vendor's implementation guide suggests that assets older than two or three years rarely need to move at launch unless they are needed for audit or archive R13; treat this as a starting hypothesis to check with your own usage data.
• Do not launch a wave into an empty or dirty library. Users judge the DAM in their first searches. A wave goes live when its assets are loaded, their metadata validated and their permissions tested.

Mapping, identifiers, rights, checksums, pilots and cut-over are covered in detail in the migration guide, in particular pilot and rehearsal and cut-over and rollback.

8. Name the roles and the time they need

Implementation needs named people with time set aside, not "whoever is available".

AVP distinguishes the DAM product manager, who configures and runs the application, from the asset manager, who handles assets, metadata and taxonomy, and notes that one person or a team may fill these roles R10. Gore's team set clear time commitments for stakeholders at kickoff and held weekly status meetings and regular demos during the build R11. Naming two administrators avoids a single point of failure; one vendor's guide makes the same recommendation R13. The metadata schema guide has the full governance-role table.

9. Manage the change, not only the system

Users need to know why the DAM exists, want to use it, know how, be able to do it in their daily work, and keep doing it. Prosci's ADKAR model, from a change-management consultancy, names these five stages awareness, desire, knowledge, ability and reinforcement, and stresses that organisational change happens one person at a time R9.

The change-aversion framework used for the Google Drive launch is a practical checklist for a DAM launch too R8:

1. Plan the launch stages.
2. Assess the impact on users before launch.
3. Tell users in advance that a change is coming.
4. Explain the benefits for them, not for the organisation.
5. Give transition guidance and support.
6. Where possible, let users switch between old and new for a limited time.
7. Monitor the change over time.
8. Let users send feedback directly.
9. Fix their issues quickly.
10. Tell them what you improved.

For champions, Microsoft's adoption guidance suggests recruiting enthusiastic people who can commit time, including vocal critics whose energy can be put to use, giving them ready-made materials and a regular rhythm of meetings, and recognising their effort R7.

10. Train by role, at the moment people need it

Train each wave just before or at its launch, not months earlier. Gore started training at launch and made sure users knew the first release was a minimum viable product R11.

• Searchers and downloaders: search, filters, collections, sharing, what "restricted" means. Thirty to sixty minutes, recorded.
• Contributors: upload, the few fields that matter, rights fields, naming. Short hands-on sessions with their own assets; AVP singles out contributor training as a way to make assets meet the DAM's standards R10.
• Approvers: workflow steps and notifications.
• Administrators: configuration, permissions, reports, schema change process; usually trained by the vendor or partner.
• External users: a one-page guide and a short video are often enough.

Back training with documentation users can find from inside the DAM: a quick-start page, a field glossary, how-to videos, a request form for missing assets. Check that training worked by looking at behaviour (upload completeness, search success) in the following weeks, as described in the KPIs guide, practice 10.

11. Launch with hypercare and a plan to retire the old tools

Launch week. Announce the date in advance, freeze configuration changes a few days before, and prepare a launch kit: announcement from the sponsor, quick-start guide, training calendar, support contacts, known limitations.

Hypercare. For the first weeks after each launch, reinforce support: a daily triage of issues, a visible support channel, office hours, champions on call in each team. Track every request; the most frequent questions become documentation and configuration fixes. End hypercare against criteria (falling request volume, no open blocking issues), not on a fixed date.

Old tools. Users keep old shared drives and folders as long as they work. Publish a retirement schedule: new assets only in the DAM from launch; old locations read-only from a set date; archived or deleted later. GDS advises keeping a legacy service running until the new one is live, then retiring services that are no longer needed R3 R4. Gore's team looked for the other places users still got assets from, then retired or integrated them so the DAM became the single source R11.

12. Measure launch indicators, then move to steady state

Agree a handful of launch indicators per wave, with a baseline from discovery:

Gore's team advised letting users work with a first release for months before judging how it is used, then using usage data to find what users are not doing and asking them why R11. The full method for KPIs, counting rules and reporting cadence is in DAM KPIs, ROI & user adoption.

Steady state begins when the last planned wave has passed its exit criteria. GDS describes the live phase as supporting the service sustainably while continuing to improve it from user research and performance data, without necessarily keeping a full project team R4. For a DAM, that means a named team, a governance rhythm, a roadmap, a yearly review of the baseline, and a backlog fed by search logs and user feedback.

On timelines

There is no independent benchmark for how long a DAM implementation takes. Duration depends on the number of teams and waves, the volume and quality of assets to migrate, the number of integrations, the state of existing metadata and the availability of the people involved. What can be said from free sources:

• Vendor-published plans for SaaS DAMs describe a first launch within weeks. One vendor's template runs about ten weeks from discovery to a first launch with hypercare, followed by six months of optimisation and a strategic review R13; other vendors' published onboarding offers are listed under "How DAM platforms support this" below. These are vendor schedules for a first scope, not enterprise rollouts.
• For context only, GDS gives typical durations of four to eight weeks for discovery and six to eight weeks for alpha in public-service projects R1 R2.
• Projects involving custom development or open-source builds can take years, as the Code4Lib case study shows R12.

Plan in phases with exit criteria and add contingency, rather than committing to a single go-live date for the whole organisation.

Common pitfalls

• Configuring before deciding. The schema grows field by field from requests during setup, without a data dictionary or owner. Decide governance first (practice 2).
• Copying the old folder tree. Rebuilding shared-drive folders in the DAM brings the old findability problems with it. See folders vs metadata.
• Too many mandatory fields at launch. Contributors stop uploading or fill fields with junk. Start with few and add later through the change process.
• A pilot with no real work. Testers click around for a week and approve. Pilots must carry real assets and deadlines.
• Launching into an empty library. If the first searches return nothing, users conclude the DAM is useless and go back to the shared drive.
• One administrator. When that person is away, uploads, permissions and fixes stop.
• Training months before launch. People forget; train at the moment of use and record it.
• No end date for the old tools. Parallel systems keep old habits alive and double the work.
• Ending the project at go-live. Without a named team, governance and reporting after launch, adoption fades and metadata drifts.
• Integrations left for "phase 2" without a date. If the DAM is not connected to the tools where assets are used, people keep local copies.
• Treating vendor timelines as commitments. A vendor's onboarding package covers its own work; your teams' availability, data quality and internal approvals drive the real schedule.

How DAM platforms support this

The wiki's solution pages record what vendors publish about onboarding, implementation services, training and test environments, mostly in the Resources and Overview pages. The examples below show the kind of difference worth checking when planning an implementation. They are illustrations, not a ranking or a complete list; each fact is cited on the linked page.

Before signing, ask each vendor what its onboarding covers (configuration, migration volume, training sessions, integration work), what remains your responsibility, and whether a non-production environment is included. The comparison table summarises deployment and API facts across platforms, and choosing a DAM covers the hand-over from selection to implementation. For a broader introduction, see what a DAM does.