Published: 26 May 2026 | Category: Migration and Governance
You have just finished a 50,000-file migration across SharePoint tenants. The files arrived. The folder structure looks correct. Then someone opens a document and the columns are blank. The Status field that drove the team's workflow shows nothing. The managed metadata tags that made the library searchable are gone. The modified date is today's date, not the date the document was last edited.
This is not a tool defect or a one-off failure. Metadata loss is one of the most predictable outcomes of a SharePoint migration that did not plan for it. Understanding the five most common failure modes turns a painful post-migration cleanup into a problem you can largely prevent before the first file moves.
Why Does SharePoint Migration Lose Metadata?
Metadata loss happens for one of three reasons: the destination environment is not ready to receive the metadata (missing columns, missing term store terms, missing content types); the migration tool lacks the API permissions to write to system fields; or the metadata type is fundamentally non-transferable between tenants without deliberate mapping work. Most losses fall into one of these three buckets - all avoidable with preparation.
1. Managed Metadata Columns Arrive Empty
This is the most disruptive metadata loss in cross-tenant migrations, and the most commonly underestimated during project scoping. Managed metadata columns in SharePoint are backed by term store entries: taxonomy terms that live in the source tenant. When content migrates to a destination tenant, those term store references point to IDs that do not exist in the destination's term store. Both the file and the column arrive, but the column value is blank - the term it referenced has no equivalent in the destination.
Fixing this requires two steps completed before any content migration runs. First, replicate the relevant term store structure in the destination tenant: create the term sets and terms that the source content uses. Second, map source term IDs to destination term IDs so the migration tool can translate references during the copy. Tools that support cross-tenant migration handle this mapping as part of their configuration; the data must be correct before the job starts.
Organisations that skip term store preparation discover the problem only after migration, at which point re-populating managed metadata columns at scale requires either re-running the migration with the correct configuration or scripting a bulk update based on other column values. Neither option is quick.
2. Custom Column Values Depend on Destination Schema
A text column called "Project Code" in the source library needs to exist as a column with the same internal name and field type in the destination library before migration runs. If it does not, the migration tool has nowhere to write the value. The file arrives; the column value is silently dropped.
Content-type-bound columns make this harder. If the source library uses a content type that defines columns, and the destination library does not have that content type registered, migrated items default to the library's base content type. Any column exclusive to the original content type is either missing from the destination schema or unpopulated.
The practical implication: schema provisioning in the destination must precede content migration. This means creating site columns, content types, and library settings before the first file moves. On complex migrations, schema preparation takes as long as the migration itself and is consistently underestimated during project planning.
For a comparison of how migration tools approach schema mapping, see the Clone Master vs ShareGate vs Migration Manager comparison.
3. Created and Modified Dates Reset to Migration Time
Every file in the destination will show today's date unless the migration tool explicitly writes to SharePoint's system fields. SharePoint exposes two system fields on every file: Created and Modified. In an audit context, these dates are often the primary evidence for questions like "who approved this document and when." A 10-year-old contract library has documents whose created dates matter for legal and compliance reasons.
When a migration tool uploads a file to the destination via the standard SharePoint file upload API, SharePoint sets both fields to the current timestamp. Every document arrives showing today's date as its creation date, regardless of when it was originally authored. On a library with a decade of history, this collapses the entire timeline into a single moment.
Preserving original dates requires the migration tool to write to the system fields directly using an elevated API call after the file upload completes. This is possible in SharePoint Online, but it requires the migration account to have appropriate permissions and the tool to implement it deliberately. Not all tools do. Before selecting a migration tool, verify whether it preserves original Created and Modified dates, and test it against a sample library before committing to the full run.
Version history timestamps carry the same risk. If version history is migrated, the timestamp on each historical version must also be written explicitly, not inferred from upload time.
4. Unique Item-Level Permissions Are Dropped or Flattened
Some SharePoint libraries contain files or list items with permissions that differ from the library's inherited structure. A sensitive contract visible only to the legal team, or a performance review item restricted to HR and the site owner, represents a permission structure that exists only as SharePoint metadata. It is invisible in the file itself.
In a same-tenant migration, tools that support permission migration can copy these unique permission assignments. In a cross-tenant migration, the user and group objects that those permissions reference do not exist in the destination tenant. Every permission entry points to a principal identified by its Entra ID object ID, and those IDs differ between tenants.
Migrating permissions cross-tenant requires a user mapping table: a configuration that matches each source principal to its destination equivalent. Building that mapping is a manual coordination step between both tenants' admin teams. Migrations that omit this step arrive in the destination with unique permissions reverting to library inheritance - restricted content may become visible to anyone with library access.
Where permission fidelity is a compliance requirement, treat permission migration as a first-class workstream in the project plan - not an afterthought appended after content has already moved.
5. Content Types Are Not Registered in the Destination
Content types define a reusable schema: a set of columns, a document template, and workflow associations bundled together. A library using the "Marketing Brief" content type in the source tenant has every file with that type applied. When migrated to a destination that does not have "Marketing Brief" registered, each file defaults to "Document" or the library's base content type. The content type identity is lost. Any columns that belonged exclusively to that type are either absent from the destination schema or empty.
Content types registered in the tenant content type hub are portable across sites within the same tenant but do not transfer to a different tenant. In cross-tenant migrations, recreate every custom content type in the destination - manually, via PnP PowerShell provisioning, or through a site template - before content migration begins. The order matters: if content arrives before its content type exists, the assignment is dropped.
Learn how Clone Master handles cross-tenant migration fidelity
How to Protect Metadata Before a SharePoint Migration
The preparation pattern that produces clean metadata migration outcomes has five components:
- Audit source metadata before you migrate anything. Run a column inventory across all libraries: what columns exist, what types they are, which are managed metadata, which are lookup columns, and which content types are in use. ShareMaster's Report Master exports this inventory to Excel, giving you a structured baseline. Without this audit, schema preparation in the destination is guesswork.
- Provision destination schema first. Create all required site columns, content types, and term store terms in the destination before any content migration runs. Test that each column accepts the expected values and that content type inheritance is configured correctly. A schema validation pass on an empty library costs an hour; fixing it after 50,000 files have migrated costs days.
- Build the user and group mapping table for cross-tenant migrations. Match every source principal (user account, security group, Microsoft 365 group) to its destination equivalent. This is a coordination exercise between both tenants' admin teams and requires access to both Entra ID directories. The mapping must be complete before the migration job runs; partial mapping produces partial permission fidelity, which is often worse than no permission migration at all.
- Run a pilot migration on a representative sample. Migrate a single library that contains diverse column types, managed metadata, unique permissions, and a content type that is not the base Document type. Check every column value, date, content type, and permission assignment in the destination before the full run. A pilot of 500 files surfaces configuration problems while fixing them is still manageable.
- Trim version history before migrating. Version history multiplies the data volume and the number of system field write operations the migration tool must complete. Migrating 200 versions per file quadruples the timestamp-correction work and can extend a job by days compared to a trimmed equivalent. See the guide to trimming SharePoint version history for the steps and tools available.
Frequently Asked Questions
Does SharePoint migration preserve column values?
It depends on the migration tool and on whether the destination schema was prepared beforehand. Dedicated tools can migrate custom column values when matching columns exist in the destination library before migration runs. Managed metadata columns require the destination term store to be populated first. Text, number, and date columns migrate more reliably than managed metadata or lookup columns.
Are created and modified dates preserved in SharePoint migrations?
Only if the migration tool explicitly writes to the system date fields after upload. Tools that do not implement this step will show today's date as the creation date for all migrated files. Always verify date preservation with a pilot migration before running the full job.
Do SharePoint migrations preserve unique item-level permissions?
Full-fidelity tools can migrate item-level permissions in same-tenant scenarios. Cross-tenant migrations require a user mapping table that matches source principals in Entra ID to their destination equivalents. Without mapping, unique permissions default to library inheritance at the destination.