Opinion · Platform replacement

Migration isn't the fix: replacing a legacy workflow platform in financial operations

Every replacement project starts the same way: change has become too slow. Most of them end with the same problem running on a newer logo.

menu_book Start reading
Jonty Hurwitz
Written by
Jonty Hurwitz
Founder
Read time
8 min
Published
Aug 2026

Nobody replaces a workflow platform because they're bored of it. They replace it because change has become impossible. A regulator updates a rule, a client wants a different approval path, an exception type appears that nobody modelled three years ago - and every one of those turns into a ticket, a sprint, and a wait.

So a replacement project gets funded. A vendor is selected. Eighteen months later, the ops team is still raising tickets to change a process. The platform is new. The bottleneck is identical.

That's not bad execution. It's the predictable result of treating this as a migration problem when it is an ownership and governance problem.

If your operations team still can't change a process without engineering, you didn't replace the platform. You reinstalled it.

01 · Why the project starts

The three symptoms that trigger a replacement

The business case is almost never written as "our platform is old." It's written from three symptoms, and they show up in this order.

The backlog
Process change requests queue behind product work in an engineering backlog. A two-field change to an onboarding form is quoted in sprints. Ops stops asking and reverts to a spreadsheet beside the platform.
The developer tax
Every new rule, jurisdiction, fund structure or exception path needs someone who can read the platform's config language. The people who understand the process are not the people allowed to change it.
The audit scramble
Evidence lives across the platform, an inbox, a shared drive and someone's memory. Reconstructing who approved what, on which version of the data, becomes a manual project every review cycle.

Notice what all three have in common: none of them is about the technology being old. They're about who is allowed to change the process, and whether governance is a property of the system or a thing people assemble by hand.

02 · Why it doesn't fix it

Swapping one horizontal platform for another recreates the problem

The usual replacement is a newer general-purpose tool: a modern BPM suite, another low-code platform, a generic automation product. These are genuinely good pieces of engineering. They're also deliberately empty. They ship with a canvas, not with a point of view about regulated financial operations.

Which means everything that makes a fund or client process defensible has to be built, by hand, on top:

1
Maker-checker becomes a build item
Four-eyes approval isn't a checkbox on a horizontal platform. It's a pattern your team implements per workflow: separate roles, block self-approval, handle delegation, cover the out-of-hours case. Implemented eleven times, it will differ eleven ways.
2
The audit trail is an application you now maintain
Task logs are not an audit trail. An auditable record needs the inputs, the version of the data, the system responses, the human decision and the timestamp, immutable and exportable. On a generic platform that is a schema, a retention policy and a reporting layer somebody owns forever.
3
Ownership stays with IT
Because governance was hand-built, changing a process risks breaking a control. So change goes back through engineering - correctly, given how it was built. The backlog reappears, now with a migration bill attached.

This is the trap. The replacement succeeds on its own terms - the old system is decommissioned, the new one is live - and fails on the only measure that mattered: how long it takes to change a process safely.

A horizontal platform adapted to finance will always be a project. A platform built for regulated financial operations is a starting point.

03 · What has to change

The replacement test

There's a single question that separates a replacement that works from one that repeats. Ask it of any shortlisted platform, and insist the answer is demonstrated on your own process, not described.

The test

Can the operations team that lives with the process build and change it themselves, within days, with maker-checker approvals, exception handling and a complete timestamped audit trail already on - without rebuilding a single control?

Three things have to be true for that answer to be yes.

Ops owns the process
The people who handle capital calls, NAV oversight and investor onboarding build and adjust those workflows directly. No config language, no release train, no ticket.
Governance is default, not configured
Four-eyes approvals, role separation, exception routing and an immutable, timestamped record apply to every workflow because the platform works that way - not because someone remembered to add them.
It augments, not replaces
Your ledger, CRM, KYC provider and data room stay exactly where they are. The new layer orchestrates across them by API. No second rip-and-replace hiding inside the first.

That third point matters more than it sounds. Plenty of replacement projects quietly become data-migration projects, because the new platform wants to be the system of record too. It shouldn't. Your ledger owns the books. What you're replacing is the layer that runs the process across everything else.

04 · Before and after

One change request, two worlds

Take a concrete, unremarkable change: a regulator-driven update requiring a second approval on any redemption above a threshold, plus an extra document check for one jurisdiction. Nothing exotic. It happens several times a year.

On a legacy or generic platform
Ops writes a change request. It's triaged, scoped, and lands in the backlog behind product work. An engineer picks it up next sprint, updates the workflow definition and the hand-built approval logic, and discovers the audit schema needs a new field. QA, change board, release window. Six to twelve weeks, and in the meantime the control is enforced by a manual checklist that will itself be an audit finding.
On Next Matter
The operations lead opens the workflow, adds a conditional approval step above the threshold and a document check for the jurisdiction, and publishes a new version. Maker-checker applies automatically. Every instance from that moment carries the new control, and the audit trail records the change, who made it, and which version each case ran on. Live in days, with no gap in evidence.

The difference isn't speed for its own sake. It's that in the first world, the safe option is to delay the change; in the second, the safe option is to make it.

Proof point · Ocorian
300+
fund specialists

Ocorian moved global fund and investor operations onto Next Matter, replacing manual, spreadsheet- and email-based coordination rather than launching a multi-year platform programme. More than 300 fund specialists now run client operations on it, with their own teams configuring and adapting workflows. Read the case study

05 · What to look for

Five questions to ask before you sign

If you're running a selection process to replace a legacy workflow, BPM, RPA or low-code platform in regulated operations, these five questions do more work than any feature matrix.

1
Show me our change, made by our ops lead, in this session. Not a demo environment built by a solutions engineer last week.
2
Is maker-checker native or a pattern we implement? If the answer includes the word "template," it's a build item.
3
Export the audit trail for a completed case, now. Inputs, system calls, approvals, timestamps, versions. If it takes a report to be written, you don't have one yet.
4
What data has to move? Every record the new platform insists on owning is migration risk you were trying to avoid.
5
Who is on the hook a year from now? If the honest answer is "engineering," you have bought the same problem with a new implementation cost.

Replacing the platform is the easy part, and it's the part every project gets right. The hard part is refusing to rebuild the same dependency on the way out. Pick the option where governance ships as behaviour, where your ops team owns the process, and where your existing systems stay exactly where they are.

Migration isn't the fix. Changing who can safely change the process is.

For the short version of this argument, see our answer page on replacing a legacy workflow platform for regulated operations.

Keep reading

Test your hardest process against the replacement test

A working session with our team, on a real workflow you'd otherwise migrate.