Migrate SharePoint Document Libraries With Metadata
Files move easily. The columns describing them do not, because SharePoint ties metadata to term store GUIDs and content type IDs that a copy cannot carry on its own. Build the taxonomy, the site columns and the content types in the target first, then move the document library into a structure that already matches.
What actually moves with a document library?
Files and folders leave a document library with almost nothing to think about. Metadata is the part that fails, and it fails in a way that looks fine on the first screen.
Open a migrated document library and the documents are there, the counts match, the folder tree looks right. Then somebody sorts by Department and the column is empty. Or it shows a forty character string that nobody can read. The content arrived. The thing that made it findable did not.
That happens because SharePoint does not store the word Finance in your column. It stores a pointer to a term in the term store, identified by a GUID. It does not store a content type by name either. It stores a hierarchical ID. Move the files into a target where those identifiers do not exist, and every managed metadata column has a reference with nothing on the other end.
Every failed metadata migration I have seen had the same root cause. Somebody moved the document library first and planned to sort out the taxonomy afterwards. There is no afterwards.
Jamie Kaler Marketing Head and Content Strategist, RecoveryTools
Why does the order decide whether metadata survives?
Because a document library is the last thing in the chain, not the first. Everything it refers to has to exist before the files arrive.
The dependency runs one way. Terms live in the term store. Site columns point at term sets. Content types group site columns and inherit from a parent. A document library then applies content types and columns to the files inside it. Reverse that order and the library lands with references that resolve to nothing, which is why values come across blank.
Blank is the good outcome for a document library. The worse one is partially correct. A column that exists with the right name but was recreated as plain text instead of managed metadata will accept values and look healthy, and it will never work with filters, refiners or anything taxonomy driven again. Nobody notices for months, and by then the document library is in daily use.
So the sequence is fixed. Term store, site columns, content types in parent to child order, hub publishing, then the document library. The wider cutover sequence around it is in the Microsoft 365 migration planning checklist.
What happens to the term store between tenants?
Nothing automatic. The term store is a tenant level service, so a second tenant starts empty and the terms have to be recreated there before any document library that uses them moves.
Three traps come with that.
- Term GUIDs have to line up. A managed metadata value is a pointer to a term ID. Recreate the term by hand with the same label and you get a new ID, so the pointer still misses. Values that arrive looking like long random strings are telling you exactly this.
- Closed term sets reject anything they do not know. If the target term set is closed and the term is missing, the write fails rather than creating it. Open term sets hide the problem by adding terms you did not plan for.
- Global term groups need the right role. Migrating term groups at tenant level needs Term Store Administrator on both the source and the target account. Without it the site level terms move and the global ones quietly do not.
Microsoft's own SharePoint Migration Tool adds a condition on top. It handles only one Managed Metadata Service term store marked as the default for the site collection, and if more than one is set as the default, it cannot decide which to read. The term groups, term sets and terms stay behind, and the managed metadata columns that referenced them break. The fix sits in Central Administration under Manage service applications, in the properties of the Managed Metadata Service Connection, where only one connection should carry the default storage location setting. More of those conditions are listed in SharePoint Migration Tool limitations you hit in week one.
Why do content types break after the files land?
Because SharePoint identifies a content type by a hierarchical ID rather than by its name. Document is 0x0101, and a child type extends its parent's ID. Recreate a type by hand in the target and it gets a new ID, so SharePoint treats it as a different type with the same name.
Everything downstream inherits that problem.
- Parents first, always. A child type whose parent is missing or carries a different ID loses the inherited columns, and the failure shows up only once content is uploaded.
- Site columns match on internal name. The internal name and the field type both have to match, so a column rebuilt with a friendly name that differs underneath will not bind.
- Lookup columns store a list ID. That ID belongs to the source list, so it needs remapping in the target or the lookup resolves to nothing.
- Calculated columns break silently. Rename or drop a referenced column and the formula fails rather than warning.
- The Content Type Hub is tenant level. Publish the hub types in the target and let them sync before the sites move, or subscribing sites create disconnected duplicates instead of binding to the published type.
Tools that merge content types by name at the destination are the ones to watch. The result looks correct in library settings and skips column updates underneath, so the document library reports a clean migration while half the columns never bound.
Move the library once the structure is already there
RecoveryTools SharePoint Migrator carries document libraries, content types, managed metadata and version history between tenants, and the read only scan reports your columns and term bindings before anything moves.
No credit card, no sign-up. Runs on Windows 11, 10 and Windows Server.
How do you migrate a document library with metadata?
Run it in this order. Steps one to four are the project. Step seven is the part people think the project is.
- Inventory the document library structure, not the files. List the content types with their IDs and parent IDs, the site columns with internal names and field types, and which sites subscribe to hub types. Numbers of documents matter less than this list.
- Recreate the term store in the target. Term groups, term sets and terms, with IDs preserved rather than retyped. Set the default storage location on one connection only.
- Rebuild the site columns. Matching internal names and matching field types, and managed metadata columns bound to the new term sets rather than created as text.
- Recreate the content types parent to child. Preserve the original IDs. A type rebuilt with a fresh ID is a different type to SharePoint even when the name is identical.
- Publish the hub types and wait for the sync. Subscribing sites need the published type available before they receive content, otherwise they bind to a local copy.
- Pilot one real document library. One with unique permissions, a managed metadata column and at least one custom view. Time it and check the columns before scaling.
- Migrate the document library in waves. Off peak, with incremental passes for the delta. Large libraries also attract throttling, covered in SharePoint migration throttling errors and how to avoid them.
- Set content types and defaults on the library. Default content type, column order, required fields and the views, because views are rebuilt rather than carried and nobody checks them until Monday.
Permissions run on a separate track from metadata and need their own mapping, described in how to migrate SharePoint permissions to another tenant. The links people already hold to those files are a third track again, set out in what happens to SharePoint sharing links after migration.
Which library limits catch you mid migration?
These are platform ceilings rather than tool ceilings, so no product removes them. Read them before sizing the document library waves.
| Limit | Value | What it means in a migration |
|---|---|---|
| List view threshold | About 5,000 items | Cannot be changed in SharePoint Online. Views and some operations block above it |
| Threshold warning | 3,000 items | List settings starts warning here, which is your cue to index and filter |
| Items per library | 30 million | The hard ceiling. Reached only by document libraries nobody has pruned |
| Unique permissions | 50,000 supported | Microsoft recommends staying under 5,000. Flatten before moving |
| Lookup join threshold | 12 joins | Lookup, Person and workflow status columns all count toward it |
| Query columns | Over 8 is blocked | A view packed with lookups fails after migration rather than during it |
The threshold is the one that bites. A document library of 40,000 files migrates without complaint and then refuses to show a sorted view, because the view was never indexed and the source farm happened to be more forgiving. Index the columns people sort on, and build document library views that filter rather than views that scroll.
Timing for libraries at that size is worth calculating rather than guessing, which is covered in how long does a SharePoint migration take, and the licensing around it in SharePoint migration cost.
How do you verify the metadata landed?
Counting files in the document library proves the copy ran. It proves nothing about the columns, and the columns are what the business will judge.
- Sort and filter by a managed metadata column. If it sorts, the binding is real. If it shows blanks or long random strings, the term IDs did not match.
- Open the document library settings and read the content type IDs. Compare them with the source list you built in step one. Same name with a different ID is a failed migration wearing a good disguise.
- Check one document of every content type. Required fields populated, inherited columns present, default values applied.
- Open every custom view. Views are rebuilt, not carried, and a view that lost a column looks like missing data to the person using it.
- Test one lookup column. Lookups point at a list ID, so this is where remapping failures surface first.
- Compare version counts on a known file. Version history is its own question, answered in does SharePoint version history migrate between tenants.
Teams without spare hands for that pass hand it to our cloud migration service, which runs the structure build before the content rather than after it.
Frequently asked questions
Does metadata migrate with a SharePoint document library?
Only if the structure exists in the target first. Managed metadata values are pointers to term GUIDs and content type IDs, so the term store, site columns and content types have to be built before the document library moves. Move the files first and the columns arrive blank.
Why are my managed metadata columns empty after migration?
The term IDs did not match. Terms recreated by hand in the target get new GUIDs, so the pointer in every migrated item resolves to nothing. Values that appear as long random strings are the same fault showing a raw ID instead of a label.
Do content types migrate between tenants?
Not by name. SharePoint identifies a content type by a hierarchical ID, with Document as 0x0101 and child types extending the parent. A type rebuilt with a new ID is a different type, so preserve the IDs and create parents before children.
How do you migrate the SharePoint term store?
Recreate term groups, term sets and terms in the target with their IDs preserved, before any content moves. Global term groups need the Term Store Administrator role on both accounts. Closed term sets reject values whose terms are missing, so check those first.
What is the 5,000 item limit in a document library?
The list view threshold, which blocks views and some operations above roughly 5,000 items and cannot be changed in SharePoint Online. A single document library can hold 30 million items. The threshold limits what a single view returns, not what the library stores.
Do views and column settings move with the library?
Views are rebuilt rather than carried, so expect to recreate custom views, column order, required fields and default values after the content lands. Put it in the plan instead of discovering it from a user on day one.
Where to start this week
Export your content types with their IDs. Not the file counts, the IDs, and the site columns with their internal names beside them.
That export is the migration. Everything after it is copying, and copying a document library is the part a tool does for you. If the IDs on the target match the IDs on that sheet, the metadata lands. If they do not, no amount of re-running the document library will fix it.
Most teams discover this backwards, after the content is already in the new tenant and the columns are empty. Spend the week on the taxonomy instead, and the document library becomes the easy part it should have been.
Jamie blends strategic marketing insight with technical writing, turning migration and recovery topics into guidance that works for technical and general readers alike.
Published 9 October 2026. Term store conditions and library limits come from managed metadata migration and list view threshold for large lists and libraries.