What it means and how to migrate
Microsoft has retired the legacy SharePoint 2010 and SharePoint 2013 workflow engines. SharePoint 2010 workflows were removed from Microsoft 365 tenants in November 2020, and SharePoint 2013 workflows were fully retired from all remaining Microsoft 365 tenants on 2 April 2026, with no option to extend.
Extended support for SharePoint Server 2016 and 2019 also ended on 14 July 2026, which pulls the supported infrastructure out from under on-premises workflow deployments running on those versions.
If your organization still has any of these workflows in play, they're either no longer running or they're running on infrastructure Microsoft no longer supports.
Why Microsoft has retired SharePoint 2010 and 2013 workflows
The SharePoint 2010 and 2013 workflow engines were built around a different set of assumptions from the way work happens now. Both were tightly coupled to their respective SharePoint versions, both sat siloed inside SharePoint rather than integrated with the wider Microsoft 365 ecosystem, and both were designed before the cloud-first, service-integrated model that now defines Microsoft 365.
Microsoft's own successor product is Power Automate, which sits inside the Power Platform and connects to more than 700 services across Microsoft 365 and beyond. In Microsoft's framing, Power Automate handles what SharePoint workflows used to, alongside a much broader range of automation scenarios the older engines were never designed to cover.
The practical result is that Microsoft no longer maintains the legacy engines. Once retired, workflows built on those engines stop running, and there's no path to keep them supported inside Microsoft 365.
How to tell if your organization is affected
The answer depends on where your SharePoint estate lives.
SharePoint Online (Microsoft 365 tenants)
Any workflow built on the SharePoint 2010 or SharePoint 2013 workflow engines has now stopped. That includes approvals, notifications, routing rules, and any automated document-library actions that used the classic workflow model. The most visible warning signs are workflows that no longer start when triggered, error messages when opening workflow lists in SharePoint Designer, and admin center notices from Microsoft.
SharePoint Server 2016 and 2019 (on-premises)
Extended support for both server products ended on 14 July 2026. The workflow engines themselves continue to run, but the underlying server platform is no longer supported by Microsoft, which affects security patching, compliance posture, and vendor support for anything running on those servers.
SharePoint Server Subscription Edition (on-premises)
This is the exception. Subscription Edition supported SharePoint 2010 workflows until 14 July 2026, and SharePoint 2013 workflows remain supported beyond that date under Microsoft's current roadmap. If you're on Subscription Edition specifically, your remaining SharePoint 2013 workflows continue to run, but the retirement direction of the legacy engines is unambiguous, and planning your migration now is the sensible position.
Third-party workflow tools.
If you use Nintex or another third-party platform that depends on the SharePoint 2013 workflow engine, you're affected regardless of which SharePoint version you're on. Vendor announcements from those platforms confirm the dependency, and their own migration paths have accelerated in response.
If you're not sure which category applies to your environment, the fastest way to check is to review your SharePoint admin center, list your active workflows, and confirm which engine each one runs on.
Your migration options
With SharePoint Online workflows now retired, there are two practical replacement paths.
Migrate to Power Automate
Power Automate is Microsoft's own recommended path and connects natively to SharePoint lists and libraries. For simple, event-driven workflows, particularly notifications, data movement, and single-step approvals, it handles the requirement well. The migration is manual, so every workflow needs to be rebuilt rather than lifted over automatically. For more complex processes with multi-stage approvals, conditional routing, and document generation, Power Automate typically needs to be paired with Power Apps and Dataverse, which adds licensing, developer resources, and product complexity.
Rebuild in a dedicated no-code process platform
The alternative is to move to a no-code platform designed specifically for structured business processes, forms, and approvals. FlowForma is the option we're most familiar with, but there are others on the market. The advantage of this route is that a single platform typically replaces the multi-product stack a full Power Automate migration ends up needing, so total-cost-of-ownership tends to be more predictable across a real enterprise migration.
Which path suits you depends on the complexity of the workflows you're migrating and how much developer resource you want to commit to the rebuild. Simple flows can move to Power Automate cleanly. Structured multi-step business processes with forms and audit trails typically move to a dedicated no-code platform more smoothly.
How FlowForma replaces legacy SharePoint workflows
Migrating from SharePoint
For a Microsoft 365 organization migrating off legacy SharePoint workflows, FlowForma is designed to slot into the same architectural position the legacy engines held.
Native SharePoint integration
FlowForma runs inside your existing Microsoft 365 tenant. Data stays in SharePoint. Permissions, audit trails, and document libraries all continue to work the way they did, so there's no data migration involved and no new tenant to secure.
No-code rebuild
Legacy SharePoint workflows are typically business-user-owned processes, approvals, routing logic, and document handling that were originally built or maintained by people who don't code. FlowForma preserves that ownership model. The rebuild is done by the same business users, using a drag-and-drop form and workflow designer, with IT providing governance around them.
AI Copilot for accelerated rebuild
FlowForma Copilot builds working processes from a plain-language description or an uploaded process diagram or documentation. For teams with a documented inventory of legacy workflows to rebuild, that means the migration is incredibly faster than recreating each process from scratch. FlowForma customers see a 60% increase in process automation using FlowForma Copilot versus Flow Designer.
Forms, workflow, document generation and audit trail in one platform
Many legacy SharePoint workflows combined form-based data entry, multi-stage approval, and document generation. FlowForma includes all three in the same platform, so the rebuild doesn't require stitching together multiple products.
For teams already running structured document workflows, our document workflow automation guide covers the pattern in more detail, and our workflow automation overview sets out the broader context. If you're also managing the retirement of InfoPath forms, our InfoPath replacement page covers that adjacent migration.
Talk to us about your SharePoint workflow migration
If you're managing the migration from legacy SharePoint workflows, whether you're already dealing with retired flows in Microsoft 365 or planning ahead of a server end-of-support, we can help you assess your options and build a realistic replacement plan.
Book a migration consultation, and we'll walk through your current workflow estate, identify the processes to prioritize, and show you what a FlowForma migration would look like on your timeline.
