There is a moment that appears in many modernisation efforts, and it is quieter than people expect.
A team has done the right things. They have identified a legacy area, discussed boundaries, chosen a stack. The bright future feels closer again. Then reality begins to bargain with the plan. A feature needs shipping. A partner wants an integration. Someone notices the old system already does most of what is needed — the rules are ugly, yes, but they exist. The edge cases are buried, but they have been survived before.
So the rational short-term decision gets made. Once, then twice, then repeatedly. The new architecture remains aspirational while the old one keeps absorbing the real business.
This is what I think of as the capability trap.
Legacy is where the business has been hiding
Legacy systems do not survive simply because organisations are conservative, or lazy, or short on technical imagination. They survive because they already know too much.
Over time, business capability settles into old systems in places nobody intended. A pricing rule lives partly in a workflow, partly in a controller, partly in a CRM customisation, and partly in the memory of the one person who knows when and how to override it. A customer process spans status fields, manual back-office conventions, downstream side effects, and one exception path nobody dares remove because it still matters for a small but important channel.
The legacy system becomes more than software. It becomes a compressed historical record of what the business has learned, improvised, tolerated, and failed to document. That is why greenfield work can be so deceptive. On a whiteboard, the new service looks cleaner because it contains only the intended model. In production, the old system keeps winning because it contains the actual one.
That is the trap: every rational local decision strengthens the irrational global outcome.
Organisations say they want modernisation while continuing to route urgency through the place where capability already exists. The legacy system becomes both the reason change is painful and the default answer whenever change must happen quickly.
You are not extracting code. You are disentangling meaning.
Architecture discussions can make decomposition sound cleaner than it really is. Find the bounded contexts. Extract services. Reduce coupling. All sensible. But the friction starts when you ask a less glamorous question:
What exactly is the capability we are extracting?
What business outcome does this part of the system enable? Which exceptions matter? Which downstream processes depend on its current behaviour? Which dependencies are real, and which are historical barnacles?
I’ve been in rooms where this question deflated an otherwise confident design session. “Customer onboarding” turns out to contain identity resolution, compliance checks, sales workflow, contract setup, document generation, and years of channel-specific compromise. “Billing” turns out to be several overlapping realities forced through one operational bottleneck.
Once you see that, the problem changes. You are no longer extracting code. You are disentangling meaning.
The extraction tax
One of the more painful lessons in modernisation is that extraction often increases complexity before it reduces it.
A domain moves into a newer service. It gets better code, clearer ownership, its own data store, cleaner deployment. Briefly, everyone feels progress. But the surrounding consequences remain in the old world. Reports still read legacy structures. Back-office users still depend on operational views that were never redesigned. Integrations still pass through old intermediaries because changing them was “out of scope.”
I’ve seen this happen multiple times. When it does, the new service stops feeling like progress. It feels like a second place where the organisation must now understand the same domain — and a second place where things can go wrong.
I think of this as the extraction tax. The solution is not to avoid extraction, but to plan deprecation from the start. Not as a follow-up item. From day one. Which old touchpoints disappear, and when? Until that question has an answer, the new service is less a simplification than an addition.
The sequence matters: domain modelling first. Capability extraction second. Deprecation planned from the start. Miss one of those steps and the old system rarely gets weaker. You just spread the ambiguity across two worlds instead of one.
A heuristic I trust more now than I did a few years ago
Before you replace a legacy component, ask what capability the organisation is currently outsourcing to its existence.
Sometimes the answer is obvious: rate calculation, document generation, identity synchronisation. More often, it is less comfortable. The old system is not only generating documents. It is the place where five teams quietly reconcile inconsistent assumptions. It is not only storing account data. It is acting as the accidental negotiation layer between sales, operations, finance, and support.
Once you see that, modernisation looks different. The problem is not only how to build the replacement. It is how to make the capability explicit, give it a proper home, and create enough organisational clarity that the new system is allowed to become the default path for future change. A new architecture does not win by existing. It wins when the organisation is willing to route real business through it.
The capability trap is not that legacy systems are old. It is that they already contain the organisation’s answers — however messy — to questions the new architecture has not yet learned to answer under pressure.
Modernisation starts to move when we stop asking only, “How do we decompose this system?” and ask the more demanding question: what has this system been doing for the business that nobody has properly named yet?
That is a less glamorous place to start. But it is more honest. And in architecture, as in archaeology, honest maps are worth more than elegant guesses.