BLOG B SERIES — PART 2 OF 3
Part 1: Why Power Apps Is the Right InfoPath Replacement for Your Organization
Part 2 (this post): How to Migrate InfoPath Forms to Power Apps — The Technical Breakdown
Part 3: Building Your InfoPath to Power Apps Migration Plan — Timeline, Cost, and Checklist
From InfoPath to Power Apps — What the Technical Migration Actually Involves
Part 1 of this series covered why Power Apps is Microsoft’s recommended replacement for InfoPath and what it does better. This post goes deeper — into the technical steps, the feature-by-feature translation, and the data migration work that IT teams and developers need to understand before they start building.
The most important thing to internalize upfront: migrating from InfoPath to Power Apps is a rebuild, not a conversion. Microsoft has confirmed there is no automated migration tool. Every form must be manually reconstructed in Power Apps — which means your development team needs to understand how each InfoPath feature maps to its Power Apps equivalent, and where the mapping requires architectural redesign rather than direct replacement.
This post is your technical reference for that mapping work.
Need expert Power Apps developers for your InfoPath migration?
WME delivers fixed-scope InfoPath to Power Apps migrations with SOC 2 certified security.
Phase 1: Analyze Your InfoPath Forms Before Writing a Single Line of Power Fx
Before any Power Apps development begins, each form in your rebuild queue needs a structured technical analysis. Skipping this step is the primary cause of mid-project scope explosions. For each form, document:
- Form type — SharePoint List form, Library form, or standalone browser form
- Data sources — SharePoint lists, SOAP/REST endpoints, SQL connections, UDCX files
- Promoted vs. unpromoted fields — only promoted fields are visible as SharePoint columns; unpromoted fields live only in the XML blob and require separate extraction
- Repeating sections — identify every repeating table or section; each one requires a Dataverse child table or SharePoint child list in the new architecture
- Business rules — conditional show/hide, calculated fields, validation rules, default values
- People Picker fields — flag all; require identity re-mapping from Windows claims to Azure AD post-migration
- Embedded attachments — InfoPath embeds attachments in the XML blob (5 MB cap); these must be extracted to SharePoint document storage
- Linked SharePoint Designer workflows — document every workflow triggered by the form; these must be rebuilt in Power Automate
CRITICAL PRE-MIGRATION STEP — DO NOT SKIP
Before any migration tool runs or any Power Apps development begins, bulk-export all .xml form submissions from the SharePoint Form Library via PowerShell (Get-PnPFile) and extract all workflow history.
SPMT drops workflow history permanently. InfoPath Client 2013 loses vendor support on July 14, 2026. The window to extract historical compliance data closes with the deadline — not after it.
Phase 2: The Complete InfoPath to Power Apps Feature Mapping
Use this reference table when planning each form rebuild. It covers every major InfoPath feature and its direct Power Apps equivalent — including where the mapping is straightforward and where it requires re-architecture.
InfoPath Feature | Power Apps Equivalent and Notes |
WYSIWYG form designer | Power Apps Studio — browser-based canvas designer with drag-and-drop controls and live device preview. No desktop install required. |
Text, date, number, boolean fields | Power Apps Text Input, Date Picker, Slider/Rating, Toggle controls. XSD type mapping must be reviewed field-by-field — not all types map 1:1. |
Dropdown / choice fields | Power Apps Dropdown or ComboBox controls connected to SharePoint choice columns, Dataverse option sets, or static collections. |
People Picker fields | Power Apps People Picker control with Azure AD connector. Requires identity re-mapping — Windows claims from on-premises InfoPath do not match M365 Azure AD identity. |
Calculated field rules | Power Fx formulas on the Default or Text property of a control. Evaluated in real time — more powerful than InfoPath’s rule-based calculation model. |
Default value rules | Power Fx Default property on controls. Supports dynamic defaults driven by user context, SharePoint profile data, or related list values. |
Repeating sections / tables | Power Apps Gallery control connected to a Dataverse child table or SharePoint child list. Requires re-architecting the data model — not a direct control swap. |
Attachment control (XML-embedded) | Power Apps Attachments control writing to SharePoint document libraries or Dataverse file columns. Removes the 5 MB XML embedding limitation. |
Data connections (SharePoint lists) | Power Apps SharePoint connector — standard, included in all M365 plans. Direct equivalent. |
Data connections (SOAP/UDCX endpoints) | Power Apps HTTP connector or custom connector. SOAP calls must be updated to supported REST endpoints where SOAP is not directly supported. |
Data connections (SQL Server, Salesforce, SAP) | Power Apps premium connectors. Requires Power Apps Premium license ($20/user/month) — standard M365 entitlement does not cover premium connectors. |
Print view | Power Apps with Power Automate PDF generation flow, or an HTML template rendered for printing. InfoPath’s print view has no direct built-in equivalent in canvas apps. |
Form versioning | SharePoint document library versioning for the app package, plus Dataverse or SharePoint list versioning for submitted data. Managed separately from the app itself. |
Phase 3: Rebuilding InfoPath Workflows in Power Automate
Every InfoPath form that had an associated SharePoint Designer workflow requires a parallel Power Automate rebuild. This is not optional — SharePoint Designer workflows are also deprecated and will not survive the migration to modern SharePoint Online.
Mapping InfoPath + SharePoint Designer Workflow Patterns to Power Automate
InfoPath + SharePoint Designer Pattern | Power Automate Equivalent |
List item creation triggers a workflow on form submission | Power Automate — When an item is created trigger on the SharePoint list. Direct equivalent. |
Multi-step approval routing with assigned approvers | Power Automate approval action with sequential or parallel approval patterns. Start an approval → wait for response → branch on outcome. |
Email notifications to form submitter or approver | Power Automate Send an email (V2) action or Post a message in Teams action. More flexible than InfoPath’s email rules. |
Conditional workflow branching based on field values | Power Automate condition actions with Power Fx-style expressions. Direct equivalent with more readable syntax. |
Status field updates based on workflow stage | Power Automate Update item action targeting the status column after each approval stage. Direct equivalent. |
Escalation rules based on elapsed time | Power Automate delay or delay until actions combined with parallel branch timeout logic. More flexible than InfoPath/SharePoint Designer timers. |
Workflow history logging | Power Automate run history in the Power Automate portal. Note: SPMT does not migrate legacy SharePoint Designer workflow history — extract before migration. |
WORKFLOW HISTORY — LAST WARNING
SPMT migrates workflow definitions to Power Automate but permanently drops all historical workflow data and in-progress workflow state.
For HIPAA, SOX 404, and ISO 27001 compliance, historical approval records are audit evidence. Extract every workflow history list before running SPMT — this cannot be recovered after migration.
Phase 4: Data Migration — Moving Historical XML Submissions
The form UI rebuild is only half the migration. The historical data stored as .xml submissions in your SharePoint Form Libraries must also be migrated and preserved — both for operational access and compliance lookback requirements.
Step-by-Step Data Extraction Pattern
- Export the .xsn template — extract the embedded manifest.xsd to document the original form schema. This is your mapping reference for all field names and data types.
- Bulk-download all .xml submissions from the SharePoint Form Library using PowerShell Get-PnPFile or CSOM/WebDAV. Do this before any library modifications.
- Parse the XML programmatically — use PowerShell, Python, or a dedicated ETL tool to extract field values from each .xml file into structured records.
- Handle repeating sections — flatten nested XML nodes into separate child records. Each repeating section maps to a child table in Dataverse or a child list in SharePoint.
- Extract embedded attachments — attachments embedded in the XML blob (5 MB cap) must be extracted to SharePoint document libraries or Dataverse file storage before the XML archive is retired.
- Load into the new data store — insert the extracted, structured records into your Dataverse tables or SharePoint Lists alongside new Power Apps submissions.
- Generate PDF/A archives — for compliance lookback, render each historical .xml submission as a PDF/A using a tool like Nutrient and store in a compliant document library.
- Store .xsn and .xml originals — retain the original files in an access-controlled archive library for the compliance retention period required by your regulatory framework.
DATAVERSE VS. SHAREPOINT LISTS FOR MIGRATED DATA
Use Dataverse when your extracted data has one-to-many relationships (repeating sections), requires row-level security, or will be used in model-driven Power Apps or Power BI reporting at scale.
Use SharePoint Lists when the data is flat, the form is low-complexity, and your licensing model does not include Power Apps Premium.
The data architecture decision made at this phase determines the complexity of your Power Apps rebuild — it is worth getting right before development starts.
Phase 5: Testing Your Power Apps Migration
Every rebuilt form requires structured testing before cutover. Use this testing framework to validate that the Power Apps replacement is functionally equivalent to the original InfoPath form:
Test Type | What to Validate |
Logic parity testing | Run every conditional show/hide rule, calculated field, and validation rule through the same test inputs used in the InfoPath form. Confirm identical outputs. |
Data submission testing | Submit test records and verify that all field values — including previously unpromoted fields — are correctly stored in the new Dataverse or SharePoint List data store. |
Workflow testing | Trigger every Power Automate flow from a form submission and trace the full workflow path — approvals, notifications, status updates, and escalations. |
Identity testing | Confirm People Picker fields resolve correctly to Azure AD identities for all user types — internal staff, guests, and service accounts. |
Attachment testing | Verify that attachments submit correctly to SharePoint document libraries and that historical PDF/A archives are accessible and readable. |
Mobile and browser testing | Test the rebuilt form on phone, tablet, and desktop browsers. Validate layout, control behavior, and submission functionality across all target devices. |
Parallel run validation | Where the deadline allows, run the Power Apps form alongside the InfoPath form for a defined period and compare output records. Confirm data parity before InfoPath cutover. |
What Comes Next
Now that you have the full technical picture — feature mapping, workflow rebuilding, data migration, and testing — Part 3 of this series covers the planning side: how to structure your migration project, what realistic timelines and costs look like, and a checklist to guide your team from assessment through go-live.
BLOG B SERIES NAVIGATION
Part 1 (this post): Why Power Apps Is the Right InfoPath Replacement for Your Organization
Part 2: How to Migrate InfoPath Forms to Power Apps — The Technical Breakdown
Part 3: Building Your InfoPath to Power Apps Migration Plan — Timeline, Cost, and Checklist
Also read: The full InfoPath EOL series (Blog A) at winmgmtexperts.com/blog
