# Run a permissions audit before you migrate SharePoint > A pre-migration permissions audit is cheap insurance. Skip it, or rush it, and you discover broken inheritance, orphaned access, and dropped grants one mystery support ticket at a time after cutover. [Home](https://tenantcraft.ca/) [Insights](https://tenantcraft.ca/insights) Governance Plan Apr 15, 2026 6 min read Geri Crroj Microsoft 365 consultant, Niagara, Ontario 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. The 5-minute version - Audit permissions on the **source** farm before SPMT touches anything. - Find five things: broken inheritance, orphaned access, external sharing, AD-group mapping gaps, and unique-permission sprawl. - Pull the inventory with the **SharePoint Server Management Shell**, not PnP PowerShell (that’s SharePoint Online only). No Microsoft tool maps identities to Entra for you anymore, so that cross-reference is manual. - Document everything, decide what to fix, get site owners to sign off. - Then migrate. The audit is a day of work; the alternative is months of mystery tickets. ## 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. Don't fix everything The goal isn’t to repair every anomaly. It’s to _know_ about them before cutover, decide which to fix, and document the rest so the next person isn’t surprised. Some broken inheritance is intentional and correct. ## 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. > A permission you thought you’d documented just vanishes, and you find out when someone’s access is wrong. 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. ![A SharePoint permissions inventory report showing broken inheritance and orphaned accounts flagged across multiple site collections](https://tenantcraft.ca/images/permissions-inventory.png) Pre-migration audit The audit output: one reviewable view per site, with the anomalies separated out so a site owner can sign off on each. 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. ![A spreadsheet cross-referencing on-premises identities against AD and Entra. Each row shows the identity, its type, its AD status, whether an Entra match exists, and what migration will do with it. Rows with a disabled account, a deleted account, or an AD group with no Entra match are flagged as Dropped.](https://tenantcraft.ca/images/identity-crossreference.png) The cross-reference you build yourself Three rows here get dropped silently: a disabled service account, a deleted user, and an AD group with no Entra equivalent. Nothing flags these for you now. ## 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. Run this before you migrate anything Permissions Cleanup & Governance Prep Checklist PDF · 7 pages · 45 checkpoints [Email me the PDF](https://tenantcraft.ca/resources/guides/permissions-cleanup-prep) ## 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. TWENTY MINUTES, NO PITCH ## Tell me what is stuck. I will tell you what it takes. Same consultant from the first email to the last cutover. If I am not the right fit, I will refer you to someone who is. [Book a 20-min call](https://tenantcraft.ca/contact) [See published rates](https://tenantcraft.ca/pricing) --- _Canonical HTML: https://tenantcraft.ca/insights/permissions-cleanup-before-migration · Agent guide: https://tenantcraft.ca/llms.txt · Site map: https://tenantcraft.ca/sitemap-index.xml_