Most DAM implementations don't fail at the software. They fail at the rollout: a taxonomy designed by committee that nobody tags against, a migration that stalls at 30%, a launch email followed by silence. The good news is that the failure patterns are well known, and so are the phases that avoid them.

This guide assumes you've chosen a system — if you haven't, start with the requirements checklist. The plan below fits a team of ten as well as an organization of hundreds; only the durations change. For a typical mid-sized library, expect to be genuinely live — pilot team working in the system daily — in four to eight weeks, and to be "done" (migration complete, adoption spread) inside a quarter. If a proposed plan runs longer than that before anyone uses the system, the plan is the problem.

Phase 1: Inventory and audit (week 1)

Before you move anything, find out what you have. Not a perfect catalog — a rough map:

• Where assets live. Shared drives, cloud folders, laptops, old systems, agency deliveries sitting in email. List the locations and a rough count and size for each.
• What's actually valuable. Every library is part treasure, part sediment. Old campaign near-duplicates, abandoned drafts, and exports of exports don't deserve migration. A useful heuristic: anything untouched for three years goes to an "archive" slice you migrate last — or never.
• What has rules attached. Licensed stock, photography with model consent, embargoed launches. These assets need their rights information found now, while the people who remember the terms still work with you. Rights that live in someone's inbox are the single most expensive thing to reconstruct later.
• How people search. Ask five future users: "describe the last asset you looked for, and the words you'd have typed." Write the answers down verbatim. This list — not a stakeholder workshop — is the raw material for your metadata model and, later, your test cases.

Deliverable: a one-page map of sources, volumes, an ordered list of migration slices, and the search phrases. A day or two of focused work; resist making it a project of its own.

Phase 2: Metadata model design — keep it small (week 1–2)

This is the phase most often over-engineered, and over-engineering here poisons everything downstream. The anti-pattern is designing a taxonomy for the library you imagine — forty fields, six-level hierarchies, every edge case anticipated. The result: uploading becomes a chore, people skip fields or invent values, and search trust dies with the metadata quality.

Design for the searches from Phase 1 instead:

• Start with five fields or fewer beyond what the system extracts automatically. Typically: asset type, product or campaign, usage rights status, and one or two organization-specific fields. That's it.
• Use controlled vocabularies for anything people filter by. A free-text "campaign" field yields Spring24, spring-2024, and SS24 within a week. An agreed term list means everyone tags the same thing the same way — see controlled vocabulary.
• Let automation carry the descriptive layer. AI tagging, captions, OCR, and transcription generate the "what's in this image / what's said in this video" layer on ingest. Semantic search then matches meaning, not just tags — so you don't need a field for every conceivable query. Humans should correct metadata, not create it from a blank form.
• Postpone hierarchy. A flat vocabulary with 30 terms beats a tree with 300 nodes that only its author understands. Add structure when real usage demands it — the system can grow; a wrong hierarchy is hard to shrink.

Deliverable: fields, vocabularies, and two or three collection structures, on one page. If it doesn't fit on one page, cut.

Phase 3: Pilot team selection (week 2)

Roll out to one team first — but pick the right one:

• High pain. A team currently losing real hours to lost files, ideally mid-campaign. Their before/after story becomes your internal sales pitch.
• Produces and consumes. A team that only uploads, or only downloads, exercises half the system. Marketing teams are the classic pilot because they do both daily.
• Has an opinionated owner. One named person who cares, answers questions, and pushes back on your metadata model when it's wrong. This role matters more than executive sponsorship in the first month.

Anti-pattern: the company-wide launch. Announcing the DAM to everyone at once means supporting everyone at once, with an untested metadata model, on day one. The pilot exists to make your mistakes cheaply.

Set the pilot up completely before inviting anyone: fields configured, vocabularies loaded, permissions and groups mapped, SSO connected, and one share or portal flow working end to end.

Phase 4: Migration in slices (weeks 3–8, overlapping everything)

