There is a common misconception among organizations, service providers, and even some within Microsoft itself that InfoPath will continue to work past July 14th, 2026 and will simply not be supported. While that statement is technically true for on-prem SharePoint instances, it will obviously not be the case for SharePoint Online-deployed InfoPath forms. They will stop working, period!

Translation, you run out of lifelines and phone-a-friends when the clock strikes (ummm, we're not sure...let's just go with Midnight in Redmond) on July 14th 2026.

Given that updates (service packs, security updates, etc) to those SharePoint versions won't include (or even consider) InfoPath Forms Services, one should assume that updates applied to on-prem instances after July 14th, 2026 could remove or cause InfoPath Form Services to stop working.

Many organizations have been surprised to learn that new form development still happens to this day.

As mentioned earlier, both Microsoft and Kudzu provide tools that will help you figure this out. Both tools give you information about how many times a form has been filled out and when it was last filled out, which will help prioritize recent and frequently filled out forms.

Complexity is obviously important when determining duration, effort, and cost.

Portability will aid in decisionmaking around destination platform(s) of choice.

Kudzu's FORMulator calculates both for you.

While there is not a specific number of fields that will exceed SharePoint list item or Dataverse table row thresholds, forms in the 300-400+ fields range will likely require refactoring.

SharePoint lists are limited to 12 lookup columns, so a form with more than 12 SharePoint list lookups can't be converted to use SharePoint lists without refactoring.

Large amounts of code-behind in a form may not translate well to declarative rules or scripting in a modern low or no code platfom.

When it comes to automated form conversion offerings like Kudzu, code-behind gets left behind.

How you answer this question will factor heavily in the destination platform(s) you choose, as many modern low and no code platforms do not provide native support for this type of user experience.

In some cases repeaters can be synthesized using other form elements and scripting, but oftentimes this results in forms that will be difficult to maintain.

An InfoPath replacement effort can be quite a bit easier if all/most of your forms are published to SharePoint lists. The problem comes in when they're published to Form libraries because those XML documents that hold all the form data will be difficult, if not impossible, to consume in the destination low or no code platform.

To paraphrase the blog post, these are a class of over-engineered forms that usually incorporate a good amount of state management (rudimentary workflow) and/or have 100's of fields or a dozen+ views. They often employ questionable color choices that would make a professional user experience engineer weep and/or cause an accessibility engineer to enter into a profanity-laced tirade.

These forms are technical and design debt traps. There should be no effort made to re-create them, as-is, in a new platform. Preserve the schema and data, but leverage a modern low or no code platform to build a new app (user experience with automation where it makes sense).

This may be your best option if you have a small number of forms and the resource bandwidth to get it done in time.

This may be your only option if most/all of your forms are very complex and in need of a refactor/rebuild.

Even with a small number of forms and/or mostly complex ones, converting the data will likely be a heavy lift if you don't leverage a tool like Kudzu.

Repeaters use destination platform-native capability or Kudzu synthesizes repeaters using other form elements and scripting.

Views can be re-created as views, screens, or pages in most modern low and no code platforms supported by Kudzu.

Most InfoPath rules are converted to their declarative counterparts or script (e.g., Power Fx Named Formulas and Behaviors).

This option includes conversion and migration of data from Form Libraries to SharePoint lists or Dataverse tables.

Preserve the form's schema and input context while re-flowing it into a modern, responsive layout with new fields and list choices suggested by Kudzu.

Once reimagined, the form can be converted to any destination low or no code platform Kudzu supports.