SharePoint 2013 workflow is retired. What now? A migration playbook for Nintex and enterprise workflow estates

Microsoft 365’s SharePoint 2013 workflow engine reached full retirement on April 2, 2026.

For organizations that completed their migration, that date is history.

For organizations that still have business processes, forms, integrations or operational knowledge tied to the old workflow estate, the harder work may only now be becoming visible.

The problem is no longer simply:

How do we convert these workflows?

It is:

How do we preserve the business process, remove obsolete design choices, recover undocumented knowledge, choose the right target platform and cut over without disrupting live operations?

That is a workflow-modernization problem, not a file-conversion problem.

Microsoft’s current guidance is explicit that organizations with processes that depended on SharePoint 2013 workflow should migrate them to Power Automate or another supported solution. Nintex also provides migration paths and tooling for customers moving from legacy SharePoint-based workflows into newer Nintex platforms.

But tooling does not make the architectural decisions for you.

A successful migration still depends on understanding what the workflow actually does, why it exists, what it integrates with, which records are authoritative, how exceptions are handled and whether the process should survive in its current form at all.

This playbook explains how to approach that work.

First, separate the technology retirement from the business process

Legacy workflow estates create a dangerous illusion.

Because the process is represented by a workflow definition, teams assume the definition is the process.

It is not.

The real process includes:

• the trigger;
• the form or intake channel;
• business rules;
• user roles;
• approvals;
• escalations;
• notifications;
• deadlines;
• integrations;
• document handling;
• security;
• exception paths;
• reporting;
• audit history;
• operational workarounds;
• and the people who know what to do when the workflow behaves unexpectedly.

If you migrate only the visible workflow diagram, you can still lose the operating model.

This is why the first objective should be to preserve business continuity and business meaning, not visual similarity.

Amayztech’s Intelligent Automation work treats workflow modernization as an operating-system problem: understand the process, systems and controls first, then choose the best automation pattern.

Do not migrate every workflow one-to-one

A one-to-one migration feels safe because it appears to reduce change.

It can also preserve years of accumulated technical debt.

Legacy estates often contain workflows that exist because of constraints that no longer apply:

• duplicated workflows created for separate departments;
• hard-coded email recipients;
• obsolete approval levels;
• workarounds for old SharePoint limitations;
• logic that belongs in a reusable service;
• steps that were added after incidents and never revisited;
• workflows with no active owner;
• workflows that have not run in months;
• redundant status fields;
• manual compensating controls around unreliable integrations.

Nintex’s own migration guidance acknowledges this distinction. Its SharePoint-to-K2 migration material recommends assessing and categorizing workflows, then deciding whether each one should receive minimal change, moderate redesign or complete rebuild rather than assuming direct conversion is always best.

The goal is not to reproduce the legacy estate perfectly.

The goal is to preserve what has business value and remove what does not.

Use four disposition choices: retire, retain, redesign, rebuild

Every workflow should receive an explicit disposition before migration begins.

Retire

The process is obsolete, duplicated or no longer worth automating.

Typical indicators:

• no meaningful executions in the relevant period;
• no identifiable business owner;
• the business function moved to another system;
• the workflow duplicates another process;
• the output is no longer used.

Retirement is a migration success, not a failure.

Every workflow you safely remove is one less object to migrate, test, support and govern.

Retain

The process remains valid and the existing logic can move with limited change.

This is appropriate when:

• business rules remain current;
• integrations are supported;
• the form and data model remain suitable;
• the workflow is stable;
• there is little value in redesign.

“Retain” should still include technical validation. A workflow that behaves correctly in one engine may require different configuration in another.

Redesign

The business outcome remains valid but the process structure should change.

Typical reasons:

• too many approval steps;
• duplicated logic;
• brittle notifications;
• poor exception handling;
• process ownership changed;
• the target platform provides a better reusable pattern;
• forms, integrations or data structures can be simplified.

Redesign usually creates more long-term value than literal migration.

Rebuild

The process is business-critical but the old implementation is no longer a useful foundation.

This may be appropriate when:

• dependencies are unsupported;
• the process spans several systems;
• the old workflow contains extensive technical debt;
• reporting and audit requirements have changed;
• the process needs a new data model;
• there is a substantial change in operating policy;
• the target architecture is materially different.

A rebuild is not the same as a greenfield fantasy. It should still preserve validated business rules and operational knowledge from the existing process.

Build an inventory that is useful for decisions

An inventory should not stop at workflow name and location.

For each workflow, capture enough information to decide migration priority and effort.

