What makes form libraries different
Submitted XML
Historical forms may live as XML documents, while the future Power Apps pattern may prefer list items or Dataverse rows.
Promoted columns
Fields shown in SharePoint views may be promoted from the InfoPath XML, not native list columns in the same way as a list form.
Template-bound behavior
The library template can control views, rules, submit actions, and default values that need separate replacement decisions.
Migration planning steps
Analyze the template
Use the .xsn to identify fields, views, media, secondary data sources, and submit logic.
Decide the future data model
Choose whether to keep a library pattern, move to a list-backed app, or create a custom relational model.
Recreate supporting artifacts
Create needed supporting lists, libraries, choice lists, people lists, and status lists in the destination site.
Validate historical access
Plan separately for reading old submitted XML if users still need historical forms after the replacement goes live.
What Form Migrator exports
For supported patterns, Form Migrator can generate a Power Apps package over the configured primary target and supporting SharePoint lists. For more complex libraries, the blueprint and compatibility report become the builder handoff.
Common questions
Does the .msapp migrate historical XML data?
No. The .msapp is an app package. Historical data migration should be planned separately based on where the old form instances live and how they need to be accessed.
Can Form Migrator identify promoted fields?
It can infer fields and mappings from the InfoPath package and SharePoint settings, but you should validate promoted fields against the real destination column inventory.
Should I keep the same library name?
Keeping names similar can simplify mapping, but production design should prioritize the future data model and user experience.