Inheriting InfoPath Forms: What to Do About Them

If you have inherited a SharePoint environment with InfoPath forms in it, the immediate question is not how to add another feature to them. It is what to do about them.

InfoPath is retired. Microsoft ended new development on it long ago, and the client and Forms Services have been on a wind-down path since. The forms still open in many environments, which is precisely what makes them dangerous — they keep working until the day they do not, and by then whoever built them has usually left.

This covers what those forms typically do, how to work out what a given form depends on, and what replaces it.

What the forms usually do

The overwhelmingly common InfoPath pattern is auto-population: a user picks a name, and the form fills in their department, manager, email and office. It looked like magic in 2010 and it is the reason many of these forms still exist.

Underneath, it is almost always one of two mechanisms:

• A data connection to the SharePoint user information list, queried when a field changes, with rules copying returned values into other fields.
• A connection to a user profile web service, which returns a richer profile and requires more plumbing.

Both are external dependencies expressed inside a form template, which is why they break in ways that are hard to diagnose: the form opens, the lookup silently returns nothing, and fields stay blank.

Working out what a form actually depends on

Before replacing anything, find out what it does. An .xsn file is a cabinet archive, and its contents are readable without InfoPath installed.

1. Copy the .xsn and rename the copy to .cab
2. Extract it
3. Open manifest.xsf — data connections, rules and submit behaviour are all declared there
4. Open the .xsd files for the data structure

What to look for, in order of how often it causes trouble:

• Data connection URLs. Hard-coded server names are extremely common, and they are why a form works in production and fails in a restored test environment.
• Web service references. Especially anything under _vti_bin, which is legacy surface.
• Submit targets. Where the data actually goes, which is not always the obvious list.
• Code-behind. A managed-code form is a much larger migration than a rules-only one.

Do this on a copy. Working directly on the deployed template is how a form that was merely obsolete becomes a form that is broken.

What replaces it

What the form does	Replacement
Simple data entry into a list	The modern SharePoint list form, with conditional formatting
Auto-populated user details	Power Apps, using Office365Users
Multi-step approval	Power Automate approvals
Complex validation and branching	Power Apps
Relational structure across entities	Dataverse with a model-driven app
Printable, precisely laid out documents	Power Automate with a document template

The auto-population case — the most common one — becomes straightforward. In a Power App, the signed-in user's details need no lookup at all:

// Details of whoever is using the app
User().FullName
User().Email

// Richer profile fields for the current user
Office365Users.MyProfileV2().department
Office365Users.MyProfileV2().jobTitle

// Someone else, chosen in a people picker
With(
    { profile: Office365Users.UserProfileV2(PeoplePicker.Selected.Email) },
    {
        Department: profile.department,
        Manager:    Office365Users.ManagerV2(PeoplePicker.Selected.Email).displayName
    }
)

Two points worth knowing. Wrapping the lookup in With() means one call rather than one per field, which matters when a form reads five profile properties. And these calls run as the signed-in user, so they return what that user is permitted to see — a meaningful improvement over a form-level connection running with fixed credentials.

Migrating without a big-bang cutover

The approach that works: inventory first, then migrate by value, keeping the old form available until the new one is proven.

1. Find every form. Look for .xsn files in form libraries and for lists whose settings point at a custom form.
2. Find out which are used. Many are not. Submission dates answer this faster than asking around.
3. Order by consequence. A form feeding a compliance process matters more than one somebody built for a project that ended.
4. Rebuild the process, not the layout. Reproducing an InfoPath form pixel for pixel in Power Apps carries forward every compromise the old technology forced. Ask what the process needs.
5. Run both briefly. Keep the old form readable while the new one takes new submissions.
6. Retire deliberately. Remove the old template once nothing depends on it, and keep the historical data.

Existing data matters more than the form. Submitted InfoPath forms are XML files in a library. Whatever replaces the form, that history needs a plan — extraction into a list, retention in place, or archival. Losing it is a far bigger problem than losing a form template.

Common mistakes and better practice

• Adding features to InfoPath forms. Every hour invested makes the eventual migration larger.
• Rebuilding the layout instead of the process. InfoPath's constraints do not apply to the replacement.
• Forgetting the submitted data. The XML history usually outlives the form's usefulness.
• Migrating without an inventory. Forms hide in libraries nobody looks at.
• Calling the profile service per field. Wrap it in With() and read from the result.
• Assuming the form still works because it opens. A broken data connection is silent — fields simply stay blank.
• Working on the deployed template. Extract a copy.

Troubleshooting inherited forms

Symptom	Likely cause	What to check
Form opens, lookup fields stay blank	Data connection failing silently	Extract the .xsn; check connection URLs in manifest.xsf
Works in production, fails in test	Hard-coded server name in a connection	Same file; the URL will name the production host
Submit succeeds but data does not appear	Submit target is not the list you expect	Submit configuration in manifest.xsf
Form will not open at all	Forms Services unavailable, or template not deployed	Confirm the feature state and template deployment
Only some users see populated fields	Connection running under credentials with partial access	Check what the connection authenticates as

Frequently asked questions

Is InfoPath still supported?

It is retired and should not be used for new work. Support dates differ between the client and Forms Services and between SharePoint versions, so confirm against the lifecycle documentation for your exact environment.

Can an InfoPath form be converted automatically?

No. There is no supported conversion to Power Apps. The process is rebuilt, which is usually an improvement — most forms carry compromises InfoPath imposed rather than requirements the business had.

What happens to already-submitted forms?

They remain as XML files in the library. They need their own plan: extract, retain or archive.

Is Power Apps always the right replacement?

No. A simple list form with conditional formatting is often enough and needs no premium licensing. Reach for Power Apps when logic or layout genuinely require it.

How do I get a user's manager in Power Apps?

Office365Users.ManagerV2() with the user's email. It runs as the signed-in user, so results reflect their permissions.

Where to start

If you have inherited InfoPath forms, the useful first move is not a migration plan. It is an inventory: which forms exist, which are still submitted to, and what each one depends on.

Most environments discover that a small number of forms carry real processes and the rest are abandoned. Knowing which is which turns an intimidating migration into a short list.