Custom columns and content types determine whether migrated SharePoint content remains searchable and filterable after cutover. Four tools handle them very differently.
| Metadata type | Clone Master | SPMT | MigrationWiz | ShareGate |
|---|---|---|---|---|
| Text, choice, number, date columns | Preserved | Preserved | Partial; requires configuration | Preserved |
| Content types | Preserved if mapped | Preserved if present at destination | Limited; needs pre-migration setup | Full mapping UI |
| Managed metadata (term store) | Same-tenant: yes. Cross-tenant: requires term mapping | Same-tenant: yes. Cross-tenant: limited | Often migrates as plain text; term links lost | Built-in term store mapping |
| Created and Modified dates | Preserved | Preserved | Preserved | Preserved |
| Created By / Modified By | Preserved when user exists at destination | Preserved when user exists at destination | Depends on user mapping file | Built-in user mapping |
| Version history | Preserved | Configurable; defaults to latest version only | Limited; major versions only in most plans | Full history with timestamps and authors |
| Lookup columns | Same-site lookups migrate; cross-site lookups break | Same-site lookups migrate; cross-site lookups break | Typically migrate as plain text | Lookup remapping available |
| Cross-tenant migrations | Yes | Not designed for cross-tenant | Yes | Yes |
What is metadata in a SharePoint migration context?
In a SharePoint migration, metadata is everything stored about a file or list item beyond the file content itself: column values, content type assignments, term store-linked fields, the identity of the user who created or last modified the item, and the full version history of changes. Migrating these fields accurately is what separates a functional migration from one where files arrive as a flat dump, stripped of the structure that made them findable and governed. A site where documents land under the wrong content type, or where managed metadata columns hold plain text instead of taxonomy links, typically requires weeks of manual remediation after cutover.
Three metadata types that commonly cause problems
Managed metadata and term store fields
Managed metadata columns link each item's value to a term in the tenant's term store. Within a single Microsoft 365 tenant, these links survive migration cleanly because the source and destination share the same term store. Across tenants, term stores are separate. Source terms don't exist at the destination by default, so tools that skip explicit term mapping write the text label into the column and sever the underlying link. Filtering by term stops working, and Microsoft 365 Copilot cannot ground responses against the taxonomy correctly.
The practical fix is to pre-create matching terms in the destination term store before the migration run begins. For migrations using Clone Master, creating the destination term structure first is the recommended pre-migration step. The cross-tenant library migration guide covers this preparation in detail.
Lookup columns
Lookup columns reference items in another SharePoint list within the same site. When that list exists at the destination with matching items, the lookup survives intact. When the referenced list is absent or contains different items, the lookup column arrives blank or broken. Cross-site lookup columns almost always break during migration because the referenced list lives at a different URL after migration. No current tool migrates broken cross-site lookups cleanly; the right approach is to audit and simplify lookup dependencies before the migration run, not after.
People and group columns
People columns store references to Entra ID accounts. Same-tenant migrations carry these references without issue. Cross-tenant migrations require that the referenced accounts exist in the destination tenant, either as full members or as guests. Without a user mapping file that ties source accounts to destination accounts, people columns default to the migration service account or arrive empty. Preparing the mapping file before cutover and testing it against a pilot library is the single step that has the highest impact on data quality for cross-tenant migrations.
How each tool approaches metadata
Clone Master is built for SharePoint Online and preserves column values and content types as part of its standard migration process. It handles cross-tenant scenarios directly, which is the case most other tools sidestep. For best fidelity, prepare a user mapping file and create destination content types and term store terms before the migration run. Version history carries across intact, which matters when version records serve as a compliance audit trail.
SPMT (SharePoint Migration Tool) is Microsoft's free utility, originally designed for migrating file shares and on-premises SharePoint content into SharePoint Online. For same-tenant SharePoint-to-SharePoint migrations, it handles most column types reliably. Content types must exist at the destination before SPMT runs, or items will land under the default content type. SPMT does not support cross-tenant migrations; it is the right choice when the source and destination share the same Microsoft 365 tenant and the content is relatively straightforward.
MigrationWiz from BitTitan is a cloud-based platform primarily optimised for mailbox and file-share migrations. Its SharePoint support handles file delivery and basic metadata reliably. SharePoint-specific metadata such as managed metadata term links and content type assignments requires additional project configuration and is not always preserved by default. For teams whose primary goal is file delivery rather than metadata fidelity, MigrationWiz is efficient; for sites where custom columns drive business workflows, plan for post-migration remediation work.
ShareGate Migrate was built specifically for SharePoint and offers the most complete metadata handling of the four tools: a column-mapping interface, a term store mapping tool, and built-in user mapping. It preserves version history with full timestamps and author data. It is the most expensive option, most justifiable for large migrations where metadata fidelity directly affects compliance requirements or search quality.
Decision matrix: which tool fits which scenario
| Scenario | Recommended approach |
|---|---|
| Same-tenant migration, mostly standard text and choice columns | SPMT or Clone Master - both handle this reliably at low cost |
| Cross-tenant migration with managed metadata taxonomy in use | Clone Master or ShareGate - pre-create the term structure in the destination first |
| Migration with significant lookup column dependencies | Audit and simplify lookups before migrating; no tool migrates broken cross-site lookups cleanly |
| File archive migration with minimal custom metadata | Any tool; SPMT or MigrationWiz is cost-effective for this scenario |
| Compliance requirement to preserve Created By and Modified By accurately | Prepare a user mapping file and test one library before full cutover, regardless of tool |
| Version history required as an audit record post-migration | Clone Master or ShareGate - confirm version migration is enabled before the run starts |
Before choosing a tool, take stock of the column types, content types, and managed metadata fields in use across the libraries being migrated. Report Master can export a library-level inventory to Excel, which is the fastest way to scope the pre-migration preparation work and avoid surprises mid-run.
Frequently Asked Questions
Does SPMT preserve content types during SharePoint migration?
SPMT preserves content types if the same content type already exists in the destination site. If the content type is absent, SPMT files items using the default library content type, discarding any source-side assignment. For cross-tenant migrations, content types must be pre-created in the destination tenant before the migration run begins.
What happens to managed metadata fields when migrating to another SharePoint tenant?
Each Microsoft 365 tenant has its own term store, so source-tenant terms do not automatically exist at the destination. If matching terms are absent, managed metadata fields typically migrate as plain text, losing their taxonomy link. The fix is to create matching terms in the destination term store before migrating, or to plan a remap pass after cutover.
Can I preserve the Created By and Modified By fields during a SharePoint migration?
Preserving these system fields requires the source user accounts to exist in the destination tenant as licensed users or guests. If a user exists in both tenants, most migration tools can write the original author into these fields. If the user does not exist at the destination, the field shows the migration service account. A user mapping file prepared before cutover significantly improves fidelity, particularly in cross-tenant scenarios.