Short answer
A DAM go-live checklist is a readiness gate that confirms migration is validated, integrations are tested and monitored, users are trained, support is live, governance rules are published and old systems have a read-only date. The DAMSelection checklist holds 38 items in five groups. Go live only when every Must item is confirmed by its named owner with evidence.
What the DAM go-live checklist confirms
The DAM go-live checklist confirms readiness in five groups: technical, content, people, governance and commercial. The checklist closes the build phases of DAM implementation. Teams that check only the technical group launch a working platform nobody uses.
DAMSelection assessment: adoption decides DAM success, so people and governance items carry the same weight as technical items. A DAM launched without trained champions or a read-only date for old drives starts with a parallel run that can last a year. The DAM user adoption guide explains why.
Each item in the checklist has three parts: the condition, the evidence and the owner. Evidence means a document, a test record or a screenshot. A verbal "done" in a status meeting does not count.
Go and no-go decision rules
The DAM go-live decision belongs to the DAM owner, taken at a go and no-go meeting five working days before launch. Five days leaves time to fix one or two open items without moving the date.
- Every owner marks each item green, amber or red, with evidence linked.
- Every Must item must be green.
- A Should item may be amber with a written mitigation, an owner and a fix date within 30 days.
- Any red item stops the launch.
- The DAM owner signs the decision and the meeting notes go to the steering group.
Repeat the meeting 24 hours before launch for items that were amber. The DAM RACI names the owner for each group.
Technical readiness
DAM technical readiness means the platform, integrations and security controls work at production volume and fail safely. The integration testing guide supplies most of the evidence. ISO/IEC/IEEE 29119-1:2022 gives the vocabulary for test completion criteria, which the test report should reference.
| Item | Evidence | Owner | Priority |
|---|---|---|---|
| Production environment configured to the signed-off design | Configuration export compared with design | DAM manager | Must |
| Single sign-on live, SSO groups mapped to DAM roles | Test log in with each role | IT and integration owner | Must |
| All integration Must test cases passed | Test report with case IDs | IT and integration owner | Must |
| Volume test passed at peak load plus safety factor | Volume test report | IT and integration owner | Must |
| Monitoring and alerts live for every integration | Test alert received by recipients | IT and integration owner | Must |
| Integration runbooks written | Runbook per integration | IT and integration owner | Must |
| Security review findings closed or accepted | Security review sign-off | IT and integration owner | Must |
| Backup and restore tested | Restore test record | IT and integration owner | Should |
| Rendition presets and CDN delivery tested on live channels | Rendition check per channel | DAM manager | Must |
| Old links redirected or mapped | Redirect test sample | IT and integration owner | Should |
The security review from selection holds the baseline for the security item. Close any findings that were deferred to implementation before launch.
Content readiness
DAM content readiness means users find useful, correctly described and legally usable assets on their first search. An empty or poorly described library loses users on day one.
| Item | Evidence | Owner | Priority |
|---|---|---|---|
| All migration batches for launch validated: counts, file integrity, metadata | Batch validation reports | DAM manager | Must |
| Most-used assets per team migrated and fully described | Top-asset list with completeness check | DAM manager | Must |
| Required metadata fields complete on launch content | Completeness report | DAM manager | Must |
| Usage rights recorded on launch content, unknown rights flagged | Rights coverage report | Legal and rights | Must |
| Expired assets withdrawn or blocked | Expiry report showing zero live | Legal and rights | Must |
| Ten common searches per team return the right assets | Champion test log | Champions | Must |
| Collections and brand portal pages set up | Portal review | Brand manager | Should |
| Duplicates resolved in launch content | Duplicate report | DAM manager | Should |
The DAM migration checklist covers batch validation in detail. The rights exposure estimator sizes the risk from assets with unknown rights. Use its after-migration section as evidence here.
People readiness
DAM people readiness means every user group knows how to do its tasks and where to get help on launch day.
| Item | Evidence | Owner | Priority |
|---|---|---|---|
| Champions named for every team and trained | Champion list and attendance | DAM manager | Must |
| Role-based training scheduled for every user group in the first two weeks | Training calendar | DAM manager | Must |
| Training videos per role stored in the DAM | Video links on help page | DAM manager | Should |
| Help page published with the RACI and contacts | Help page link | DAM manager | Must |
| Support channel live with response targets | Channel and targets published | DAM manager | Must |
| Launch communication sent, with the read-only date for old drives | Message copy and send date | DAM owner | Must |
| Agencies briefed on upload rules and access | Agency briefing record | Brand manager | Should |
| Vendor support contacts and escalation path known | Escalation sheet | IT and integration owner | Must |
Governance readiness
DAM governance readiness means the rules that keep the library usable are written, published and owned before the first upload. The DAM governance model defines those rules.
| Item | Evidence | Owner | Priority |
|---|---|---|---|
| RACI signed off with named people and deputies | Signed RACI | DAM owner | Must |
| Metadata schema frozen, with change request process | Schema document and request form | Taxonomy owner | Must |
| Upload and metadata rules published | Rules page | DAM manager | Must |
| Rights and expiry process documented | Process document | Legal and rights | Must |
| Monthly change board scheduled for six months | Calendar invites | DAM manager | Should |
| KPI set, baseline and targets agreed | KPI sheet | DAM owner | Must |
| Old drives read-only date confirmed | Change ticket with date | IT and integration owner | Must |
The DAM KPI guide gives the formulas. Record the baseline before launch, because no baseline can be rebuilt afterwards.
Commercial and vendor readiness
DAM commercial readiness means the contract terms that matter after launch are known, entered in calendars and owned. The renewal date and notice deadline are the items teams most often leave out of the plan (DAMSelection assessment).
| Item | Evidence | Owner | Priority |
|---|---|---|---|
| Renewal date and notice deadline entered in calendars | Calendar entries for DAM owner and procurement | DAM owner | Must |
| Renewal Radar start date set at 180 days before renewal | Calendar entry | DAM owner | Must |
| Metered allowances recorded: storage, egress, AI credits, users | Allowance sheet | DAM owner | Must |
| Support level, response times and hypercare period confirmed | Contract extract | IT and integration owner | Must |
| Data export method tested once | Export test record | IT and integration owner | Should |
The Renewal Radar playbook uses these dates. A tested export also supports the exit strategy agreed during selection.
Common go-live blockers and fixes
DAM go-live blockers repeat across programmes, and most can be found four weeks ahead with the right check. Run these checks at the four-week mark, so the go and no-go meeting holds no surprises.
| Blocker | Early check at four weeks | Fix |
|---|---|---|
| Rights unknown on a large share of launch content | Rights coverage report on the launch batches | Launch with rights-known assets only, flag the rest as restricted |
| SSO groups do not match DAM roles | Test log in with one user per role | Map groups with the identity team, simplify roles where possible |
| Integration passes functional tests, fails at volume | Volume test result | Tune batch sizes and rate limits, retest at peak plus safety factor |
| Champions missing in one or more teams | Champion list against team list | Escalate to the team lead through the DAM owner |
| Schema still changing | Change requests in the last two weeks | Freeze the schema, park requests for the first change board |
| Old-drive read-only date not agreed | IT change ticket | DAM owner escalates to the steering group |
Checklist for later waves
Later DAM waves reuse the full checklist, with three items added for each new user group or brand:
- The new group's most-used assets are migrated, described and tested with its own 10 common searches.
- The new group's champions are trained and its read-only date for old drives is announced.
- New integrations for the wave have passed their own test cycle, and existing integrations pass a regression run.
Cutover runbook
The DAM cutover runbook sequences the final 14 days before launch and the first 30 days after it, with one owner per step.
| When | Step | Owner |
|---|---|---|
| Day minus 14 | Final migration delta planned, freeze on old-drive uploads announced | DAM manager |
| Day minus 5 | Go and no-go meeting | DAM owner |
| Day minus 2 | Final delta migration and validation | DAM manager |
| Day minus 1 | Repeat go and no-go for amber items, integrations switched to production | DAM owner, IT |
| Day 0 | Launch message, help channel staffed, champions on call | DAM owner, champions |
| Days 1 to 10 | Daily stand-up on issues, alerts and top requests | DAM manager |
| Day 30 | Old drives read-only if not done at launch, hypercare review | IT, DAM owner |
Hypercare after go-live
DAM hypercare is a fixed period of extra support after launch, usually 2 to 4 weeks (DAMSelection rule of thumb). Issues are fixed fastest while the project team is still in place.
- Staff the help channel with a response target of four working hours.
- Hold a 15-minute daily stand-up on issues, alerts and requests.
- Log every issue with category, fix and owner.
- Review zero-result searches daily and add content or synonyms.
- Close hypercare with a handover to the run organisation and a lessons-learned note.
Frequently asked
What should be on a DAM go-live checklist?
A DAM go-live checklist covers five groups: technical readiness, content readiness, people readiness, governance readiness and commercial readiness. Each item needs evidence and a named owner. Typical Must items are passed integration tests, validated migration, trained champions, a published RACI and a confirmed read-only date for old drives.
Who decides whether a DAM goes live?
The DAM owner decides, at a go and no-go meeting about five working days before launch. Item owners present evidence, every Must item must be green and any red item stops the launch. The DAM owner signs the decision and shares it with the steering group.
How long should DAM hypercare last?
DAM hypercare usually lasts 2 to 4 weeks after launch (DAMSelection rule of thumb). Extend it when a second wave of users or integrations goes live soon after the first. Agree the hypercare period and vendor support levels in the contract or statement of work before launch.
Can a DAM go live with open issues?
A DAM can go live with open Should items marked amber, each with a written mitigation, an owner and a fix date within 30 days. Every Must item has to be green. Open issues on rights expiry, sign-in or core integrations always block launch.
When should old shared drives become read-only?
Old shared drives should become read-only on a date announced at launch, typically within 30 to 60 days (DAMSelection rule of thumb). A shorter window ends the parallel run faster. Check access logs before the date and migrate any assets still in demand.