Migrating from SharePoint to a DAM: a step-by-step playbook

No published guide describes how to move a media library from SharePoint into a DAM step by step. Vendors offer free migration services, and one case study reports 75,000 assets moved, but the steps, the mapping decisions and the timelines are not written down anywhere. This guide writes them down.

It is part 4 of a four-part series. Part 3 decided what moves and what stays; this guide assumes that decision is made. The general DAM implementation guide covers the project around the migration, including the pilot team and the training. This page covers the migration itself, in the order the steps happen.

Step 1: Fix the scope in writing

Write a one-page scope before touching any file. It lists:

• Which locations are in scope. Named SharePoint sites and libraries, named Teams channels, and named OneDrive accounts. Part 3 explains why all three have to be searched.
• Which content types move. Usually photography, video, design files, logos, templates and distributed finals. Documents stay.
• What will be deleted rather than moved. Working files older than a cut-off, exports that were never used, duplicates. Deciding this now saves more time than any tool.
• What "done" means. Every in-scope asset is in the DAM with metadata, every old link resolves somewhere useful, and the old libraries are read-only.

A migration without a written scope grows to include every file anyone remembers, and never finishes.

Step 2: Inventory what you have

You need a list of every file in scope with its path, size, type, dates and column values. SharePoint will not give you this from the UI beyond a few thousand items. The options:

• PnP PowerShell. Get-PnPListItem with paging exports a library's items and columns to CSV, including managed metadata values. This is the most complete method and the one a SharePoint admin will recognise.
• The Microsoft Graph API. Listing drive items recursively gives path, size, dates and hashes, but not custom columns. Good for a first count, less good for metadata.
• Sync and scan. Sync the library with OneDrive and run a file scanner on the local folder. Simple, but it hits the 300,000-file sync recommendation on large libraries and it loses column values.

From the export, produce four numbers per library: file count, total size, count by extension, and count by last-modified year. These numbers set the timeline in step 9, and they usually show that a large share of the library is old exports nobody has opened in years.

Find the problem containers at the same time: any folder over 100,000 items (permission inheritance cannot be changed on it), any library where views are already failing at the 5,000-item threshold, and any path near the 400-character limit. These are documented in part 1 and they are the places where the export tools also struggle.

Step 3: Remove duplicates before moving anything

A SharePoint media library that has been used for a few years contains the same image in several places: the original in a shoot folder, a resized copy in a campaign folder, a renamed copy in a Teams channel, and a re-saved copy in a designer's OneDrive. Moving all of them into the DAM moves the problem.

Two passes work:

1. Exact duplicates by content hash, from the inventory. These are safe to collapse without looking.
2. Near duplicates (resized, recompressed, cropped, re-exported) which a hash does not catch. A DAM with duplicate detection finds these after ingest; freedam's near-duplicate detection is built for exactly this pass. The practical sequence is therefore: collapse exact duplicates before the move, ingest, then review the near-duplicate groups the DAM proposes and keep one master per group.

Record which path was kept for each group. Step 8 needs it.

Step 4: Map columns and terms to DAM fields

This is the step that determines whether the migrated library is searchable on day one. Take every column from the inventory export and decide its destination. A mapping table has four columns: SharePoint column, DAM field, transformation, and what to do with empty values.

Typical decisions:

• Title, Description, Enterprise Keywords map to the DAM's title, description and tags. Keywords split on the semicolon SharePoint uses.
• Managed metadata columns map to DAM controlled vocabularies. Export the term set from the term store and import it as the vocabulary first, so values match. The taxonomy guide covers how to trim a term set that has grown.
• Folder path is often the only metadata a library has. Map path segments to fields: /Campaigns/2025/Spring/ becomes campaign = Spring 2025. Write the rule per library; do not try to write one rule for all of them.
• Created, Modified, Created By carry over as the asset's original dates and contributor, not as the ingest date.
• EXIF and IPTC inside the files are read by the DAM on ingest, so anything SharePoint ignored (Lightroom keywords, captions, copyright lines) appears without being mapped. Check a sample to confirm the fields you expect are present.
• Approval status columns, if any, map to the DAM's workflow state. See step 6.
• Columns with no destination are either dropped or kept as a generic "legacy" field for reference. Decide, and do not carry thirty unused fields into the new schema. The metadata guide explains why a small schema gets filled in and a large one does not.

