GOVERNANCE · April 15, 2026 · 12 min read

Your SharePoint modernization inventory: what to fix before the EOL window closes

The next twelve months are the busiest end-of-life window SharePoint has seen in a decade. SharePoint 2013 workflows, the engine behind thousands of long-running approval and document lifecycle processes in the average tenant, were retired in April 2026. InfoPath, which Microsoft stopped developing in 2014 but kept on life support for an embarrassingly long time, retires in December 2026 — at which point it stops rendering full stop. Classic SharePoint pages are on a slower deprecation curve but the direction of travel is the same: modern pages, modern lists, modern columns, or nothing.

The problem most teams face is not “we do not know modernization is coming.” Everyone knows. The problem is scope. You walk into a tenant with 800 sites and the first question is “how many InfoPath forms do we have?” The honest answer is nobody knows, because InfoPath forms live inside form libraries scattered across site collections, some of them published, some of them as saved-as templates, some bound to Access Services that shut down five years ago. You cannot estimate the project until you have the inventory, and you cannot build the inventory by hand.

The Modernization Engine at /governance/modernization is the inventory-first answer. You scan, you get a line-itemised list of every legacy artefact across your tenant, each one scored for modernization effort. Now you can quote the project.

The EOL timeline, in plain calendar form

The dates that actually matter, from Microsoft’s published retirement notices:

• April 2026 (past) — SharePoint 2013 workflows retired in SharePoint Online. Existing workflows may still execute for a grace period but new creation is blocked and Microsoft can disable execution at any time. Any business process still running on the 2013 engine is on borrowed time.
• December 2026 — InfoPath Forms Services shuts off. Forms stop rendering. Form libraries still hold the XML, but users cannot fill out, submit, or view forms in the browser. Desktop InfoPath 2013 client continues to work against local XSN files but cannot publish to SharePoint.
• Ongoing — Classic publishing pages and wiki pages remain supported but are increasingly second-class. New features (Viva integration, Copilot, modern page web parts) do not target them. Ranking and search behave better on modern pages.
• Ongoing — Classic list experience is being phased out in favour of the modern list UI. Classic lookup columns (as opposed to modern indexed lookups) have quirks that break modern view rendering.

“We will deal with InfoPath later” has been a valid answer for eleven years. From December 2026 it becomes the answer that explains why forms do not work.

What the scanner finds

The engine walks your tenant via Graph and SharePoint REST and classifies every artefact into five modernization categories.

1. InfoPath forms

Scan surface: every document library with content type Form, InfoPath Form, or containing files with extension .xsn, .xml (bound to form templates), or a FormTemplates hidden library. The scanner inspects the XSN header to determine whether the form is a list form, a library form, or a free-standing published form, because the conversion target differs.

2. SharePoint 2013 workflows

Scan surface: every list and library has a WorkflowAssociations collection; we enumerate workflow templates across the tenant and flag anything with the 2013 engine. We also read the History list for recent runs — a workflow that has not executed in 18 months is scored lower priority than one that ran yesterday.

3. Classic publishing pages

Scan surface: pages in the Pages library (publishing sites) or SitePages where the PublishingPageLayout field is set. We capture layout, web parts, and custom CSS references because those drive the conversion effort.

4. Wiki pages

Scan surface: pages in SitePages with the wiki layout. Wiki pages convert to modern one-column pages cleanly in most cases but wiki-style inline links ([[Page Name]]) have to be rewritten.

5. Classic lookup columns and calculated fields

Scan surface: every list’s field schema. Classic lookups reference other lists by list ID; if the target list has been deleted, the lookup becomes a zombie column that cannot render in modern views. Calculated columns referencing deprecated functions (TEXT with locale-specific format strings, for example) also surface here.

Effort estimates

Every finding is tagged with one of four effort levels. The numbers are calibrated against measured time on real conversion projects, not guesses:

The engine multiplies per-item effort by item count per site and rolls up totals at the site-collection and tenant levels. A tenant report usually comes back with a single number at the top: “Estimated modernization effort: 142 person-days.” That is the number you put in your quote or plan against.

The conversion target matrix

Each legacy artefact has a recommended modern target. The matrix the engine uses:

How to use it

1. Open /governance/modernization. Authenticate your tenant if you have not already. The engine needs Graph Sites.Read.All and SharePoint Tenant.Read.All; read-only.
2. Pick a scope: full tenant, a list of site collections, or a single site. Full tenant scans on a 400-site tenant typically take 15–25 minutes.
3. Wait for the scan to finish. The UI shows per-module progress (InfoPath, Workflows, Pages, Lookups).
4. Open the report. Top of the page: aggregate counts and aggregate effort. Below that: a per-site breakdown, expandable to per-artefact rows.
5. Sort by effort descending to find the biggest-ticket items first. Sort by last-used ascending to find abandoned artefacts you may be able to decommission rather than convert.
6. Export the full inventory as CSV or Excel. This becomes the project plan and the client-facing estimate.
7. Where appropriate, kick off conversions directly from the report. Wiki-to-modern and classic-lookup-to-indexed-lookup have in-product one-click conversions. InfoPath and workflow conversions are tracked in the Modernization Engine’s task list but implemented by humans.

A worked tenant report

Aggregate numbers from a 420-site engineering firm tenant, actual scan output, client name redacted:

• InfoPath forms: 67 (12 low, 38 medium, 11 high, 6 manual-only) — estimated 143 days
• SP 2013 workflows: 89 (4 low, 44 medium, 22 high, 19 manual-only) — estimated 346 days
• Classic publishing pages: 221 (180 low, 32 medium, 9 high) — estimated 172 days
• Wiki pages: 508 (420 low, 88 medium) — estimated 386 days
• Classic lookup columns: 114 (all low, auto-convertible) — estimated 57 days

Total: 1,104 person-days. That is a three-year program for a two-person team, or a twelve-month program for a team of five. Before the scan, the client’s internal estimate was “maybe six months of work.”

The per-artefact detail turned 23 of the 67 InfoPath forms into decommissioning candidates — they had not been filled out in 24+ months. Applied across the inventory, quick-decommission reductions took about 18% off the total. That is the kind of scoping precision a hand-built inventory never gets to.

Known limits

• InfoPath with Access Services binding. We detect the binding but cannot introspect the backing Access database, which was retired in 2017. These forms need manual analysis.
• Workflows with third-party custom activities. We flag them manual-only but cannot enumerate which third-party packages are involved without reflecting on the workflow XAML.
• Custom branded publishing page layouts. Effort estimate is best-case; unusually heavy design customisation may run long.
• On-prem SharePoint. The engine is SharePoint Online only. On-prem tenants need a different scan tool.

Why it pays to scan now, not in Q3

The InfoPath December 2026 deadline is firm. Every scan we have run since January has found more InfoPath forms than the client expected — the average overshoot is about 3x. If you are scoping modernization work today, you have eight months. If you are scoping it in September, you have three, and the market for qualified InfoPath migration resources starts tightening.

A scan costs nothing to run. The output either confirms your scope or forces a hard conversation with the client early, while there is still runway to handle the answer.

Related reading

• InfoPath to PDF archive: the safe fallback for forms you do not need to rebuild
• SharePoint migration best practices

Get started

Scan your tenant at app.migrationfox.com/register. The Modernization Engine is included on every workspace.