The single most damaging anti-pattern in DAM projects is the big-bang migration: "we'll move all 200,000 files, tag them properly, and then launch." It has a failure mode so consistent you can set a calendar by it — three months of tagging effort, fatigue, quiet abandonment, and a system that launches with a half-organized library nobody trusts.

Migrate in slices instead:

1. Slice by value, not by folder. First slice: what the pilot team needs this month — the active campaign, the current product imagery, the approved logo set. A first slice of 500–2,000 assets is plenty.
2. Enrich on ingest. Point the importer at the source (S3 bucket, WebDAV share, Google Drive folder) and let the pipeline work on the way in: virus scan, preview generation, embedded-metadata extraction, AI tagging, transcription, OCR, duplicate detection. Automation writes the first draft of every asset's metadata.
3. Correct, don't create. The pilot team's tagging job is review: fix wrong tags, add the campaign field, confirm rights. Correcting a pre-filled record takes a fraction of the time of a blank form — this is where the automated first pass pays for itself.
4. Test search after every slice. Run the Phase 1 search phrases. If "lifestyle photo mountain bike autumn" doesn't find the right assets, fix the model now, while re-tagging costs an afternoon instead of a month.
5. Keep the archive slice honest. Old-but-keepable material gets migrated with automated enrichment only — no human review. Findable is enough; polished is a waste.

Rule of thumb: each slice should be fully usable — migrated, reviewed, searched, in daily use — before the next one starts. Progress you can demo beats progress you can only report.

Phase 5: Training and adoption (weeks 4–10)

Adoption is a product of two things: whether the system is genuinely faster than the old way, and whether people know it exists. Training covers the second; the first you earned in Phases 2–4.

• Train in roles, not features. Thirty minutes for viewers ("find, filter, download, share"), an hour for editors (upload, review AI metadata, collections), a separate session for admins. Nobody needs the full tour.
• Kill the old path. The moment the pilot's assets are migrated, the old folder goes read-only with a link to the DAM. As long as the shared drive still works, it wins by habit. This step takes managerial nerve and is non-negotiable.
• Move one external flow immediately. The first time a partner self-serves the logo pack from a portal instead of emailing someone, the system has visibly paid for itself. Early, visible wins recruit the next team better than any announcement.
• Hold a weekly correction loop for the first month. Owner reviews failed searches and metadata complaints, adjusts vocabularies, communicates changes. The model you designed in Phase 2 was a hypothesis; this is where it meets reality.

Phase 6: Measuring success (ongoing from week 4)

"People seem to like it" is not a metric. Track a small set from the analytics:

• Search success rate. Of searches run, how many end in a preview, download, or share? Falling success on a specific term means a content gap or a vocabulary miss — both fixable. This is your primary health metric.
• Zero-result searches. The literal list of things people wanted and didn't find. Review it weekly; it's a work queue, not a report.
• Self-serve share rate. Portion of asset deliveries flowing through share links and portals rather than email and chat. This measures whether the DAM changed behavior outside the core team — the whole point.
• Time-to-available. How long from upload to enriched-and-findable. If the pipeline handles it in minutes, uploading stays effortless and people keep doing it.
• Active users vs. invited users. The bluntest adoption number. If it stalls, the cause is almost always an old path still open (Phase 5) or a search that doesn't deliver (Phase 2).

Report these monthly against the Phase 1 baseline ("finding an asset used to mean asking Marta"). That narrative is what unlocks the next team's migration slice — and, eventually, budget conversations, where the cost guide helps frame the totals.

The anti-patterns, collected

• Big-bang migration — moves everything, launches nothing. Slice it.
• Over-engineered taxonomy — forty fields nobody fills. Five fields, controlled vocabularies, automation for the rest.
• Hand-tagging the backlog — humans doing what the ingest pipeline does better. Correct, don't create.
• Launching to everyone — support load with no proven model. Pilot first.
• Leaving the old drive open — habit beats quality. Close the old path.
• No metrics — without search success and self-serve rates, you can't tell adoption from silence.

The cheapest way to pressure-test this plan is on a live system with your own files — start with freedam's free plan and run Phase 1 this week.