To migrate SharePoint to Microsoft 365 without breaking permissions and governance, map permissions before you move a single site: inventory every site collection’s unique permissions, broken inheritance, orphaned users, and legacy Active Directory groups, then decide deliberately which of those structures should survive the move and which should be replaced by Microsoft 365 groups and a governed target model. Permissions break in migrations for two reasons: legacy identities that have no valid mapping in the target tenant, and inheritance structures the migration tool flattens silently. Both are findable in assessment, before they become an outage.
That is the answer in two sentences and a warning. The rest of this page is the sequence that preserves access wave by wave, the restructure or carry-over decision that determines whether the migration retires permission sprawl or relocates it, and the tenant governance work that has to be in place before broad cutover.
Why Permissions Break in SharePoint Migrations
SharePoint Server estates accumulate years of item-level permission exceptions, broken inheritance, and Active Directory groups whose members left long ago. Migration tooling copies what it can resolve and silently drops what it cannot, which is why the failure surfaces as a help desk queue two days after cutover rather than an error during the move. The second failure is subtler: governance features that did not exist on the server side, such as tenant sharing policies, sensitivity labels, and external access rules, default to values nobody chose. An estate can arrive with every permission technically intact and still be ungoverned in ways an auditor will find.
The Sequence That Preserves Access
- Assessment and permissions inventory. Map every site, library, and item-level permission exception. Flag orphaned users, disabled accounts, and AD groups that will not resolve in Entra ID. This inventory is the migration’s governance contract: every wave gets validated against it.
- Design the target permission model. Decide restructure versus lift and shift per site. A migration is the one moment you can retire years of accumulated permission sprawl; carrying it over unexamined just relocates the audit problem into a new tenant.
- Stage the move in validated waves. After each wave, verify a sample of users can reach exactly what they could reach before, and nothing more. Broken inheritance and dropped item-level exceptions surface here, while the wave is small enough to fix quietly.
- Re-establish governance in Microsoft 365. Sharing policies, sensitivity labels, external access, and site provisioning rules are tenant-level decisions that had no equivalent on SharePoint Server. Set them before broad cutover, or the clean migrated estate starts sprawling on day one.
- Post-migration stabilization. Hold a defect window where permission gaps are triaged daily, then hand the estate to operations with the permission inventory as its documentation.
Restructure or Carry Over?
The default answer is restructure at the site level and carry over at the item level. Site-level structures map cleanly to Microsoft 365 groups and modern sharing, and rebuilding them is cheap during a migration and expensive afterward. Item-level exceptions are where the real business logic hides, and flattening them wholesale is how a migration breaks the one library a contracts team depends on. The inventory from step one is what lets you make this call per site instead of guessing estate-wide.
Who Does This Work
i3solutions has run SharePoint migrations since 1997, including staged multi-version paths from SharePoint 2010 and 2013 through an interim 2016 farm into SharePoint Online, and moves into GCC and other regulated configurations where the permission model is an audited artifact rather than an afterthought. i3 plans and runs governed Azure and Microsoft 365 migrations with senior, U.S.-based teams, and the usual first step is a SharePoint Migration Review that maps your environment, flags the risks, and sequences the waves. The full practice is described on our SharePoint migration services page, with migration consulting available when you want the plan reviewed before committing to execution.
Frequently Asked Questions
What breaks most often in a SharePoint to Microsoft 365 migration?
Permissions, in two forms: legacy identities and AD groups that have no valid mapping in the target tenant, and item-level permission exceptions that migration tooling flattens without an error. Both are detectable in a pre-migration inventory, which is why assessment is the step that decides how the cutover goes.
Should we clean up permissions before or during the migration?
During, using the migration as the forcing function. Cleaning up first on the server side means doing the work twice, since the target model uses Microsoft 365 groups and modern sharing that do not exist on the source. Inventory first, design the target model, and retire the sprawl as each wave moves.
How do we keep governance from regressing after cutover?
Set tenant-level governance before broad cutover, not after: sharing policies, sensitivity labels, external access rules, and site provisioning. A migrated estate without provisioning rules starts sprawling on day one, and retrofitting governance onto an active tenant is harder than arriving with it.
Can permissions survive a migration from SharePoint 2010 or 2013?
Yes, with staging. Very old versions cannot jump directly to SharePoint Online, so the path runs through an interim farm, and the permission inventory has to be validated at each hop. i3solutions has run staged multi-version paths from SharePoint 2010 and 2013 through an interim 2016 farm into SharePoint Online.
What does a permissions-safe migration cost for a regulated organization?
Scope drives it, and compliance scope drives it hardest. Full migration project cost for defense contractors with SharePoint customizations and CMMC compliance scope typically lands in the $100,000 to $300,000 range. A migration review scopes the real number for your estate before you commit.
How long does the permissions inventory take?
It is the fastest high-value step in the project: automated tooling enumerates the estate, and the analysis effort scales with how many sites carry unique permissions rather than with raw content volume. It runs inside the assessment phase, before any migration wave is scheduled.
Start With the Review, Not the Move
The migrations that break access are the ones that started with a tool license instead of an inventory. A SharePoint Migration Review maps your environment, flags where permissions and governance will bite, and sequences the waves, so the decision to migrate is made on your estate’s real shape. It is the difference between planning the move and discovering it.
If a SharePoint migration is on your calendar and the permission model is the part that worries you, a consultation can scope the review.
