GOVERNANCE · April 15, 2026 · Updated November 6, 2026 · 7 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 many long-running approval and document lifecycle processes, were retired in April 2026. InfoPath, which Microsoft stopped developing in 2014 but kept on life support for an embarrassingly long time, was retired on July 14, 2026, and stopped 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. Each scan covers one site and returns a line-itemized list of the legacy artifacts it finds there, each one scored for modernization effort. Scan the sites in scope, add up the results, and 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.
• July 14, 2026 (past): InfoPath Forms Services shut off. Forms no longer render. Form libraries still hold the XML, but users cannot fill out, submit, or view forms in the browser. The InfoPath 2013 desktop client reached the end of its support on the same date. For the historic submissions you do not plan to rebuild, an InfoPath PDF archive turns each one into a searchable PDF and recovers its attached files.
• 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 favor 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” was a valid answer for eleven years. Since July 14, 2026 it is the answer that explains why forms do not work.

What the scanner finds

The engine reads one site through Microsoft Graph (and, for workflows, the SharePoint REST API) and sorts what it finds into five categories.

1. InfoPath forms

The scanner looks for three signals: a list holding .xml form submissions, a library containing .xsn or .xsf form template files, and .xsn templates in the site’s FormServerTemplates folder. It finds these files by name; it does not open the template to read fields, rules, or data connections, so per-form complexity still needs a human look.

2. SharePoint 2013 workflows

The scanner reads the site’s workflow subscriptions through the SharePoint REST API and lists each 2013 workflow it finds. It does not read workflow history, so it cannot tell you when a workflow last ran. SharePoint rejects REST calls from an app registration that signs in with a client secret, so this part of the scan needs a “Sign in with Microsoft” connection. On an app-registration connection, workflows are skipped and the report says so in its scan gaps.

3. Classic publishing pages

Pages returned by the site’s pages API that are not modern site pages and are not wiki pages. Publishing-specific web parts (Content Search, Summary Links, Content Query) have no direct modern equivalent, which is why these score high.

4. Wiki pages

Wiki pages in the site’s pages library. They convert to modern pages by recreating the layout with Text and Quick Links web parts, but wiki-style inline links ([[Page Name]]) have to be rewritten by hand.

5. Classic lookup columns

User-created lookup columns in the site’s lists; built-in system lookups are filtered out. A lookup references its target list by ID, so on a cross-tenant move the target list ID changes and the lookup breaks unless it is rebuilt. Calculated columns are not scanned.

Effort estimates

Every finding is tagged with an effort level, and each level carries a fixed planning rate in person-days. These are planning defaults to start a conversation, not measurements of your content:

The report adds the per-item rates into one estimate for the site: “Estimated effort: 38 person-days”, for example. Adjust it once you have looked at the high-effort items yourself; a simple InfoPath form takes far less than five days, and one with code-behind or secondary data connections can take more.

The conversion target matrix

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

How to use it

1. Open /governance/modernization and pick a SharePoint connection. A “Sign in with Microsoft” connection covers everything, including workflows. An app registration needs Sites.Read.All and covers everything except workflows. The scan is read-only.
2. Enter the site to scan. Each scan covers one site; run it site by site, starting with the sites you suspect hold the most legacy content.
3. Open the report: counts by type and effort level, the estimated person-days for the site, any scan gaps, and the per-artifact rows with a conversion note for each.
4. Download the report as JSON. Combined across the sites in scope, it becomes the source for the project plan and the client-facing estimate.
5. Where appropriate, use the Convert action on an artifact to generate a starting point for its conversion. Treat the output as a draft: InfoPath and workflow rebuilds in particular still need a person to review the logic before anything goes live.

Known limits

• One site per scan. There is no tenant-wide rollup; combine the per-site reports yourself.
• Workflows need a sign-in connection. On an app-registration connection, the workflow check is skipped and listed as a scan gap.
• No usage data. The scanner does not read workflow history or form submission dates, so it cannot tell you which artifacts are abandoned.
• InfoPath internals are not inspected. Fields, rules, data connections, and code-behind are not read from the template.
• Calculated columns, SharePoint 2010 workflows, and SharePoint Designer workflows are not scanned.
• Large sites are sampled. The scan reads up to 200 pages and a capped number of lists per site, and the first 50 items in each list when looking for InfoPath files.
• On-premises SharePoint. The engine is SharePoint Online only.

Why it pays to scan now

InfoPath is retired, but the form libraries are still there. The forms no longer render, so the job now is to find every library, decide what gets rebuilt, and turn the historic XML into readable records. Even simple PDF-archive paths take days to plan, run, and verify, so start with the inventory.

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
• InfoPath vs Power Apps: what each path costs
• SharePoint migration best practices

Get started

The Modernization Engine comes with the Tenant Suite or Consultant Pro; a single report pack does not include it. Prices are on the pricing page. Create an account at app.migrationfox.com/register.