The real problem isn’t which tool to pick

Search for “process automation tools” and you’ll get a list of twenty platforms, a Gartner category page, and a lot of AI hype about agents that triage your inbox. None of that helps if you’re the person actually responsible for keeping a Nintex or K2 workflow running while everyone above you asks when you’re “moving to Power Automate.”

The real problem sitting on your desk usually looks like this: you have live approval routes, onboarding flows or document processes built years ago on a platform that’s now end-of-life, being sunset, or simply too expensive to keep licensing. Someone above you wants a Power Platform strategy. Nobody wants the finance approval workflow to stop working on a Tuesday morning.

That’s not really a tools question. It’s a sequencing question. This article treats it that way.

What “process automation tools” actually means in a Microsoft 365 shop

Gartner defines business process automation tools as software that enables the design, execution and monitoring of business processes involving diverse sets of systems and humans, playing a role in streamlining operations, reducing human error and improving decision making (Gartner). That’s a broad category – it covers everything from RPA bots to low-code workflow builders to full BPM suites.

If you already run Microsoft 365, you’re not really choosing from that whole market. You’re choosing between:

• Keeping Nintex or K2 running as-is, for as long as it’s supported and licensed.
• Power Automate, Microsoft’s own workflow layer, which Microsoft positions as an end-to-end automation solution combining low-code cloud flows, desktop RPA, AI processing and orchestration built into the platform you’re already paying for (Microsoft).
• A hybrid state, where both run side by side while you migrate process by process.

For most IT and Digital Workplace Managers we talk to, the honest answer is the third one – at least for a while. If you want the fuller picture of what a workflow management tool actually needs to do inside Microsoft 365, we’ve covered that in more depth in what is a workflow management tool, and do you need one if you already have Microsoft 365.

Why rip-and-replace is the wrong pitch

Every vendor conversation about legacy workflow migration eventually arrives at a big-bang proposal: audit everything, rebuild everything, cut over on a fixed date. It looks tidy on a slide. It’s a bad idea in practice, for three reasons:

1. Nintex and K2 workflows are rarely documented well enough to rebuild blind. The person who built the original approval chain left two years ago. The “process” now lives partly in the workflow, partly in someone’s inbox rules, and partly in a spreadsheet nobody admits to.
2. Not every workflow is worth rebuilding. Some are used twice a year. Migrating those first wastes budget you need for the ones that actually save hours every week.
3. A single cutover date means a single point of failure. If something breaks, it breaks everywhere, on a day you didn’t get to choose.

The pragmatic alternative is to keep the legacy platform supported on its own terms while you migrate in order of value – starting with the workflows that are costing the most staff time right now, not the ones that are technically easiest to lift and shift.

A phased approach: five named steps

Here’s the process we actually run with clients, in plain English, with no step skipped for the sake of a shorter proposal.

Step 1: Inventory what’s actually running. List every live Nintex or K2 workflow, who owns it, how often it runs, and what breaks if it stops. This alone usually surfaces workflows nobody remembered existed, and a couple that are technically still “live” but haven’t fired in a year.

Step 2: Triage by business impact, not technical complexity. Rank workflows by hours saved and people affected, not by how easy they’d be to rebuild. A five-step expense approval running weekly for 40 staff outranks a complex 20-step onboarding flow used twice a year, even if the onboarding flow looks more impressive on paper.

Step 3: Stabilise the legacy platform for the transition period. Before touching migration, make sure Nintex or K2 is properly supported – patched, licensed, and someone’s accountable for it – so nothing forces an emergency rebuild mid-project. This is the step most rip-and-replace pitches skip entirely, because there’s no glamour in supporting something you’re planning to retire.

Step 4: Rebuild in Power Automate, highest-impact process first. Use the triage list from Step 2. Rebuild, test against the real business rule (not just the old flow diagram), and run both systems in parallel briefly before switching the live version off. For ideas on what a rebuilt process actually looks like day to day, see real examples of operational workflows you can automate with Power Automate this month.

Step 5: Decommission platform by platform, not all at once. Once a workflow is confirmed working and adopted in Power Automate, retire its Nintex or K2 equivalent. Repeat until the legacy platform has nothing left running on it and can be switched off cleanly – rather than left in an ambiguous half-retired state that still needs licensing and admin time.

What this looks like for expense approvals and onboarding

The two workflows almost every client leads with are expense approvals and staff onboarding – because they’re the ones generating constant chasing emails and manual data entry. If that’s your starting point, we’ve written a detailed walkthrough of what modern process automation actually looks like for expense claims specifically in expense approvals eating your team’s week? Here’s what process automation actually looks like.

The pattern holds for onboarding, holiday requests, IT ticket routing and most other approval-heavy processes: they’re rarely “just” a workflow. They’re a queue, an approval route, a source of record, and often a workaround for something nobody’s had time to fix properly.

Choosing who runs the migration

A Nintex or K2 to Power Automate migration is exactly the kind of project that goes wrong when it’s handed to whoever’s free, rather than someone who’s done it before. Before you brief anyone – internal team, generalist IT contractor, or agency – it’s worth working through how to choose a process automation company for Microsoft 365 (not just any RPA vendor), because the questions that matter are different from a standard software procurement checklist.

At ThePoint, this kind of work is delivered by a senior consultant end to end, not handed off to junior staff partway through – and we support Nintex and K2 on an SLA basis alongside the migration itself, so the legacy platform doesn’t become someone’s unmanaged risk while the new one gets built. Automations are quoted at fixed price, starting from £500, so you know the cost of migrating a given workflow before it starts, not after.

How this fits your wider Microsoft 365 picture

Workflow migration rarely happens in isolation. It’s usually one part of a wider digital workplace tidy-up that also touches file server migration to SharePoint, intranet consolidation, and search. If you’re weighing up workflow platforms alongside a broader intranet or search decision, our guide to workflow management in operations, in plain English is a useful starting point for framing the whole conversation for stakeholders who aren’t in IT.

FAQ

Can we keep Nintex or K2 running while we migrate to Power Automate?

Yes, and for most organisations this is the sensible route rather than a forced cutover. Legacy platforms can be supported on an SLA basis while workflows are migrated one at a time, in order of business impact, so nothing live gets disrupted mid-project.

How long does a Nintex or K2 to Power Automate migration take?

It depends entirely on how many workflows are live and how well they’re documented. A phased approach – inventory, triage, rebuild highest-impact processes first – means you get value early rather than waiting for one big cutover date.

Is Power Automate actually a replacement for Nintex or K2?

For most cloud-based approval and data-entry workflows, yes. Microsoft positions Power Automate as an end-to-end automation solution covering low-code cloud flows, desktop RPA and AI-powered processing, built directly into Microsoft 365 rather than as a bolt-on platform.

What happens if we migrate the wrong workflows first?

You spend budget rebuilding processes that don’t save much time, while the workflows actually generating chasing emails and manual data entry stay on the legacy platform. Triaging by business impact before any rebuild work starts avoids this.

Do we need to hire internally to manage this migration?

Not necessarily. Many businesses don’t have in-house Power Platform expertise and don’t want to hire for a project-shaped piece of work. A retainer arrangement with a senior consultant gives you on-demand access to that expertise without adding headcount.