How to Migrate Workflows From Nintex: Step-by-Step by Destination

How you migrate workflows from Nintex depends on your target platform. Inventory every workflow first. Then upgrade inside Nintex Automation Cloud, rebuild in Microsoft Power Automate and Power Apps, or rebuild on another governed platform. No path offers a one-click conversion, so plan to replace logic, test outside production, and deactivate each legacy workflow at cutover. K2 server, version and K2 Cloud moves follow their own routes, covered in a separate section below.

TL;DR

• Run the Know Your Workflow script or Nintex Insights first, and we suggest retiring anything idle for six to twelve months
• Nintex’s upgrade tooling moves workflows to Nintex Automation Cloud but leaves placeholders where actions are unsupported
• Microsoft offers no converter from Nintex, so Power Automate and Power Apps targets mean a rebuild, and a Kissflow target does too
• Each Nintex K2 path has different limits: server moves, version upgrades, SharePoint-to-K2 moves, and K2 Cloud
• Publish the new version only after user acceptance testing, then switch the old workflow off

A Nintex workflow migration moves a workflow’s start event, actions, connections, task forms, and stored data out of a Nintex product and into the platform you will maintain for the next several years. The workflow is the asset that matters. Forms come along for the ride.

For many SharePoint tenants the deadline has already passed. Microsoft retired the SharePoint 2013 workflow engine on 2 April 2026 and switched off the SharePoint add-in model on 2 April 2026. Nintex ended support for Nintex Workflow for Office 365 on 31 December 2025. If your approvals ran on those add-ins, they have stopped, and the migration is now a recovery project with a backlog attached.

IT directors who own SharePoint Online and Microsoft 365 have to choose where those approvals live next, and the work runs in a fixed order: inventory, triage, destination, migration by path, then testing and cutover.

Step 1: Inventory your Nintex workflows and forms

The first deliverable is a spreadsheet, not a new workflow. Until you can see every workflow, its start event and its last run date, you cannot size the move or pick a destination.

• Run the Know Your Workflow script against each SharePoint Online site collection, or pull the same view from Nintex Insights.
• Record the list or library each workflow runs on, its start event, the actions it uses, its connections, and its attached form.
• Add the last run date, then flag every workflow with no runs in the past six to twelve months, which we suggest as the retirement cutoff.
• Mark forms that use repeating sections, because those need extra handling on almost every destination.
• Name a business owner for each workflow that survives the filter.
• Note custom code or web service calls next to the workflow that makes them.
• The script lists what exists, and the owner interviews tell you what the business still needs.

Splitting the project into two tracks, one for SharePoint content and lists and one for workflows and forms, lets content move on its own schedule while the slower workflow rebuilds queue behind it. The split shapes the next decision, which is what to do with each workflow on the list.

Step 2: Decide what to retire, upgrade, or rebuild

Retiring a workflow is the cheapest migration you will do. Every workflow you drop before the move is one less you have to rebuild, test or explain to an auditor.

Sort each inventory row into one of these outcomes:

• Retire workflows that fell outside our suggested six-to-twelve-month activity window, once the owner signs off.
• Upgrade a workflow when its pre-upgrade report shows few unsupported actions and you are staying on Nintex Automation Cloud.
• Rebuild workflows that depend on unsupported actions, custom code, or task comments the business must keep.
• Rebuild every workflow bound for Power Automate, Power Apps or a platform outside Nintex, because no converter exists for those targets.
• Hold K2 artifacts for the K2 section of this guide. Version and identity rules decide their outcome.

The rebuild pile is usually where the budget goes. It is also where the choice of destination stops being abstract.

Step 3: Choose your destination

Your destination determines every step after this one. Nintex’s own path keeps you in the same vendor. The Microsoft path keeps you inside Microsoft 365. A governed enterprise application platform changes who builds and maintains the workflows from here on.

Community and vendor guides also name skybow, NITRO Studio, and K2 as destinations. Judge every option, including those, on three questions:

• Who will build and change these workflows a year from now?
• Will governance and the audit trail be at least as strong as what you ran on Nintex?
• How will you test a change before it reaches production?

Step 4: Migrate by path

Each destination has its own sequence, and none of them starts by importing a file. Find the branch that matches your Step 3 decision below.

How do you upgrade to Nintex Automation Cloud?

Nintex Automation Cloud, also called Nintex Workflow Cloud (the “NWC” in the status column), is the in-vendor route for Nintex for Office 365 workflows. The tooling converts supported actions, inserts placeholders for unsupported ones, and leaves task names, descriptions, and comments behind. Nintex publishes no list prices for Nintex Automation Cloud and sells by quote, per its pricing page.

