InfoPath & SharePoint Workflows Ending 2026: Migration Guide

Microsoft is shutting down InfoPath Forms Services and legacy SharePoint workflows across both SharePoint Online and on-premises environments in 2026. There is no extension, no grace period for SharePoint Online, and no automated migration tool for InfoPath forms. If your organization runs approval workflows, internal request forms, or document routing built on InfoPath or SharePoint Designer, you need a concrete migration plan — not next quarter, now.

For over a decade, InfoPath and SharePoint Designer workflows were the backbone of enterprise data entry, approval routing, and internal automation. These tools relied on XML-based document generation and highly specific state-machine logic, so there is no simple "upgrade" button. Migrating requires a fundamental architectural shift — from document-based XML storage to modern relational databases (Dataverse or modern SharePoint Lists) and from state-machine workflows to trigger-based automation (Power Automate).

This guide covers the exact deadlines, what breaks at each cutoff, the real limitations of Microsoft's migration tooling, and a practical technical path for moving to Power Apps and Power Automate without losing historical data.

For a broader view of all Microsoft product retirements hitting in 2026, see our Microsoft 2026 End-of-Support Timeline.

The 2026 Deadlines: What Breaks in SharePoint and When

Three separate retirement timelines converge in 2026. Missing any of them means broken business processes with no fallback.

SharePoint 2013 Workflows — April 2, 2026 (SharePoint Online)

SharePoint 2013 workflows will be fully removed from all existing Microsoft 365 tenants on April 2, 2026. This includes Government Clouds (GCC, GCC High) and Department of Defense environments. New tenants already lost access on April 2, 2024. (support.microsoft.com)

After this date:

• All running SharePoint 2013 workflows stop executing — approvals, routing, notifications, everything
• Workflow definitions become viewable only as raw XML files
• SharePoint Designer 2013 can no longer create or execute workflows against SharePoint Online
• Third-party engines that depend on the SharePoint 2013 workflow platform (including some Nintex configurations) also break

This deadline overlaps with the SharePoint Add-ins retirement, which hits the same day. If you're running both legacy add-ins and 2013 workflows, April 2 is a double-impact event.

InfoPath Forms Services — May 18 & July 14, 2026 (SharePoint Online)

InfoPath Forms Services will be fully retired from SharePoint Online on July 14, 2026. The disruption starts earlier: publishing new or updated InfoPath forms will be blocked across all tenants after May 18, 2026. (mc.merill.net)

After July 14, 2026:

• InfoPath forms will no longer open, submit, or render in SharePoint Online lists, libraries, or content types
• InfoPath configuration options will be removed from the SharePoint Admin Center
• End users can still download .xsn templates and .xml form data from SharePoint libraries and open them locally using InfoPath Client 2013 — but only if they have file permissions and a machine with the legacy client installed
• The underlying .xml data remains in the document library, but the UI to read or edit it is gone

On-Premises: SharePoint Server 2016, 2019, and SPSE — July 14, 2026

For on-premises environments, the picture is slightly different but converges on the same date:

• SharePoint Server 2016 extended support ends July 14, 2026. All SharePoint 2010 and 2013 workflows, plus InfoPath Forms Services, lose support on that date.
• SharePoint Server 2019 extended support also ends July 14, 2026, with the same impact.
• SharePoint Server Subscription Edition (SPSE) will support SharePoint 2010 workflows only until July 14, 2026. SharePoint 2013 workflows on SPSE remain supported beyond that date when using SharePoint Workflow Manager — a notable exception. InfoPath Forms Services support on SPSE also ends July 14, 2026. (support.microsoft.com)

Because SharePoint Server 2016 and 2019 themselves hit end of support on July 14, 2026, the entire farm becomes the problem — not just the workflow engine.

What InfoPath and SharePoint Workflows Were Actually Used For

If you inherited a SharePoint environment, you may not fully grasp how deeply these tools are embedded. InfoPath and SharePoint Designer workflows were the standard internal automation stack for over a decade.

