Your SharePoint data travels through a four-stage pipeline during migration: extract from source, transform to target shape, load into SharePoint Online, and verify against source. At each stage, specific things happen to permissions, metadata, content types, versions, audit history, encryption, compliance configurations, and data residency. Most data is preserved exactly; some is reshaped deliberately; a small portion may be deliberately or accidentally dropped depending on the migration plan and tooling. This guide walks each stage of the pipeline, names what happens to each category of content, and identifies the verification steps that catch problems before users do.
It is written for US IT leaders, security and compliance leads, SharePoint administrators, and digital workplace owners scoping a SharePoint Online migration and wanting an operational rather than abstract view of what the migration actually does to content.
The Data Migration Pipeline
The SharePoint data migration pipeline is four stages, regardless of tooling. Extract: the migration tool reads source content (SharePoint on-premise, SharePoint Online tenants being merged, file shares, OneDrive, third-party content systems) through native APIs or supported connectors. Transform: the tool reshapes content for the target - identity mapping, content type mapping, URL rewriting, sometimes metadata enrichment or trimming. Load: the tool writes content into the SharePoint Online target through Microsoft's supported migration APIs (SharePoint Migration Tool, Migration Manager, Microsoft Graph for some patterns), respecting throttling and large-file limits. Verify: the tool produces logs the project team uses to reconcile what arrived against what left, with manual or scripted sampling to confirm fidelity. Every commercial tool - SPMT, ShareGate, AvePoint, Quest, Metalogix - implements this pipeline differently; the operational pattern is identical.
|
Pipeline stage |
What happens |
Common failure mode |
|
Extract |
Read source content via API or connector |
Throttling, oversized items, corrupted items skipped |
|
Transform |
Reshape for target (identity, URLs, content types) |
Mapping miss, unintended trim |
|
Load |
Write to SharePoint Online |
Throttling, target structure mismatch |
|
Verify |
Reconcile target vs source |
Skipped step or unreviewed logs |
Permissions and Security Through Migration
Permissions are the most-touched piece of data during migration. SharePoint on-premise permissions are usually a mix of SharePoint groups, AD groups, individual users, and unique permissions broken from inheritance at the site, library, folder, or item level. During migration, identity has to be mapped from AD to Entra ID, group membership has to be replicated or restructured for Microsoft 365 groups, and permission breaks have to be either preserved or deliberately flattened. Most migration tools support multiple modes; the project team chooses. The data does not "lose" permissions in transit, but the resulting permission model in the target depends on the choices made during transform. A permissions audit before migration and a verification step after are the controls.
Metadata and Content Types
Metadata and content types are usually preserved during migration but often need deliberate work. Custom content types in the source must exist in the target before migration, or content arrives with default types. Site columns, term store entries, and managed metadata have to be migrated or recreated. Documents inherit content types and metadata from libraries; the migration tool maintains this where the target is configured correctly. The most common loss is in custom property mapping where on-premise SharePoint had loose schemas that the target tenant has tightened.
Versions and Audit History
Version history is preserved by most migration tools when the source library has versioning enabled, with caveats. Major versions are usually preserved; minor versions sometimes are; very large version histories sometimes hit tool-specific limits. Audit history - the record of who did what to which item - is rarely migrated because the source and target audit systems are structurally different (on-premise SharePoint audit vs Microsoft Purview audit). The practical pattern: confirm whether version history is required, choose a tool that supports the depth needed, and keep the source environment read-only for a retention window so historical audit queries remain answerable in the source.
Encryption in Transit and at Rest
SharePoint data is encrypted in transit during migration through HTTPS/TLS between the migration tool, the source, and the target. SharePoint Online encrypts data at rest by default with Microsoft-managed keys; customer-managed keys (Customer Key) are available for additional sovereignty requirements. The migration tool itself, depending on architecture, may temporarily stage data in cloud storage; the project team should confirm the staging encryption posture and retention. Microsoft's SharePoint Migration Tool and Migration Manager run inside the Microsoft trust boundary; third-party tools have their own posture that should be reviewed during tool selection. (See how Centric handles SharePoint data security during migration for the engagement-level controls.)
Verification and Rollback
Verification is the stage most often shortened and most often missed. The minimum verification pattern: item-count reconciliation by site and library, checksum or hash comparison on a sample of files, metadata-completeness checks against known content types, permissions verification on a sample of users, and a UAT pass by content owners in each business unit. Rollback for SharePoint migrations is rarely full-rollback (the target tenant is the new home); rollback usually means keeping the source environment read-only for a defined window so issues can be resolved by restoring individual items or reviewing source state. The plan should be explicit about rollback duration and ownership.
Compliance and Records
Compliance configurations need deliberate migration. Microsoft Purview sensitivity labels, retention labels, retention policies, DLP rules, and eDiscovery holds either move with content or have to be re-applied in the target. The pattern depends on the source: SharePoint Online to SharePoint Online (tenant-to-tenant) usually preserves labels with the right tool; on-premise to SharePoint Online generally requires re-labeling in the target. Records management - legal holds, records declarations, retention rules - needs explicit migration design and security/compliance sign-off. General guidance, not legal or compliance advice; consult counsel and your security function.
Data Sovereignty
Data sovereignty - where the content actually lives and who has jurisdictional access - is a 2026 conversation that did not exist for most SharePoint migrations five years ago. Commercial SharePoint Online stores content in Microsoft regional datacenters; multi-geo configurations let enterprises constrain content to specific regions for residency requirements. GCC, GCC High, and DoD environments serve federal and defense customers with stricter isolation. State and critical-infrastructure customers may have requirements that map to multi-geo or to specific environment choices. The data migration plan has to confirm residency before content moves, not after.
What Can Go Wrong With Data?
Data problems during SharePoint migration fall into recognizable categories. Silent skip: the tool reports completion but skipped items hit a limit; mitigation is log review. Identity mismap: user accounts in the target do not align with source, permissions break; mitigation is identity-mapping verification on a sample. Metadata loss: content arrives without expected properties because target content types were not pre-created; mitigation is content-type pre-creation. Version truncation: long version histories are partially preserved; mitigation is tool selection and library-specific decisions. Throttling: the target rejects writes at peak, content arrives slowly or partially; mitigation is throttling-aware batch design. Audit gap: queries against historical audit fail because audit did not migrate; mitigation is source-environment retention.
Frequently Asked Questions
Will all my SharePoint permissions transfer correctly?
Permissions transfer with the migration tool but the resulting model depends on choices made during transform. Preserve-unique-permissions modes carry the full source model; flatten-to-groups modes restructure for a cleaner target. Either is valid; the choice has to be deliberate.
Are document versions preserved?
Usually yes when the source library has versioning enabled, with depth depending on the tool. Confirm version-history retention requirements before tool selection.
What happens to file metadata?
Metadata is preserved when content types exist in the target. Custom content types must be pre-created or content arrives with default types and metadata loss in property fields.
Is data encrypted during migration?
Yes - HTTPS/TLS in transit, target-side at-rest encryption by default, with Customer Key available for additional control. Third-party tools may use intermediate staging; review the posture during selection.
Does audit history migrate?
Rarely - source and target audit systems are different. The practical pattern is to keep the source environment read-only for a retention window so historical audit queries remain answerable.
What about compliance labels and retention?
Microsoft Purview labels and retention need deliberate migration. Online-to-online usually preserves; on-premise-to-online usually requires re-labeling in the target.
How do we verify the migration was complete?
Item-count reconciliation, checksum sampling, metadata-completeness checks, permissions verification on a sample of users, and UAT by content owners. The migration tool report alone is not enough.
Conclusion
SharePoint migration data handling is well-understood, well-tooled, and almost entirely predictable - when the project plan addresses each stage of the pipeline deliberately. Permissions, metadata, versions, audit, encryption, compliance, and sovereignty each have established patterns. The migrations that lose data almost always lose it because a stage of the pipeline was skipped, a verification was abbreviated, or a tooling choice did not fit the source. A pre-migration assessment, a tool selection that fits the source, and a verification step that actually runs are the cheapest way to confirm the migration does what the plan says it does. Centric runs SharePoint Online migrations through its SharePoint migration & integration practice, as part of the broader Centric SharePoint consulting practice.