• Open the SharePoint Online site and go to the Nintex workflow gallery.
• Check the “Upgrade to NWC status” column for each workflow.
• Select the ellipsis next to a workflow and run the pre-upgrade report.
• Select Upgrade Workflow.
• Reconfigure the start event and every connection in Nintex Automation Cloud.
• Replace each placeholder action. For example, a “build dictionary” action becomes “Add item to collection.”
• Rebuild the task forms and re-enter task names, descriptions, and comments by hand.
• Publish, and tick the box that deactivates the workflow in Nintex for Office 365 so it never runs twice.

How do you rebuild Nintex workflows in Power Automate and Power Apps?

No tool converts Nintex workflows into Power Automate flows or Nintex forms into Power Apps. The Microsoft route is a rebuild. Third-party tools tell you how large that rebuild will be.

• Run Flow Migrator, Kudzu, or ShareGate across the inventory to classify each workflow by the actions it uses.
• Rebuild the logic of each workflow as a Power Automate flow, starting with the highest-volume approvals.
• Rebuild each Nintex form in Power Apps.
• Extract repeating-section data, which Nintex stores as XML inside a single field, into child SharePoint lists before you rebuild the form that reads it.
• Recreate connections with the accounts that will own them in production.
• Decide where the rebuilt data lives. If you choose Dataverse over SharePoint lists, Microsoft lists the Dataverse Database capacity add-on at US$40 per GB per month.

Picture an expense-exception form with a repeating section of line items. The XML has to become rows in a child list before Power Apps can show or total them. Plan that data step as its own task.

How do you rebuild Nintex workflows on Kissflow?

Kissflow is an AI-powered enterprise application platform. In a Nintex migration, it is a rebuild destination. Kissflow fits the governed execution and exception layer around systems of record such as SAP, Oracle, Salesforce, and Workday, where structured work falls at the edges of what those core systems were built to do.

The case for Kissflow rests on who maintains the result. Kissflow is driven by business logic, not code, so business teams build and automate their own approvals while IT governs the platform. Aswaq Management and Services evaluated Power Apps and Creatio before choosing Kissflow.

Take a software-access request that ran on Nintex, with manager approval and a security review for anything that touches finance data:

• Write the inventory row up as a short requirements document covering the start event, approvers, branches, and the record each step updates.
• Upload that document to AI Builder. AI Builder is generally available as of May 2026 and generates a complete working app from a single prompt or an uploaded requirements document, which you then refine through conversation.
• Review the generated blueprint with the workflow owner. The blueprint covers the data model, pages, roles, workflows, and navigation.
• Confirm the roles and approvers in the blueprint with IT before testing begins.
• Run user acceptance testing with the workflow owner, then have an admin control what goes live.
• Confirm that audit logs record every action, timestamped and attributed, so your auditors can see who approved what and when.

Build your first governed approval workflow with AI Builder and see every change land in one audit log.

What are the on-premises options?

Staying on-premises is a legitimate destination when data residency rules or an air-gapped network rule out the cloud. Nintex for SharePoint on-premises has its own upgrade route through the Upgrade Center. Teams that keep some systems on-premises use Nintex Gateway to let cloud workflows reach them.

• Run the Upgrade Center extraction script against your Nintex for SharePoint farm.
• Import the package the script produces.
• Run the upgrade and review every workflow it flags.
• Use a database attach if you need workflow history to stay intact on the new farm.
• If K2 is the on-premises target, follow the Nintex for SharePoint to K2 path in the next section.

Step 5: Test and cut over

Every migration path ends the same way: nothing reaches production untested, and the old workflow is switched off the moment the new one goes live.

• Build and test against non-production lists and accounts, never against live data.
• Run user acceptance testing with each workflow owner, using real cases from the last quarter.
• Move in batches, starting with low-volume workflows that have few integrations.
• Pilot each batch with one team before opening it to everyone.
• Publish the new workflow and deactivate the legacy one in the same change window (Nintex for Office 365 offers a deactivate tick at publish).
• Keep the inventory spreadsheet as the cutover record, with a date and a sign-off for each row.

Nintex K2 migration: how to pick your path

A Nintex K2 migration depends on whether you are moving K2 servers or databases, upgrading blackpearl 4.7 to K2 Five, moving Nintex for SharePoint workflows into K2, or leaving for K2 Cloud, Nintex Automation Cloud, or Microsoft Power Platform. The constraint that matters most: moves to the cloud or to Power Platform are rebuilds, with no lift-and-shift or direct conversion tool.