Then decide what the DAM's AI does on ingest. Automatic tagging, OCR of text in images, transcription of video and face detection fill gaps that no SharePoint export has, and they run on the whole library rather than on new uploads only. Let them run, and plan a review pass rather than a manual tagging pass; humans correcting machine tags is roughly ten times faster than humans creating tags. The AI guide sets expectations for what needs review.

Step 5: Translate permissions

List every Entra group and SharePoint group that has access to an in-scope library, and every folder with unique permissions. Then build the role table from part 3: each group maps to one DAM role, and each folder with unique permissions maps to a collection with an access rule.

Two simplifications are almost always right:

• Collapse folder-level permissions that differ only in history. A library with 40 uniquely permissioned folders usually has three real audiences.
• Convert guest accounts into share links or portal access where the guest only downloads. Keep guest-equivalent accounts only for people who upload.

Record the mapping. It is the document IT will review, and it is what makes the "can see but cannot download" problem from part 3 avoidable.

Step 6: Decide what happens to versions and approval state

SharePoint keeps a version history. Most of it is not worth moving: intermediate saves of a video export are large and nobody will look at them. Move the current version of every asset, and move earlier versions only where the asset type needs them (logos and templates, where the previous approved version is sometimes requested). Note in the scope document that the rest stays in the read-only SharePoint library until its retention ends.

Approval state is different. If the SharePoint library had an "Approved" column, a folder named "Final", or an unwritten rule that anything in a given folder was approved, decide how that maps to the DAM's states before ingest. The DAM's version control and workflow features will manage state from then on; the migration has to seed it correctly once. Assets whose state nobody can vouch for should be ingested as "needs review" rather than as approved.

Step 7: Move in slices

Do not migrate everything in one operation. Migrate one library, one campaign or one asset type, check it, and repeat. The implementation guide explains why slices succeed where big-bang migrations are abandoned; the short version is that every mapping rule has an error you only find on real data, and a slice makes the error small.

The order that usually works:

1. The brand kit. Logos, fonts, templates, guidelines. Small, high value, used by everyone, and it makes the DAM immediately useful to the pilot team.
2. The current campaign. Whatever marketing is working on this month. Its users will test the mapping hard.
3. Product imagery. Large, well structured, easy to map from path or SKU columns.
4. Historical campaigns, newest first, stopping at the cut-off from the scope.
5. Video, separately, because of size.

For the transfer itself, the DAM's ingestion path decides the mechanics. freedam ingests from a WebDAV share, an S3-compatible bucket or Google Drive, and through the REST API with a sidecar of metadata per file. A common pipeline is: export the slice from SharePoint with PnP PowerShell to a staging folder or bucket, write the mapped metadata alongside it as CSV or JSON, and let the DAM's watched-folder ingestion pick both up. The ingestion glossary entry describes what happens to each file on the way in.

After each slice, check five things: count in equals count out minus deliberate deletions; a sample of ten assets has the metadata the mapping predicted; search for three things the pilot team searches for; previews exist for the design formats; and permissions behave for one person from each role.

Step 8: Redirect the old links

Every SharePoint page, Teams message, email and intranet article that linked to a moved file now points at a file that will soon be read-only or gone. This step is the one most migrations skip and then regret.

