This page is for teams that still have InfoPath forms in production. The dates are the easy part. The hard part is that there is no conversion tool, so every form is a decision.
What is being retired
The client. InfoPath 2013 was the last release of the desktop client, and it reached end of support on 14 July 2026.
The server side. InfoPath Forms Services 2013 was the last release of the forms service. Its fate differs by platform, and this is the distinction that decides whether you have a deadline or a debt.
| Where the forms live | State |
|---|---|
| SharePoint Server Subscription Edition | InfoPath Forms Services is removed and no longer supported |
| SharePoint Server 2019 | Deprecated but supported for the release, with the 2013 client supported to the end of its own lifecycle |
| SharePoint Server 2016 | Forms Services support matched the SharePoint Server 2016 lifecycle, which also ended on 14 July 2026 |
What stops working
On Subscription Edition, browser rendered InfoPath forms do not work, because the service is not there. That is a migration prerequisite rather than a post migration problem: upgrading a farm to Subscription Edition with InfoPath forms still in use means those forms need a destination before the upgrade, not after it.
Everywhere else, the honest answer is that nothing breaks on a date. The client still installs, the forms still open, and the debt keeps compounding: no fixes, no security updates, and a dependency that blocks the next platform move.
What is not affected
- The data. InfoPath forms store their data in SharePoint lists and libraries. Retiring the form technology does not retire the content behind it.
- Power Apps, Microsoft Forms and SPFx, which are where this work goes and are all current.
What migration path exists
There is no automated conversion from InfoPath to anything. Microsoft's guidance is to rebuild, and the choice depends on what each form actually does.
| What the form does | Build it as |
|---|---|
| Customises the add or edit experience of a SharePoint list | A Power Apps customised list form, from the Customize button on the list |
| Collects a short response, often from outside the immediate team | Microsoft Forms |
| Carries substantial logic, external calls or code behind | An SPFx web part or extension, with the logic moved to code and, where needed, an external service |
| Triggered a process on submission | A Power Automate flow, separated from the form itself |
Two practical notes from Microsoft's own guidance. Forms driven by extensive code behind are the ones that become SPFx or an external application, and they need developer resources rather than a maker. Forms whose code behind turns out to do nothing, which is common in old estates, can often be retired outright rather than rebuilt.
The sequencing that works: inventory the forms, separate the ones that are genuinely in use from the ones that merely still exist, then classify the survivors against the table above. Most estates find that the count of forms worth rebuilding is far smaller than the count of forms present.
What M365 Governance as Code can observe
- It does not detect InfoPath forms.
- It does not inventory SharePoint Designer solutions.
- It can identify modernisation signals elsewhere in the tenant, such as classic publishing infrastructure or custom master pages, but not these technologies directly.
If you need a form inventory, this is not the instrument that produces it.
Primary Microsoft sources
- InfoPath 2013 lifecycle
- Migrate InfoPath forms to SharePoint
- Fix InfoPath forms in sandbox solutions
- What's deprecated or removed from SharePoint Server 2019
Where this fits
The full picture of what ended and what to build on is in our guide to the state of SharePoint in 2026.