Dimension	What to capture
Business	Process name, business owner, purpose, criticality, user group
Usage	Execution volume, last execution, peak periods, seasonality
Trigger	List event, manual start, schedule, API/event, form submission
Logic	Approval levels, business rules, routing, SLAs, escalations
Forms	Form technology, fields, validation, conditional sections
Data	Lists, databases, documents, master-data dependencies
Integrations	SharePoint, SQL, APIs, line-of-business systems, email, identity
Security	Roles, service accounts, impersonation, privileged actions
History	Audit requirements, workflow history, retention requirements
Exceptions	Common failures, manual recovery steps, known workarounds
Technical	Workflow engine, custom code, unsupported actions, third-party components
Target	Retire, retain, redesign or rebuild
Migration	Complexity, dependencies, test effort, target wave

This inventory becomes the control plane for the migration.

It lets the organization answer a question executives care about:

How much of the estate do we actually need to move, in what order, and with what risk?

Prioritize by business consequence, not by workflow count

A program can migrate 80% of workflows and still be in serious trouble if the remaining 20% runs critical operations.

Do not report progress only as “workflows migrated.”

Track business coverage.

A useful prioritization model considers:

Business criticality
What happens if the process stops?

Transaction volume
How much work depends on it?

Time sensitivity
Can work wait, or does delay create customer, financial or regulatory consequences?

Integration complexity
How many external systems need to behave correctly?

Change risk
How sensitive are users to process changes?

Knowledge concentration
How many people understand the current implementation?

Migration complexity
How difficult is it to recreate or redesign?

A low-volume annual regulatory process may deserve higher priority than a high-volume convenience workflow if failure has much greater consequence.

Map dependencies before selecting the target pattern

A workflow rarely lives alone.

Before choosing a target platform, identify dependencies across four layers.

1. User experience

Where does the user begin?

A SharePoint list? A Nintex form? A portal? Email? A line-of-business application?

Migrating the workflow engine while leaving a broken or unsupported intake experience does not solve the process.

2. Data

What is the system of record?

Is information stored in SharePoint lists, SQL Server, a document-management system, an ERP, a regulatory platform or another business application?

Do not accidentally turn the workflow engine into a database.

3. Integration

What does the workflow call?

• REST or SOAP services;
• databases;
• document repositories;
• identity systems;
• email;
• ERP systems;
• case-management systems;
• custom service brokers;
• scripts;
• legacy endpoints.

Every integration needs a target-state decision.

4. Control

What makes the process trustworthy?

• access control;
• segregation of duties;
• approval authority;
• timestamps;
• audit history;
• retention;
• escalation;
• evidence of completion.

Migration testing must prove these controls, not only that tasks can move from one person to another.

Where the workflow estate spans older applications and document platforms, cloud and integration capabilities often become part of the migration whether or not the original project was described as an integration initiative.

Choose the target platform from the process requirements

There is no universal answer to “What should replace SharePoint 2013 workflow?”

Microsoft recommends Power Automate or another supported solution.

For Nintex customers, options can include modern Nintex cloud offerings or Nintex Automation K2 depending on requirements, architecture and deployment constraints.

Other organizations may decide that a custom application or another orchestration platform is more appropriate.

The decision should follow requirements.

Power Automate may fit when

• the organization is deeply standardized on Microsoft 365;
• processes are well suited to Microsoft cloud connectors;
• citizen-development governance is mature;
• the required actions and scale fit the platform;
• cloud deployment aligns with policy.

Nintex Automation K2 may fit when

• the organization needs a dedicated workflow/application platform;
• complex forms and long-running workflows matter;
• integration patterns require deeper orchestration;
• on-premises or controlled deployment is important;
• existing K2 skills, components or investments create value.

Nintex’s current documentation describes K2 as a separate workflow engine with support for REST, SOAP and custom service-broker integration patterns, which can make it suitable for more complex enterprise orchestration.

A modern Nintex cloud platform may fit when

• the organization wants cloud-first workflow automation;
• the process can use supported cloud integrations;
• governance and data residency requirements are compatible;
• migration tooling reduces effort for the existing Nintex estate.

Custom application/workflow services may fit when

• workflow is embedded in a larger product;
• the process needs highly specialized user experience or logic;
• platform licensing becomes inefficient at scale;
• the organization has the engineering and support model to own custom software.

The important point is that the target should be selected against the workflow estate’s requirements, not against the loudest migration message.

Treat unsupported actions as design decisions

Migration tools are valuable because they can accelerate repetitive conversion work.

They should not be mistaken for proof that the migrated workflow is correct.

Nintex’s Office 365 upgrade documentation notes that some actions may require manual configuration or replacement and that unsupported actions can be represented as placeholders requiring attention.

That is exactly where migration discipline matters.

Every unsupported or partially converted action should become one of:

• replace with a supported native action;
• redesign the process;
• move logic into an integration service;
• replace obsolete functionality;
• retire the step;
• rebuild the relevant component.