How to move a K2 server or database

Prepare the network layer before you touch the data. Create DNS A Records for the K2 server and SQL Server layers so clients follow a name rather than a machine.

• Back up every K2 database, then stop the K2 service.
• Back up the SCSSO master key with Nintex’s scripts so encrypted credentials survive the move.
• Restore the HostServer, K2SQLUM, K2SmartBox, and K2SmartBroker databases on the new server.
• Create a local SQL alias if the SQL Server name changed.
• Scan tables for the old server name, update instance data, XML and service broker settings, then repoint SharePoint.
• The SQL scripts apply to K2 Five 5.0 and lower. Versions 5.1 and later use PowerShell instead.

How to upgrade from blackpearl 4.7 to K2 Five

Support for K2 blackpearl 4.7 ended on 31 December 2025, and Nintex Automation K2 5.9.1 is supported until 31 March 2027. Sources disagree on what an upgrade preserves. The answer depends on the method.

• An in-place upgrade runs existing 4.7 workflows on K2 Five without a rebuild
• Workflows originally built in k2.net 2003 are excluded from that and need rebuilding
• A clean K2 Five-only server cannot host 4.7 workflows, so plan a build-and-migrate project there
• Use the Process Version Migration Utility or the Live Instance Management API to move running instances to a new version
• Inventory custom service brokers and custom code, and retest every SmartObject that depends on them

How to move Nintex for SharePoint workflows into K2

The K2 Workflow Importer brings Nintex for SharePoint workflows into K2. Forms take a separate route.

• Run the K2 Workflow Importer against the Nintex for SharePoint workflows you kept after triage
• Rebuild each Nintex for SharePoint form as a SmartForm
• Use the SPFx Migration Tool for SharePoint-integrated K2 sites, after confirming its scope for your version on help.nintex.com
• Retest every imported workflow against the SmartObjects it now calls

Limits that apply to K2 Cloud

K2 Cloud accepts Azure AD identities only. Workflows from older designers do not deploy there.

• Refactor every Active Directory domain account and group into Azure AD before you move
• Rebuild workflows created in K2 Studio or K2 for Visual Studio, because Package and Deployment cannot carry them to K2 Cloud
• Replace custom service brokers that need on-premises access, or route them through Nintex Gateway

Moving off K2 entirely

Leaving K2 means rebuilding wherever you land, including Nintex Automation Cloud, Microsoft Power Platform, and Kissflow.

• Rebuild the logic of each K2 workflow and SmartForm on the target platform
• Let in-flight instances finish on K2 before you decommission it
• On Kissflow, K2 approval processes are rebuilt as apps that business teams own under IT governance

Items that do not carry over in a K2 move

Check these items before any K2 cutover: domain identities bound for K2 Cloud, K2 Studio and K2 for Visual Studio workflows, Nintex for SharePoint forms, running instances across versions, k2.net 2003 workflows, and custom service broker code.

Choose who owns the workflows next

A rebuild is also a chance to decide who owns these workflows next. Whatever the destination, choose process management software where the people who understand the approval can change it under IT’s governance.

Frequently asked questions

What is workflow migration?

Workflow migration is the move of a workflow’s trigger, actions, connections, task forms, and stored data from one platform to another. In a Nintex migration the workflow is what matters most, and the forms follow it. Depending on the destination, the move is either an upgrade of supported actions or a full rebuild, and no path offers a one-click conversion.

Which is better, Microsoft Power Automate or Nintex?

It depends on your target platform, because both routes involve manual rework. Staying in Nintex Automation Cloud means an upgrade that converts supported actions but leaves placeholders and task text to redo by hand. Moving to Power Automate and Power Apps keeps you inside Microsoft 365 but is a full rebuild, since no tool converts Nintex workflows or forms.

How much does Nintex cost?

Nintex does not publish list prices for Nintex Automation Cloud and sells it by quote. The budget for the migration work too, since rebuilds are usually where the money goes. If you choose Dataverse for the rebuilt data, Microsoft charges US$40 per GB per month for the Dataverse Database capacity add-on (checked 2 November 2026).

How to automate a workflow in SharePoint?

On SharePoint Online, you rebuild the workflow’s logic as a Power Automate flow and its form in Power Apps, starting with the highest-volume approvals. First record the list or library, start event, actions and connections for each workflow. Move any repeating-section data into child SharePoint lists before rebuilding the form that reads it.

Book a demo to see how Kissflow generates a governed approval app from your requirements document with AI Builder.