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.

It used to be caught for you. The SharePoint Migration Assessment Tool produced an identity report that flagged unmappable accounts as NoMatch, and running it before migrating was the standard advice. That safety net is gone twice over: SMAT’s identity mapping stopped working on June 30, 2023, when Azure AD Graph was deprecated underneath it, and SMAT itself reaches end of support on October 1, 2026.

Microsoft points you at SPMT’s built-in scan instead, and you should run it, but be clear about what it does. The scan reports content and structure risks: unsupported workflows, item counts, unique permissions over the limit. It does not produce an identity map. Check its risk codes and you’ll find nothing equivalent to NoMatch.

So the cross-reference is now yours to do by hand, and it’s the step this whole audit turns on.

(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, use both of these, for different jobs:

• SharePoint Server Management Shell, the Microsoft.SharePoint.PowerShell snap-in, run directly on a farm server. This is the one that does the real work here: full enumeration of sites, groups, and direct user grants.
• SPMT’s scan, built into version 4.0 and later. It won’t enumerate identities, but it flags the structural problems from the list above, including lists that exceed the 50,000 unique-permission limit.

Click to zoom

The pattern I follow:

• Pull the full permissions inventory with the Management Shell, every site, list, group, and direct user grant.
• Cross-reference every identity against AD and Entra by hand, and mark which ones will actually survive the move.
• 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.