InfoPath was a WYSIWYG form designer that stored data as XML documents. Microsoft describes InfoPath Forms Services as a way to deploy forms to SharePoint so users can fill them out in a browser, commonly for collecting information, connecting to different data sources, and automating workflow. (techcommunity.microsoft.com) Organizations used it for:

• Expense reports and purchase requests — forms submitted to SharePoint libraries, triggering approval chains
• HR onboarding checklists — multi-step forms with conditional sections and repeating tables
• Compliance and audit forms — data collection tied to managed metadata and content types
• IT service requests — forms with cascading dropdowns pulling from external data connections (SOAP, REST, SQL)

SharePoint 2010/2013 workflows (built in SharePoint Designer or Visual Studio) handled:

• Document approval routing — serial and parallel approvals with escalation logic
• Three-state tracking — managing support issues, project tasks, or sales leads through status transitions
• Automated notifications — email alerts triggered by list item changes, due dates, or field values
• Content publishing approvals — routing pages to reviewers before publishing

The critical pattern: InfoPath forms and SharePoint workflows were often tightly coupled. A form submission triggered a workflow, the workflow updated list columns, and those columns drove the form's conditional visibility rules. When one side breaks, the entire process chain collapses. That is why this migration is rarely just a form rewrite — you are usually replacing UI, data model, automation, and audit trail at the same time.

The Business Impact of Unsupported Legacy Forms and Workflows

When these deadlines pass, the failure mode is immediate and binary — processes stop, not degrade.

Operational disruption: Every approval workflow running on the SharePoint 2013 engine halts on April 2. Purchase orders sit untouched. Document reviews don't route to Legal. Onboarding task lists don't auto-create. These aren't edge cases — they're the core use cases organizations built these workflows for.

Data trapped in XML: InfoPath saves user inputs as deeply nested XML files within a Form Library. Once the rendering engine is retired, average users cannot read the data. Extracting business context requires parsing raw XML tags. After retirement, accessing historical data requires the InfoPath 2013 desktop client on a compatible machine — a client that is itself end-of-support. The window to read your own historical data narrows with every OS and browser update.

Manual work spike: Teams revert to email chains, spreadsheet tracking, and manual follow-ups for any process that relied on automation. The organizations hit hardest are the ones that built 50–200+ workflows over the years and stopped tracking which ones are still active.

Security and compliance exposure: Running InfoPath forms on unsupported platforms means no security patches. InfoPath forms that use SOAP-based data connections or managed code present an expanding attack surface. For regulated industries — healthcare, finance, government — unsupported software is a compliance finding. If audit logs and workflow history are tied to a deprecated engine, you risk violating data retention policies during compliance audits.

Why Native Migration Tools Fall Short

Microsoft recommends Power Apps (for forms) and Power Automate (for workflows) as replacements. The recommendation is sound. The tooling to get there is incomplete.

No Automated InfoPath-to-Power Apps Converter

This is the single most important fact for InfoPath migration planning: Microsoft does not provide an automated migration tool to convert InfoPath forms into Power Apps. Every InfoPath form must be manually redesigned and rebuilt. There is no "Import InfoPath" button, no XSN-to-Power-App converter, and no automated field mapping. (mc.merill.net)

Microsoft's own announcement states you should "allow adequate time for migration" because "there is no migration tool provided." The Power Apps team has mentioned evaluating scalable migration programs, but as of early 2026, nothing has shipped.

Some third-party tools offer partial automation. Lightning Tools Form Migrator and Kudzu Migrator for Power Apps can analyze InfoPath form definitions and generate equivalent Power Apps structures, and in some cases migrate XML form data to SharePoint lists or Dataverse tables. Nintex positions Nintex Forms as a modern InfoPath replacement within its workflow platform. FlowForma markets automated conversion into its own form platform. These tools reduce manual effort but don't eliminate it, especially for forms with complex business logic, managed code, or deep data connections.

SPMT Drops Workflow History

The SharePoint Migration Tool (SPMT) can migrate SharePoint Designer 2010 and 2013 workflow definitions to Power Automate. But it explicitly does not migrate workflow history data. (learn.microsoft.com)