• For files that were linked from SharePoint pages and the intranet, edit the links to the DAM URL. The inventory export tells you which files were most linked; start there.
• For files people have bookmarked, leave a small "moved" document in the old location for a defined period, with the new link. This is manual and worth doing for the fifty most-used assets, not for all of them.
• For Teams channels, post a pinned message with the DAM's collection link for that team.
• Keep the mapping from step 3 (which path was kept for each duplicate group) and the mapping of old path to new asset URL, so that any request for an old link can be answered.

The DAM's own links do not need this treatment again: an asset's URL stays stable across versions, and a share link keeps working until its expiry.

Step 9: Timelines by volume

These are working estimates for the migration steps above, for a team that has done the scope and inventory. They assume the DAM's AI does the first tagging pass and humans review.

Video adds time in proportion to size rather than count; 2 TB of footage moves at the speed of the network between SharePoint and the DAM's storage, and that transfer should run unattended over nights and weekends rather than on the project's critical path.

The elapsed times are longer than the work in them because each slice waits for a check by someone with a day job. That is expected. A migration that reports 100% done in a week has usually skipped step 8.

Step 10: Decommission

When the last slice is checked:

1. Set the old libraries to read-only. Do not delete them.
2. Apply a retention label so that they are deleted on a date, after which nobody will still be looking for them. A year is common.
3. If the old libraries are large and the storage pool is tight, move them to Microsoft 365 Archive, which is billed at $0.05 per GB per month only for storage above the tenant's quota, rather than $0.20 for active storage.
4. Remove the guest accounts that were converted to share links in step 5.
5. Update the intranet's "where do I find" page, and the onboarding material for new staff.

Step 11: Tell people, twice

Send one message before the first slice moves, saying what will move, when, and where it will be. Send a second when the brand kit is live, with the link and the three searches that now work. Then let the pilot team from the implementation guide answer questions in their channels. The two messages matter more than a training session, because they arrive when people are about to look for something.

The checklist

1. Scope document: locations, content types, deletions, definition of done.
2. Inventory export per library with counts by type and year.
3. Exact-duplicate collapse from hashes.
4. Mapping table: column to field, transformation, empty-value rule.
5. Term sets exported and imported as vocabularies.
6. Role table: group to role, folder to collection.
7. Version and approval-state rules written down.
8. Slice order agreed, starting with the brand kit.
9. Per-slice checks: counts, sample metadata, three searches, previews, one user per role.
10. Near-duplicate review after ingest.
11. Links redirected for the most-used assets and pages.
12. Old libraries read-only, labelled, archived if large.
13. Two announcements sent.

Frequently asked questions

How long does it take to migrate from SharePoint to a DAM?

Two to three weeks for a library under 5,000 assets, six to eight weeks for up to 50,000, and about a quarter for hundreds of thousands, when the work is done in slices with a check after each one. The elapsed time is set by the checks and the link redirects, not by the file transfer.

Do I lose version history when I move from SharePoint to a DAM?

Only if you choose to. The usual choice is to move the current version of every asset, move earlier versions for the few asset types that need them, and leave the rest in the read-only SharePoint library until its retention period ends. The DAM keeps its own version history from the day of ingest.

Can I keep my folder structure?

Yes, and you should also convert it into metadata. Most DAMs can import a folder tree as collections, and the folder path is often the only metadata a SharePoint library has, so mapping path segments to fields (campaign, year, product line) gives every asset searchable values that the folder alone did not.

How do I export files and metadata from SharePoint?

PnP PowerShell exports a library's items and column values, including managed metadata, to CSV, and can download the files. The Microsoft Graph API lists drive items with paths, sizes and hashes but not custom columns. Syncing with OneDrive and scanning the local folder is simplest but drops column values and is limited by the 300,000-file sync recommendation.

What should stay in SharePoint after the migration?

Documents, records, anything under retention or legal hold, meeting recordings in Stream, and the intranet. Part 3 of this series gives the full split by content type.

This is the last part of the series. Start again with SharePoint as a DAM: the real limits, or go to the decision page. To run a first slice on real files, a freedam free plan ingests from a folder in an afternoon.