Nintex to Power Automate migration services
A fixed-fee rebuild of a specific retired product, not a general automation project. Nintex Workflow for Office 365 left support in December 2025, and the SharePoint 2013 workflow engine it ran on was removed from existing Microsoft 365 tenants on 2 April 2026, so the approvals, notifications and document routing you built in Nintex are no longer firing. Senior US-based Microsoft engineers inventory every Nintex workflow and form, rebuild the ones people still rely on as Power Automate cloud flows and Power Apps forms on the SharePoint lists you already run, and state the licensing position for each flow in writing — one price, typical delivery in 2–4 weeks, 30 days of hypercare included.
Representative dashboard — sample data
What you get
A Nintex workflow bundled its trigger, branching, task assignments, notifications and history into one designer canvas on top of a SharePoint list. Power Automate keeps each of those as a visible, editable step, which is most of the rebuild.
Every Nintex workflow on every site is catalogued with its list, its owner and the last date it actually ran. Workflows nobody has started since the last reorg are retired on purpose rather than rebuilt out of habit.
State machines, Flexi tasks, workflow constants and pause-for-weeks steps have no one-to-one action in Power Automate. Each is redesigned to a documented pattern, so the flow behaves the way your staff expect rather than approximating it.
Assign-a-task and request-approval steps become Power Automate approval actions with reminders, escalation and delegation. Approvers respond from the card in their inbox, and the decision, comment and timestamp are written back to the item.
The forms that fed those workflows are rebuilt as Power Apps forms attached to the same SharePoint lists, with rules, repeating sections and lookups recreated, so the intake and the routing land on one platform together.
Each rebuilt flow is marked as covered by your Microsoft 365 plan or as needing Power Automate Premium, with the reason. You see the position before work starts, not after the first invoice.
Nintex workflow history and task lists stay in your tenant, and where an audit needs a continuous record the new flow logs each decision to a SharePoint list beside them. Nothing is deleted to make the rebuild tidier.
How it works
A free consultation plus a pass over your sites, workflow galleries, task lists and history lists tells us which Nintex workflows still run a real process and what each one does step by step. You get a written scope, one fixed price and a delivery date.
Every kept workflow is rebuilt as a cloud flow on its existing list, with routing, approvals, notifications and long-running steps redesigned to documented patterns. Nintex Forms that still matter are rebuilt in Power Apps, and your process owners test the highest-traffic flow first.
Each flow goes live with its history handled as agreed, the Nintex subscription is left with nothing depending on it, and your admins receive documentation they can maintain. We stay on for 30 days of hypercare after the last workflow is switched over.
Two dates decided this. Nintex published an end-of-life notice for Nintex Workflow for Office 365, with support ending in December 2025 and customers pointed at Nintex Automation Cloud, its separately subscribed successor. The reason was Microsoft's: Nintex for Office 365 workflows executed on the SharePoint 2013 workflow engine, and Microsoft's guidance on moving from classic SharePoint workflows (opens in new tab) records that the engine was turned off for new tenants on 2 April 2024 and fully retired for existing tenants on 2 April 2026, with Power Automate named as the replacement. There was no extension. If you are reading this, the approval that used to route a purchase request or the notification that told HR a new-hire form was submitted has already stopped, and the interim fix has probably been email.
What did not go anywhere is your data. Every Nintex workflow ran against a SharePoint list or library, and the list, its columns, its views and its permissions are untouched. The workflow history list and the task list the workflow wrote to are still there and still readable. The Nintex Forms product for Office 365 was explicitly excluded from the workflow announcement, so a form may still open; it simply has nothing running behind it. The rebuild therefore starts from a better place than a move off another platform: the container exists, the history exists, and the people who used the workflow in March are the same people who need it now. What is missing is the workflow itself, and that is what this service puts back. If your Nintex runs on-premises inside a SharePoint Server 2016 or 2019 farm, the same rebuild happens as one workstream of our SharePoint Server to SharePoint Online migration, because the lists have to land in the cloud before the flows can act on them.
Microsoft's SharePoint Migration Tool can carry SharePoint Designer 2010 and 2013 workflows into Power Automate, as its workflow migration overview (opens in new tab) describes. Nintex workflows are not on that list. They were authored in Nintex's own designer, stored in Nintex's own format, and used actions such as Flexi tasks, state machines and workflow constants that have no single equivalent action in Power Automate. The commercial analyzers that exist are useful for producing the inventory; none of them hands you a working flow. So each workflow is read action by action and rebuilt to the Power Automate pattern that does the same job, which is what the table below is for. The inventory in your written scope is a filled-in copy of it, workflow by workflow.
| Nintex action or feature | What it did | Where it lands in Power Automate |
|---|---|---|
| Start when items are created or modified | Fired the workflow automatically on a list or library event | The SharePoint connector's created, modified, or created-or-modified trigger, with a trigger condition so the flow only runs when the right column changes |
| Assign a task, Assign a Flexi task | Gave one or more people a task with configurable outcomes and reminders | The Start and wait for an approval action with custom responses, first-to-respond or everyone-must-approve, plus reminders and escalation on the timeout branch, as in Microsoft's approvals documentation (opens in new tab) |
| Request approval, Request review | A simpler sequential or parallel sign-off | Sequential or parallel approval actions inside condition branches; the decision, comment and timestamp are written back to the item |
| State machine | Moved an item between named states over days or weeks | A status column on the list driving a Switch action, usually split into one flow per transition so no single run has to live for the whole lifecycle |
| Workflow constants and variables | Site-level settings such as approver groups and thresholds shared across workflows | Environment variables in a solution, or a small settings list your admins can edit without opening the flow |
| Run if, Set a condition, Switch, Loop | The branching and repetition inside the workflow | Condition, Switch, Apply to each and Do until actions, one for one |
| Pause for duration, Wait for item update | Held the workflow for a fixed time or until a column changed | Delay and Delay until actions where the wait is short; anything that could exceed 30 days is redesigned as separate flows, because a cloud flow run has a 30-day lifespan that Microsoft documents on the same guidance page |
| Send notification | Email to requesters, approvers and watchers at each step | Outlook and Teams actions, with a rich-text body and the link to the item, all on standard connectors |
| Query list, Update item, Create item | Read and wrote other lists during the run | Get items, Update item and Create item on the SharePoint connector, with filter queries instead of full-list reads |
| Call web service, Web request | Reached an external system or SharePoint's own REST API | Send an HTTP request to SharePoint stays standard; a call to an external API uses the HTTP action or a dedicated connector, which is premium and flagged in the scope |
| Document generation and Nintex Forms | Produced a document from item data, and captured the request in the first place | Word and PDF generation reviewed case by case for connector type; forms rebuilt as Power Apps, described in the next section |
| Workflow history and task lists | The record of who did what, and when, inside the workflow | Run history in Power Automate for recent runs; where a longer audit record matters, the flow writes each decision to a SharePoint log list you keep |
Two rows decide the timeline. If your workflows are single-stage approvals with a notification or two, the project is mostly rebuilding screens of logic and it moves quickly. If they are state machines with pauses measured in weeks, web-service calls into an ERP and a form with repeating sections in front of them, there is real redesign to do, and we price that as the scope it is rather than discovering it in week three. K2 estates, now sold as Nintex Automation K2, follow the same inventory-and-rebuild pattern and are scoped under this service.
Most Nintex workflows started from a Nintex form, and a form that submits into a dead workflow is not much use even when it still opens. The forms that still matter are rebuilt as Power Apps forms attached to the same SharePoint list, the way Microsoft documents for customizing a list form (opens in new tab). Rules become Power Fx formulas on the control's properties, repeating sections become a gallery bound to a child list with a lookup to the parent, lookups and cascading drop-downs use the standard SharePoint connector, and the submit button saves to the list, which is what triggers the new flow. It is the same shape of work as our InfoPath to Power Apps migration services, and estates that adopted Nintex in the SharePoint 2013 era often still have both kinds of form; where they do, we scope them together. A form that has outgrown a list and needs a genuine application behind it moves into our custom Power Apps development service instead.
Nintex's own transition path is Nintex Automation Cloud, which is a further subscription on top of the Microsoft 365 licences you already hold. The argument for Power Automate is that most of what a Nintex workflow did is already covered. Microsoft's description of Power Automate licence types (opens in new tab) sets out the boundary: the Power Automate rights seeded into Microsoft 365 plans cover cloud flows on standard connectors, which includes SharePoint, Outlook, Teams and the approvals action, and that is the whole of a typical approval workflow. Premium connectors such as HTTP to an external API and SQL Server, and desktop flows for robotic process automation, need a Power Automate Premium licence for the user who owns the flow or a Process licence on the flow itself. Some Nintex estates do cross that line, particularly where a workflow called into an ERP or waited longer than a month. We say which side of it each flow sits on in the written scope, and where a premium connector is only reachable from a service account, one licence on that account is usually the answer rather than one per user. Current prices are on Microsoft's Power Automate pricing page (opens in new tab); we do not quote them here because they change.
We publish several pages that end in a Power Automate flow, and they are not interchangeable. The differences are in what you are starting from.
| Your starting point | What the work mostly is | The right service |
|---|---|---|
| Nintex workflows and forms that stopped running, in Microsoft 365 or on a farm | Inventorying a retired product and rebuilding each workflow and form on the lists that already exist | This page |
| SharePoint Designer workflows on an on-premises farm | Migrating the farm, with Designer workflows carried by Microsoft's tool or rebuilt where they should be redesigned | SharePoint Server to SharePoint Online migration |
| InfoPath forms that stopped opening in July 2026 | Rebuilding the form, its rules and its routing on data that already exists | InfoPath to Power Apps migration services |
| Approvals that still run through email and spreadsheets, with no workflow product yet | Mapping a process and designing an approval flow from scratch | Power Automate approval workflow consulting, or the walkthrough in our guide to replacing email approvals with Power Automate |
| Licensed RPA robots driving application screens — UiPath, Blue Prism or Automation Anywhere | Rebuilding each bot as a cloud flow or desktop flow, re-capturing UI selectors, and mapping attended and unattended robots onto Power Automate run modes | UiPath to Power Automate migration services |
| A process with no system behind it, or a form that needs to become an application | Data design first, then screens, then flows | Power Apps consulting |
This page is for an organization of roughly 20 to 500 people whose Microsoft 365 tenant or SharePoint farm carried a handful of Nintex workflows that mattered: a purchase requisition with a two-stage approval, a contract review with a Flexi task to legal, an onboarding checklist that created tasks for IT and facilities, a safety inspection that escalated when nobody responded. The usual trigger is blunt. Something that used to route itself stopped in April, the Nintex renewal notice arrived pointing at a new product, and the interim fix has been forwarding email. If that describes you, the workflows are the scope, the lists are already there, and the work is measured in weeks.
Once the rebuilt flows are live, new automation that starts from a process rather than a retired product sits under our Power Automate approval workflow consulting. Forms that need more than a list form behind them belong to our custom Power Apps development service, and if the lists and libraries the workflows act on need restructuring or permissions cleaned up, that is shaped by our SharePoint intranet and document management consulting. We serve all US states remotely from our Orange County, CA base.
Most Nintex estates sort into three phases. The table shows scope and typical timeline rather than prices, because an honest number requires reading your workflows first, which is the same principle described on how our fixed-fee process works.
| Phase | Scope | Typical timeline | Fee |
|---|---|---|---|
| Phase 1 — inventory and the workflow that hurts most | Every Nintex workflow and form catalogued with its list, owner and last run; the licensing position for each written down; the highest-traffic approval rebuilt as a cloud flow and tested by the people who request and approve | About the first week | Fixed fee — scoped after your free consultation |
| Phase 2 — the remaining active workflows and forms | State machines split into per-transition flows, long waits redesigned, constants moved to environment variables, external calls re-pointed, Nintex Forms rebuilt in Power Apps, history logging added where audit needs it | Weeks 2–3 | Fixed fee — scoped after your free consultation |
| Phase 3 — cutover, retirement and handover | Unused workflows retired by agreement, the Nintex app left with nothing depending on it so the subscription can lapse on your schedule, admin documentation and a short owner walkthrough, then 30 days of hypercare | Week 4 and close-out | Fixed fee — scoped after your free consultation |
Everything produced is yours from the first day. The flows, the forms, the solution files and the documentation live in your own Microsoft tenant, never in ours, and your own admins can edit any of it after we leave.
Related services
Approvals, RPA and integrations built as flows for the processes that start from scratch rather than from a retired workflow product.
The other 2013-era form technology in the same estates, rebuilt as Power Apps forms on the lists you already run.
Fixed-fee app development for the forms that have outgrown a list and need a real application behind them.
How an approval chain is built as a flow, step by step, with reminders, escalation and an audit trail.
How to pick the workflow worth rebuilding first instead of the loudest one.
Why teams already on Microsoft 365 usually rebuild their workflows here rather than on another subscription.
FAQ
No. Microsoft's SharePoint Migration Tool moves SharePoint Designer workflows, not Nintex ones, and the third-party analyzers that exist produce an inventory rather than a working flow. We read each Nintex workflow action by action, then rebuild it as a cloud flow with the same trigger, routing, approvals and notifications, documented so your admins can change it.
Nintex set end of support for Nintex Workflow for Office 365 at December 2025, and Microsoft retired the SharePoint 2013 workflow engine it ran on for existing Microsoft 365 tenants on 2 April 2026. Any Nintex for Office 365 workflow still in your tenant stopped running that day. The lists, forms and history it worked on are still there.
Often not. The Power Automate rights included with most Microsoft 365 plans cover cloud flows built on standard connectors such as SharePoint, Outlook and Teams. A Nintex workflow that called an external web service, wrote to SQL or ran for longer than 30 days may need Power Automate Premium, and the written scope says which ones before work starts.
Nintex Forms for Office 365 was not part of the workflow end-of-life announcement, so a form may still open. It just has nothing running behind it. We rebuild the forms that still matter as Power Apps forms on the same SharePoint lists, with their rules and repeating sections recreated, as one workstream of the same project.
Mostly. Nintex Workflow 2013, 2016 and 2019 run inside a SharePoint Server farm, and SharePoint Server 2016 and 2019 left support in July 2026, so the workflows usually move as one workstream of a farm migration. We inventory and rebuild them the same way; the difference is that the lists they act on move to SharePoint Online first.
Most projects run two to four weeks and are quoted as one fixed fee after a free consultation. The number is driven by how many Nintex workflows are still genuinely used, how much branching, state and external-call logic each carries, and whether Nintex Forms are in scope. Thirty days of hypercare follow go-live, and everything lives in your tenant.
Book a free consultation
Tell us what you’re trying to fix — a report, an approval process, an intranet, a Copilot rollout. We scope it as a fixed-fee project, you approve, and a senior engineer delivers in 2–4 weeks.
The fastest way to reach us is the form — tell us the task and we’ll reply within one business day.