SPMT migrates:

• Workflow definitions and associations
• List, library, and content-type workflows

It does not migrate:

• Workflow run history (who approved what, when, with what comments)
• In-progress workflow state — a running item can land in the target as if the workflow never started
• Site workflows (only list/library/content-type scoped)
• All workflow actions — some unsupported actions are converted to placeholder "Compose" actions that do nothing

For organizations in regulated industries or with audit requirements, losing workflow history is a non-starter. That approval trail — who signed off, on what date, with what comments — is often the entire point of the workflow.

SPMT Action Support Gaps

SPMT doesn't support all SharePoint Designer workflow actions. Unsupported actions are converted to "Compose" placeholder actions — just markers showing where logic used to exist. Actions like "Log to History List" and "Set Workflow Status" have no direct Power Automate equivalent.

SPMT only converts workflows whose stage structure forms a directed rooted tree. If your workflow uses a general directed graph (stages that loop back or branch in non-tree patterns), SPMT will report an error and skip the workflow entirely.

The workflow migration feature in SPMT is still marked as public preview in Microsoft's documentation. Converted flows may not match original behavior exactly, and after migration, the flow owner must sign in to Power Automate, fix connection references, and manually turn the flows on. (learn.microsoft.com)

Power Automate Has Hard Architectural Limits

Even after migration, Power Automate imposes constraints that didn't exist in SharePoint Designer:

• Maximum 500 actions per flow — complex workflows must be split into parent/child flows
• Maximum 8 levels of nesting — deeply nested conditions or loops cause save-time errors
• 30-day run limit — if an approval takes longer than 30 days, the flow fails
• 28 days of built-in run-history visibility — the Power Automate dashboard only shows the last 28 days unless you deliberately log somewhere else
• Connector-specific throttling — SharePoint connector calls are subject to their own rate limits, separate from flow-level limits
• Premium licensing required for HTTP connectors, Dataverse, SQL connections, and child flows — features that were effectively free in SharePoint Designer

If your legacy workflows used deep conditional logic (common in multi-level approval chains), you'll need to redesign the flow architecture, not just port the logic. (learn.microsoft.com)

Mapping InfoPath XML Data to Power Apps and Dataverse

The hardest part of an InfoPath migration isn't rebuilding the form UI — it's dealing with the data. InfoPath stored everything as XML, and that XML doesn't map cleanly to modern relational or list-based storage.

The XML Problem

InfoPath forms stored in Form Libraries save each submission as an .xml file. The form template (.xsn) defines the schema, but the actual data lives in those individual XML documents. Every InfoPath form template uses an XML Schema (XSD) for structural and data validation. (learn.microsoft.com) Key issues:

• Not all fields are promoted to SharePoint columns. Only fields explicitly configured as "promoted" appear as list columns. Unpromoted data exists only inside the XML file — invisible to SharePoint views, search, and reporting.
• Repeating sections are embedded in XML, not relational tables. InfoPath handled one-to-many relationships (e.g., line items on a purchase order) through repeating XML nodes. This data was never stored in a child list or lookup column — it's nested inside each XML document.
• Data types don't align. InfoPath's XML schema types (xsd:date, xsd:boolean, xsd:string with patterns) don't map 1:1 to Dataverse column types or SharePoint list column types. Date formatting, boolean representations, and multi-value fields all require transformation.
• Attachments may be embedded in XML. Browser forms in a forms library can embed file attachments directly into the XML blob, subject to a 5 MB cap. These need to be extracted and stored separately. (learn.microsoft.com)

Extraction and Transformation Process

To migrate historical InfoPath data without losing records:

1. Export the .xsn template and extract the XML schema (manifest.xsd or embedded schema). This defines every field, its data type, and its nesting structure.
2. Bulk-download all .xml form submissions from the SharePoint Form Library using PowerShell (Get-PnPFile or CSOM) or direct WebDAV access.
3. Parse the XML programmatically. Use PowerShell ([xml] type accelerator), Python (lxml), or C# to extract field values from each XML file. For repeating sections, flatten nested nodes into separate rows keyed by a parent ID.
4. Transform and load into the target. Map extracted fields to SharePoint list columns, Dataverse table columns, or SQL tables. Use Power Automate or custom scripts to batch-insert records.

