It’s a familiar pattern: a legacy application gets replatformed — rehosted in the cloud, rewritten in a modern framework, given a new interface — and eighteen months later the business runs at roughly the same speed it did before. The technology changed. The outcomes didn’t.

Same process, newer wrapper

This happens because most modernisation projects treat the system as the thing to fix. But a system is usually just the current implementation of a process, and the process — the approval chain, the manual handoff, the batch cadence inherited from a constraint that no longer exists — is what actually determines how fast work moves. Migrate the platform and keep the process, and you’ve bought a faster way to do the same slow thing.

The job versus the system

It helps to separate what a system exists to do (the job: approve a claim, provision an account, route a request) from how it currently does it (the system: this specific sequence of steps, screens, and sign-offs). Most legacy constraints live in the second category — built for a limit that’s long gone — but modernisation projects are usually scoped against the first, which is why replacing the system so rarely changes the job.

A different diagnostic

Before committing to a replatform, it’s worth asking questions that have nothing to do with the technology stack:

  • Which steps in this process exist only because of a limitation the current platform no longer has?
  • Who actually consumes the output at the end, and would they notice if three of the steps disappeared?
  • If this job were designed today, with no legacy system in the picture at all, would it look anything like this?

What modernising well looks like

Done well, modernisation leaves you with a different shape of work — fewer handoffs, clearer ownership, decisions made closer to where the information is — not just a different technology underneath the same shape. The platform work is often necessary. It’s rarely sufficient on its own.