InfoPath end of life in 2026: your migration options

Microsoft has confirmed InfoPath's retirement date. After more than a decade of "definitely deprecated, but still works" purgatory, the InfoPath Forms Service on SharePoint Online is being switched off, and InfoPath Filler stops receiving security updates not long after.

If your organisation still has live InfoPath forms (and based on every audit we've run in the last 18 months, you probably do), you need a real migration plan. This post lays out the realistic options and how to choose.

What "end of life" actually means in practice

• InfoPath Forms Service on SharePoint Online: stops rendering forms in the browser. Existing form definitions remain in document libraries but cannot be filled out via the web.
• InfoPath Filler client app: continues to open existing .xsn files locally, but receives no security or compatibility updates. Read-only is fine for archives; production filling becomes a risk.
• What does NOT change: the underlying SharePoint lists. Your data is safe. You're losing the front end, not the storage.

The four replacement paths

1. SharePoint Forms365

The product this site is about, a direct InfoPath replacement that:

• Renders directly on the same SharePoint list, replacing the default form
• Imports the InfoPath XSN (best-effort schema extraction)
• Supports the same conditional logic patterns (visibility, validation, audience)
• Has a JavaScript runtime API for the cases where InfoPath authors used VBA / managed code

Pick this when: your InfoPath forms are tied to SharePoint lists (most of them), the team that owned them was business-side not dev-side, and you don't want to re-platform onto a fundamentally different stack.

2. Microsoft Power Apps

Microsoft's official heir, but a very different shape:

• A whole new authoring tool and runtime
• Lives separately from SharePoint list forms (Power App per list, not a form per list)
• Licensing complexity (depending on tenant tier and per-user vs per-app)
• Steeper learning curve for ex-InfoPath authors

Pick this when: you're already on a Power Platform-heavy roadmap, you have Power Apps capacity already procured, and the forms are part of broader Dataverse-based workflows.

3. Nintex Forms

The InfoPath-replacement-of-choice circa 2018, now in long-tail mode:

• Mature, fully-featured
• Pricing tilted enterprise-up
• Modernisation has been steady but the UX shows its age

Pick this when: you already have Nintex on the books and adding more isn't a procurement battle. Don't pick this if you're starting fresh, the licence cost is hard to justify against the alternatives.

4. Custom SPFx

Hand-rolled SharePoint Framework web parts replacing InfoPath one form at a time:

• Maximum flexibility, full developer control
• Highest ongoing cost, every form needs a dev
• No vendor lock-in, no per-form licensing

Pick this when: you have an internal SPFx team already shipping, you're building ~3 forms a year (the per-form cost dominates), and the forms have requirements no off-the-shelf tool covers.

A decision tree

Question	If yes →
Do you have ≥10 forms to migrate?	Pick a product (SharePoint Forms365, Power Apps, Nintex). Custom dev doesn't scale.
Are most forms tied to SharePoint lists?	Lean SharePoint Forms365 or custom SPFx.
Is Power Platform already in your roadmap?	Power Apps is the safe bet for executive alignment.
Are licence costs the gate?	SharePoint Forms365 (lower per-seat) wins.
Need it shipped in under 90 days?	SharePoint Forms365 or Power Apps. Nintex onboarding is slower; custom dev is slower still.

What to start now

Regardless of which path you choose:

1. Inventory every active InfoPath form. Use the SharePoint admin centre's solution scanner or run a script across your tenant's libraries.
2. Triage by usage. Many "active" InfoPath forms are filled twice a year. They can be retired, not replaced.
3. Identify the highest-impact 5 forms. Whatever path you choose, prove the migration on these first before committing the whole portfolio.
4. Set a hard deadline. The end-of-life date is fixed; if your migration plan extends past it, you're rendering forms in a deprecated runtime.

We've built migration into SharePoint Forms365 specifically because we live this problem with our customers every week. Get in touch if you'd like to walk through your inventory.