Customisation audit
Custom code that will not migrate
Find what has been added to your sites beyond content: custom actions and SPFx extensions, webhooks, field and form customizers, app permissions, custom property bag keys, site designs, classic publishing and branding, and whether custom script is allowed. One Excel sheet per kind. Nothing is changed.
What it tells you
- What on these sites will not come across in a migration?
- Which sites run classic script or publishing?
- Which apps were granted access to which sites?
How it runs
- Sign in. One sign-in when you click the tile.
- Choose sites. Tick sites, with or without subsites.
- Choose checks. Each check says what it reads and what it costs. List-level checks take one read per list.
- Run. One row per site with a pill: Customised, Clean, Partly read or Refused.
- Save. One workbook, one sheet per kind, plus Not read. It goes into Report History only when you save it.
How it works
Each ticked site is read and, with subsites included, every subsite below it, each once. Up to four sites are read at the same time. For each site, in order: custom actions at site and web level and tenant-wide extensions, webhooks on its lists, field and form customizers, app grants, the site's property bag (and list property bags when you ask), site designs applied, classic publishing and branding (publishing features, a custom master page, alternate CSS and add-ins), and finally whether custom script is allowed.
Property bag keys that SharePoint and Microsoft products set themselves are recognised by name and left out, so the sheet shows keys someone added. A key whose name contains secret, password, key or token has its value hidden unless you choose to include it. Webhook client state is written only as present or absent.
Custom script state is read with an administrator's view first. When that is not available, or fails, it is inferred from what your account is allowed to do, and the workbook says which. If neither works, the state is unknown and the site is listed on Not read.
Each site gets one verdict: Refused when every check was refused, Partly read when any check did not finish or the script state is unknown, Customised when anything was found or custom script is allowed, and Clean otherwise. A site that errors is marked failed and the run continues; if your sign-in is lost, no further sites are started. The workbook is written when you save it.
What you get
An Excel workbook, named like Customisation audit 2026-10-07 14-22.xlsx, kept in Report History whether or not you save it.
Summary sheet
One row per site: custom script, counts per kind, will not migrate, not read.
| Column | Example |
|---|---|
| Site URL | https://contoso.sharepoint.com/sites/hr |
| Title | Human Resources |
| Custom script | Blocked (SharePoint admin read) |
| Custom actions | 2 |
| Will not migrate | 3 |
Custom actions sheet
One row per action.
Tenant-wide extensions sheet
Tenant-wide extensions, which apply to every site, listed once each.
Webhooks sheet
One row per subscription; client state as present or absent.
By endpoint host sheet
The webhooks grouped by the host they call.
SPFx customizers sheet
Field and form bindings.
Orphaned components sheet
Customizers bound to a component id that no app catalog ShareMaster could read knows.
App grants sheet
Sites.Selected grants.
Property bag sheet
Custom keys only; system keys are always left out in the audit.
Site designs sheet
Designs applied and how their actions went.
Classic sheet
Publishing features, master pages, alternate CSS, add-ins.
Not read sheet
Everything that could not be read, with the reason.
What you need
- Site owner on each site to read custom actions, subscriptions and property bags.
- The custom script state is read exactly for a SharePoint Administrator; for anyone else it is inferred from your permissions, and the workbook says which.
What it will not do
- A site that could not be read is never reported as clean: it appears on Not read.
- Webhook client state is a shared secret, so only present or absent is written.
- Property values whose key looks like a secret are hidden unless you include them.
- System property bag keys are always left out of the audit; only custom keys are listed.
- SharePoint 2013 workflows and JSLink on fields and views are not covered in this version.
- Feeding these findings into Pre-migration analysis is waiting for that analysis to reach this build.