Do not solve every incompatibility by inserting custom code.

Custom extensions can be appropriate, but they create future support and upgrade obligations. Use them deliberately.

Preserve audit and history before you cut over

Workflow history is often treated as a technical detail until someone needs it for:

• an audit;
• a complaint;
• regulatory evidence;
• investigation;
• legal discovery;
• operational reconstruction.

Migration planning should explicitly decide what historical evidence must remain accessible after cutover.

Nintex’s own migration guidance has warned customers that legacy workflow version or audit history may not automatically move with upgrade tooling and recommends exporting required history for retention.

The exact retention requirement depends on the organization and process.

The principle does not.

Do not discover your history strategy after the old environment is gone.

For material processes, define:

• what history must be retained;
• in what format;
• for how long;
• who can access it;
• how it can be searched;
• whether it is immutable;
• how it links to the migrated process or business record.

This is also an information-governance and security-and-risk issue, not just a migration task.

Test the business process, not only the workflow definition

A migrated workflow can publish successfully and still fail in production.

Testing should cover the complete operating path.

Functional tests

• correct triggers;
• correct routing;
• approvals and rejections;
• rework loops;
• escalations;
• notifications;
• deadlines;
• exception paths;
• integrations;
• attachments and documents.

Security tests

• role-based access;
• privileged actions;
• service identities;
• delegation;
• segregation of duties;
• unauthorized-user behavior.

Data tests

• required fields;
• existing-record compatibility;
• data types;
• encoding;
• large values;
• historical records;
• document metadata.

Operational tests

• retry behavior;
• unavailable integration endpoints;
• duplicate triggers;
• delayed callbacks;
• partial failure;
• restart/recovery;
• monitoring;
• support visibility.

User acceptance testing

UAT should involve actual process owners and representative users, not only the migration team.

Users should validate the business outcome, not simply confirm that screens load.

Use migration waves, not a single big-bang release

A phased migration creates learning without forcing the organization to run two estates indefinitely.

A practical wave sequence is:

Wave 0: Prove the migration pattern

Choose a small set of representative workflows.

Include enough complexity to test the architecture, deployment process, integrations, security and support model.

Do not choose only the three easiest workflows and call the platform proven.

Wave 1: Low-risk repeatable processes

Move simpler workflows that use established patterns.

This builds delivery velocity and validates tooling.

Wave 2: Integrated departmental processes

Move workflows with more complex forms, integrations and business rules.

By this point, common components should be reusable.

Wave 3: High-criticality workflows

Move the processes where failure creates significant operational, financial, customer or regulatory consequence.

These deserve the strongest testing, cutover and rollback plans.

Wave 4: Decommission and close

Retire the old runtime, remove obsolete integrations, close service accounts, archive evidence and update support documentation.

A migration is not complete while the old estate remains silently operational “just in case.”

Parallel running should have a purpose and an end date

Running old and new workflows in parallel can reduce cutover risk for selected processes.

It can also create duplicate work, conflicting records and uncertainty about which system is authoritative.

Use parallel operation selectively.

Define:

• what is being compared;
• how long the parallel period lasts;
• which system is authoritative;
• how duplicate actions are prevented;
• what success criteria allow the old path to be disabled.

Nintex’s current K2 migration material also supports phased approaches and, in some scenarios, old and new environments operating during transition.

The key is governance.

Parallel running should be a controlled migration technique, not a permanent architecture.

Capture institutional knowledge while the people still remember it

The highest-risk migration dependency is often not technical.

It is the person who says:

“That branch looks strange, but don’t remove it. Finance needs it at month end when the vendor feed arrives late.”

That knowledge rarely appears in the workflow name.

Modernization should capture:

• why unusual logic exists;
• known exceptions;
• manual fallback procedures;
• business-owner expectations;
• support escalation paths;
• integration quirks;
• peak-volume behavior;
• temporary controls that became permanent.

This is one reason Amayztech treats workflow modernization as more than platform implementation. Our IT staffing and delivery services and managed support work often sits alongside automation because durable ownership matters after the migration team leaves.

Avoid recreating the same governance problem on a newer platform

A migration project can technically succeed and still leave the organization with the same structural weaknesses:

• no workflow owner;
• no naming standard;
• no environment strategy;
• no reusable components;
• no release process;
• no documentation;
• no support model;
• uncontrolled citizen development;
• direct production changes;
• unclear licensing ownership.

Use the migration as the moment to establish a better operating model.

At minimum, define:

Ownership

Every production workflow should have a business owner and a technical/support owner.

Environments

Separate development, testing and production where the platform and risk justify it.

Change control

Material changes should be reviewed, tested and traceable.

Reuse