# Example: Extract promoted + unpromoted fields from InfoPath XML
$xmlFiles = Get-ChildItem -Path "C:\InfoPathExport" -Filter "*.xml"
foreach ($file in $xmlFiles) {
    [xml]$formData = Get-Content $file.FullName
    $ns = New-Object System.Xml.XmlNamespaceManager($formData.NameTable)
    $ns.AddNamespace("my", "http://schemas.microsoft.com/office/infopath/2003/myXSD")
    
    $requester = $formData.SelectSingleNode("//my:Requester", $ns).InnerText
    $amount    = $formData.SelectSingleNode("//my:TotalAmount", $ns).InnerText
    $lineItems = $formData.SelectNodes("//my:LineItems/my:LineItem", $ns)
    
    # Write parent record
    # For each $lineItem in $lineItems, write child record with parent reference
}

Choosing Your Target Data Store

Mapping Legacy Patterns to Modern Targets

• InfoPath custom form on a SharePoint list → Power Apps customized list form. This is the cleanest option when the old form was just a better UI over one SharePoint list. Microsoft supports customizing SharePoint list forms directly via Integrate > Power Apps > Customize forms. (learn.microsoft.com)
• InfoPath form library storing XML → new app plus new data model. Microsoft's scanner reports distinguish between CustomForm usage and FormLibrary usage — form-library usage stores InfoPath XML in the library. That usually means you need a real target schema in SharePoint lists or Dataverse, not just a UI rewrite. (learn.microsoft.com)
• Workflow history and approval audit → dedicated archive store. Native workflow migration does not preserve history. Build a target list, table, or audit log for comments, timestamps, prior assignees, and statuses.

For a deeper look at loading transformed data into SharePoint, see our How to Import Data into SharePoint guide.

Rebuilding the UI in Power Apps

Once the data is relational, you can build a Canvas or Model-driven Power App. Unlike InfoPath, which allowed users to inject custom C# code behind the form, Power Apps relies on Power Fx — a declarative, Excel-like formula language. Any heavy computational logic or external API calls previously handled by InfoPath code-behind must be offloaded to Power Automate or custom Azure Functions.

Don't treat form logic as a black box during the rebuild. Rebuild validations, default values, conditional visibility, and submit behavior from explicit test cases. Large or complex browser forms can already hit InfoPath publishing or runtime limits in SharePoint Online, which is one more reason to audit carefully before rebuilding. (learn.microsoft.com)

Rebuilding SharePoint Workflows in Power Automate

Workflow migration is a rebuild, not an upgrade. The execution models are fundamentally different.

Audit First: Know What You Have

Before rebuilding anything, you need a complete inventory. The Microsoft 365 Assessment Tool (open-source, maintained by Microsoft and the PnP community) scans your tenant for:

• All SharePoint 2013 workflows, per site collection and site
• Recency and volume of workflow usage
• Lists, libraries, and content types using workflows
• Power Automate upgradability score — indicating how many detected actions have a direct equivalent in Power Automate

For on-premises environments, use the SharePoint Migration Assessment Tool (SMAT) instead. SMAT also flags InfoPath forms that use unsupported SOAP calls, managed code, or old people-picker identities that don't map cleanly to Microsoft 365. (learn.microsoft.com)

The upgradability score is useful as a rough complexity indicator, but don't treat it as a migration guarantee. A workflow with a 90% score can still require a full redesign if the remaining 10% includes critical logic like multi-stage loops or custom status logging.

Understanding the Architectural Shift

SharePoint 2010/2013 workflows often used a state-machine architecture — moving from "Draft" to "In Review" to "Approved" — where the workflow could pause indefinitely, waiting for a specific field change. Power Automate is a trigger-and-action engine with a 30-day run limit.

