Run a permissions audit before you migrate SharePoint

A SharePoint migration carries your permissions over whether they make sense or not. Broken inheritance, accounts that were disabled years ago, sharing links nobody remembers creating, all of it comes along for the ride, or worse, quietly doesn’t. The audit that catches this gets rushed more often than it gets done properly, because it’s not glamorous and the deliverable is “the same thing, but cleaner.”

Here’s the trade you’re actually making. Skip or under-do the audit and you don’t avoid the work; you just move it. Instead of a contained block of cleanup before cutover, you get an open-ended stream of access problems afterward. Each one surfaces as a confused user and a support ticket.

Why the source farm, not the destination

The problems already exist. They’re sitting in your SP2016 or SP2019 farm right now. Migration doesn’t introduce them and it doesn’t fix them; it just relocates them to a faster, more visible platform where they’re easier to trip over.

So the audit runs against the source. You want the full picture before SPMT (the SharePoint Migration Tool) starts copying, because some of what’s wrong will not survive the trip intact, and you’d rather know that in advance.

The five things to find

For every site you’re about to migrate, check these:

1. Broken inheritance, at site, list, and item level. Someone clicked “Stop Inheriting Permissions” years ago and moved on. Every break is a separate access list to migrate, validate, and explain to whoever owns the site now. Don’t just check sites; lists and individual items break inheritance too.
2. Orphaned access. AD users whose accounts were disabled or deleted but still appear on permission lists. This one matters more than it looks, see the next section.
3. External sharing. Anonymous links, “everyone except external users” misconfigurations, guest accounts that haven’t logged in for two years. SharePoint Online’s sharing model often behaves differently from your farm, group-connected sites default to internal-only, and tenant guest settings may be tighter or looser than you expect. Mismatches surface as access failures.
4. AD-group-to-SharePoint-group mapping. AD groups that became SharePoint groups that became Microsoft 365 groups, same name, different identity, mostly different membership. SPMT does not migrate AD groups as SharePoint group mappings at all, so anything relying on that needs a plan before cutover.
5. Unique-permission sprawl. Lists and libraries where thousands of items have been individually permissioned. This is fragile and slow, and SharePoint Online caps unique permission scopes at 50,000 per list. A library quietly approaching that ceiling is a problem you want to find now, not on migration day.

The orphaned-account trap

This is the one most worth slowing down for, because the common assumption about it is wrong.

You might expect SPMT to carry a disabled account’s permission over as a dead entry you can clean up later. It doesn’t. If SPMT can’t map an account to an Entra ID user, it does not migrate that permission. The content silently falls back to the destination’s default permissions. The grant isn’t carried over as a broken entry; it’s simply dropped.

That’s the danger. Not clutter, not noise. A silent gap between what your audit said and what actually migrated. SMAT (the SharePoint Migration Assessment Tool) flags these accounts as NoMatch in its identity report, which is exactly why you run it before migrating rather than discovering the gap afterward.

(Worth separating out: the “Account is no longer accessible” label you sometimes see in SharePoint Online is a different thing. That appears when a user who was successfully migrated is later deleted in Entra. It’s not an SPMT artifact.)

What the audit looks like in practice

The inventory step is the part people get wrong, so be precise here.

PnP PowerShell, the modern PnP.PowerShell module, works against SharePoint Online only. It cannot connect to an on-prem SharePoint Server farm. Your source farm is on-prem, so PnP PowerShell is the wrong tool for this audit.

For the source farm, you have two good options:

• SharePoint Server Management Shell, the Microsoft.SharePoint.PowerShell snap-in, run directly on a farm server. This gives you full enumeration of sites, groups, and direct user grants.
• SMAT (SharePoint Migration Assessment Tool), Microsoft’s tool, which generates a complete identity report including the NoMatch flags described above.

Click to zoom

The pattern I follow:

• Pull the full permissions inventory with the Management Shell or SMAT, every site, list, group, and direct user grant.
• Cross-reference user identities against AD and Entra to flag disabled and deleted accounts.
• List every external-sharing entry point in one column: who has access, when it was granted, whether they’re still relevant.
• Note every permission level customized away from the defaults, and document why.

The output is a one-page-per-site report. The site owner reviews it, approves it, signs it. Then you migrate.

Click to zoom

How long it actually takes

Honest expectation-setting: this isn’t a three-hour job, and pretending it is sets the wrong scope.

Permission enumeration across dozens of site collections is a multi-hour unattended scan on its own. You start it and walk away. After that comes the human part: triage with site owners, deciding what to fix, what to leave, what to document. Think of it as a day of work, not a week. Mostly scan time you don’t babysit, plus a half-day of focused review.

The cost of skipping it

There’s no clean arithmetic here, and you should be suspicious of anyone who gives you one. But the shape of the trade is clear.

A pre-migration audit is a known, contained block of work that happens before cutover, on your schedule, with site owners in the room. Skipping it doesn’t remove that work; it converts it into an open-ended drip of mystery access tickets afterward. Each one arrives whenever an affected user next hits the content, each one carrying the quiet message that “the migration is broken.”

A day of unglamorous PowerShell and review beats months of that. Run the audit, properly.