Know what will convert before you export.

Primary input format. The analyzer reads the manifest, XSL views, schema, rules, data connections, and embedded media.

Works when the package contains the same InfoPath files that are normally inside the .xsn.

Analyzes an exported classic or responsive Nintex Forms XML definition, including controls, SharePoint bindings, layout metadata, rules, formulas, and references.

Analyzes ZIP portfolios containing multiple exported Nintex Forms XML definitions and lets the user select a form for SharePoint validation and Power Apps generation.

Best-fit path. Form Migrator targets an existing SharePoint list and generates a Power Apps canvas form package.

Supported for document-library style InfoPath packages when fields and data connections can be mapped to SharePoint targets.

The package can be analyzed, but client-only features often need a manual target design before export.

If the XSN references assets that are not embedded, the analyzer reports the missing references for maker review.

Exports a ready-to-import canvas app package that connects to the configured SharePoint list or library.

Current default. Import into Power Apps Studio, reconnect data sources, validate, then publish.

Exports embedded source media with unique file names and a manifest for handoff or reuse when media is present and supported.

Reports the detected fields, views, rules, data sources, warnings, and manual-review items.

Power Apps list-form replacement still requires a maker to create or customize the SharePoint form shell.

Today Form Migrator downloads package files. Direct deployment is a future workflow.

Generates a main Power Apps screen with the configured app title, layout columns, fields, and save behavior.

Each InfoPath view becomes a screen. Screen names are derived from the original view names.

Preserves source control order, relative coordinates, dimensions, and one- or multi-column placement as a first-pass Power Apps layout.

Uses responsive column-span and section metadata to scaffold a Power Apps layout. Makers should validate spacing and behavior at the target canvas sizes.

Show/Hide sections can be promoted to virtual screens, but complex conditional layouts should be validated in Studio.

Optional. Buttons can be carried over and mapped to first-pass Power Fx actions when the rule intent is clear.

Optional. Embedded images can be added to generated screens and exported separately as media files.

The generator aims for a clean, source-aware Power Apps layout rather than an exact HTML, CSS, or pixel-for-pixel reproduction.

Generated apps use a desktop canvas baseline. Mobile optimization is a maker review task.

Maps to standard Power Apps data cards and uses SharePoint-compatible update formulas.

Static choices and SharePoint-backed dropdowns are generated with separate display and saved values when detected.

Uses required SharePoint targets to connect supporting lists and populate dropdown choices.

Can be flattened to text/email or mapped to person-style data depending on the selected handling mode.

SharePoint attachments can be planned, but migration and UX patterns depend on the target list/library design.

Detected and scaffolded where possible. Formatting fidelity depends on the target Power Apps control strategy.

Usually needs a child-list, gallery, or related-table pattern. The generator can flag the pattern for buildout.

These usually require a custom Power Apps control design and storage strategy.

Maps to Navigate formulas when the destination view or virtual screen is clear.

Simple show/hide patterns are recognized. Complex chained conditions may need formula cleanup.

First-pass formula scaffolds are generated for straightforward assignments.

Uses SharePoint column metadata and field mapping settings to preserve required behavior where possible.

Standard submit/save behavior is scaffolded. Multi-submit or conditional submit paths need validation.

Simple formulas can be scaffolded. XPath-heavy InfoPath logic or complex Nintex formula chains require maker review.

InfoPath code-behind and Nintex custom JavaScript are reported as risk items and must be rebuilt in Power Fx, Power Automate, or another service.

Form Migrator focuses on the form layer. Workflow modernization belongs in Power Automate or a separate build path.

Connect Microsoft 365, load the destination site, select the primary target, and import real column metadata.

Required SharePoint targets can be auto-matched from the destination site and used by dropdowns and lookups.

Uses a connected Microsoft 365 account to read SharePoint site/list metadata for mapping and export.

Recognized when user/profile data is part of the original design; formulas may need environment-specific review.

Endpoint and authentication patterns vary. The analyzer can report them, but the maker should rebuild the connector path.

Requires target-connector decisions, gateway planning, and data model validation.

Legacy service calls generally need a custom connector, Power Automate flow, or replacement API strategy.

Typically replaced with Power Automate or a connector-driven process after the form is generated.