Common integrations, notifications, forms and business rules should be engineered for reuse where sensible.

Monitoring

The support team should know when workflows fail, stall or exceed expected processing times.

Documentation

Document purpose, dependencies, ownership, recovery and deployment—not every visual step in prose.

Lifecycle

Workflows should have a review and retirement path.

A workflow estate that can only grow will eventually become another migration problem.

Use the migration to prepare for AI without embedding AI everywhere

Workflow modernization is also a chance to make future AI adoption easier.

That does not mean adding generative AI to every process.

It means separating the architecture cleanly:

• reliable process state;
• clear systems of record;
• reusable integrations;
• structured audit data;
• well-defined human decision points;
• document and data access through governed interfaces.

Those foundations make later AI use cases safer.

Our guide on where AI belongs in regulated workflows explains how to assign different authority levels to AI retrieval, extraction, recommendation, drafting and action.

Modernize the workflow first.

Then add intelligence where it improves the operating model.

A practical migration scorecard

Before declaring a workflow migrated, score it against the following questions.

Area	Completion test
Business	Business owner accepts the new process
Function	All required paths and exceptions work
Data	Records are stored in the intended system of record
Integration	External calls succeed and failures recover safely
Security	Roles and privileged actions are validated
Audit	Required evidence and history remain accessible
Operations	Monitoring, support and escalation are ready
Performance	The process meets expected volume and timing
Continuity	Cutover/rollback plan is proven
Governance	Ownership, documentation and change process exist
Legacy	Old workflow is disabled or has an approved retirement date

That scorecard turns “migration complete” into an operational statement rather than a technical one.

What to do if the April 2026 deadline passed and you are still exposed

If an organization still has unresolved dependencies after retirement, the priority is not to launch a large transformation program before taking action.

Start with containment.

1. Identify affected business processes. Determine what stopped, what was manually replaced and what is still creating operational exposure.
2. Establish temporary controlled procedures. Document the manual process, approvals and evidence required to keep critical operations moving.
3. Recover available workflow knowledge. Use retained documentation, exports, screenshots, source packages, business users and system records.
4. Prioritize by business consequence. Restore critical processes before low-value convenience workflows.
5. Select the minimum viable supported target architecture. Avoid another temporary solution that creates a second migration.
6. Document the control gap. Risk, compliance and business owners should understand the temporary state and remediation plan.
7. Execute in controlled waves.

The deadline matters.

But panic-driven rebuilding can create a second failure.

Frequently asked questions

Is SharePoint 2013 workflow still supported in Microsoft 365?

No. Microsoft states that SharePoint 2013 workflow was fully retired for existing Microsoft 365 tenants on April 2, 2026. Organizations that depended on it should move affected processes to Power Automate or another supported solution.

Does every Nintex workflow need to be rebuilt?

No. The right disposition depends on the workflow. Some can be migrated with limited change, some should be redesigned, some should be rebuilt and others should be retired. A workflow inventory and business-owner review should happen before migration waves are committed.

Can Nintex workflows be migrated automatically?

Migration and upgrade tooling can reduce conversion effort, but it does not eliminate validation. Some actions or configurations may require manual attention, substitution or redesign. Forms, integrations, security, history and operational behavior also need testing.

Should we move from Nintex to Power Automate?

Not automatically. Power Automate can be a strong fit for Microsoft-centric cloud workflows, but the target platform should be selected against process complexity, forms, integration requirements, deployment constraints, security, governance, licensing and internal skills. Nintex Automation K2, modern Nintex cloud platforms and other supported orchestration options may be appropriate for different estates.

What should be migrated first?

Prioritize by business consequence and architectural learning. Begin with a representative pilot that proves the migration pattern, then move repeatable lower-risk processes before the most critical integrated workflows. Do not prioritize solely by workflow count.

What happens to historical workflow audit data?

History may not automatically transfer with migration tooling. Determine retention and audit requirements before decommissioning the legacy environment, then archive required history in a controlled and searchable form.

Sources and further reading

• Microsoft Learn: Workflows in SharePoint
• Microsoft Learn: Modernize SharePoint 2013 workflows
• Nintex: SharePoint to K2 Migration FAQs
• Nintex: Upgrading from Nintex Workflow for SharePoint to Nintex Automation K2
• Nintex Help: Upgrade workflows to Nintex Workflow
• Nintex Help: K2 Workflow Importer

External references are cited for context. No endorsement of Amayztech by Microsoft or Nintex is implied.

Next step

Still carrying risk from a legacy Nintex, K2 or SharePoint workflow estate?

Amayztech can help inventory the estate, recover business and integration dependencies, define the target architecture, migrate in controlled waves and establish the support model after cutover.

Discuss your workflow modernization