This isn't a terminology difference. It changes how you model every long-running process. Instead of keeping a flow running for weeks waiting for an approval, update a "Status" column in your database. Build separate, smaller flows that trigger only when that Status column changes.

Mapping Legacy Workflow Patterns to Power Automate

Preserving Workflow History

Because native tools drop workflow history, you must engineer a custom extraction. The legacy WorkflowHistory hidden list contains the instance IDs, timestamps, and outcome strings of past approvals.

To preserve this:

1. Extract the hidden list data via the SharePoint REST API
2. Transform the user IDs to map to modern Entra ID (Azure AD) Object IDs
3. Write the history to an immutable archive table in Dataverse or a locked-down SharePoint List

This ensures historical approvals remain queryable after the 2026 cutoffs. Do this before the retirement dates — after April 2 for SP 2013 workflows, this data becomes read-only XML at best and may be inaccessible depending on your tenant configuration.

Step-by-Step Workflow Rebuild

1. Export the workflow definition from SharePoint Designer as a .xoml file or document it manually (screenshots + action list). If using SPMT, run a scan first to get the action inventory.
2. Map each action to a Power Automate equivalent using the mapping table above. Flag actions with no direct equivalent.
3. Redesign the flow architecture. If the original workflow exceeds 500 actions or 8 nesting levels, split it into a parent flow and child flows. This requires premium licensing.
4. Rebuild in Power Automate. Use the visual designer. For approval flows, leverage the Approvals connector. For list operations, use the SharePoint connector.
5. Migrate identity references. On-premises Active Directory users must be mapped to Microsoft Entra ID users. SPMT handles this automatically if you provide a user mapping file.
6. Test with production-like data. Don't test with 5 items and call it done. Test with a representative volume — the flow's behavior at scale (throttling, timeouts, parallel execution) will differ from small test runs.
7. Run legacy and modern workflows in parallel for a validation period before decommissioning the old ones.

Executing a Zero-Downtime Migration

The technical work is clear. The execution risk is in the timeline and the data you leave behind.

Migration Timeline

For a complex environment with 50+ forms and 100+ workflows, expect 8–16 weeks of active project work. For environments with fewer than 10 forms and simple approval workflows, a focused team can complete the migration in 2–4 weeks.

The Risks of Waiting

• April 2, 2026: SharePoint 2013 workflows stop running. No gradual degradation — full stop.
• May 18, 2026: You can no longer publish new or updated InfoPath forms in SharePoint Online. If you discover a bug in a migrated form during testing, you cannot fix the legacy version as a fallback.
• July 14, 2026: InfoPath Forms Services removed entirely. On-prem support ends for SP 2016/2019.
• Licensing costs increase under pressure. Rushed migrations often require premium Power Automate licensing, external consultants at emergency rates, and overtime for internal teams.
• Data loss window narrows. Every day you delay extracting InfoPath XML data and workflow history is a day closer to that data becoming practically inaccessible.

When to Call for Help

If your environment has fewer than 5 simple InfoPath forms and a handful of basic approval workflows, a competent SharePoint admin can handle this migration in-house using Microsoft's published guidance.

But if you're dealing with:

• Dozens of InfoPath forms with repeating sections, managed code, or SOAP data connections
• Deeply nested XML data that needs to be transformed into relational structures without losing historical records
• Workflow history that must be preserved for compliance or audit purposes (which SPMT explicitly drops)
• Site workflows or reusable workflows that have no like-for-like Power Automate equivalent
• A compressed timeline with limited internal bandwidth

...then you're looking at a data transformation and migration problem, not a form-rebuilding exercise. That's the kind of work we do at ClonePartner. We extract and transform deeply nested InfoPath XML data into modern Dataverse tables or SharePoint lists, preserve the workflow history and approval metadata that SPMT abandons, and reverse-engineer undocumented SharePoint Designer logic into clean Power Automate flows — typically in days, not months.

The July 2026 deadline is a hard stop. The time to audit your environment and engineer your migration path is now.