When I first stepped into enterprise architecture leadership, I expected modernization to unlock capacity and enable growth. We had a roadmap, a cloud architecture we believed in and sponsorship from the business. Teams were upskilling, new engineering practices were being introduced and the target platform was already delivering value in a few isolated areas.
On paper, the strategy was sound. In reality, the results did not show up the way we expected.
Delivery speed wasn’t improving. Run costs weren’t decreasing. And complexity in the environment was actually growing.
It took time to understand why. We hadn’t replaced the legacy environment. We had added the new one on top of it. We were running two architectures in parallel: the legacy stack and the modern stack. Each required support, compliance oversight, integration maintenance and delivery coordination.
The modernization effort wasn’t failing. It was being taxed by the cost of keeping the old system alive.
Once I saw this pattern clearly, I began to see it everywhere. In manufacturing, banking, public services and insurance, the specifics varied but the structure was the same: modernization was assumed to produce value because the new platforms technically worked.
But modernization does not produce value simply by existing. It produces value when the old system is retired.
The cost of not turning the old system off
Boston Consulting Group highlights that many organizations assume the shift to cloud automatically reduces cost. In reality, cost reductions only occur when legacy systems are actually shut down and the cost structures tied to them are removed.
BCG also points out that the coexistence window — when legacy and modern systems operate in parallel — is the phase where complexity increases and progress stalls.
McKinsey frames this directly: Architecture is a cost structure. If the legacy environment remains fully funded, the cost base does not shift and transformation does not create strategic capacity.
The new stack is not the problem. The problem is coexistence.
Cloud isn’t the win. Retirement is
It’s common to track modernization progress with:
- Application counts migrated
- Microservices deployed
- Platform adoption rates
- DevOps maturity scores
I have used all of these metrics myself. But none of them indicate value. The real indicators of modernization success are:
- Legacy run cost decreasing
- Spend shifting from run to innovation
- Lead time decreasing
- Integration surface shrinking
- Operational risk reducing
If the old system remains operational and supported, modernization has not occurred. The architecture footprint has simply expanded.
A finance view changed how I approached modernization
A turning point in my approach came when finance leadership asked a simple question: “When does the cost base actually decrease?”
That reframed modernization. It was no longer just an engineering or architecture initiative. It was a capital allocation decision.
If retirement is not designed into the modernization roadmap from the beginning, there is no mechanism for the cost structure to change. The organization ends up funding the legacy environment and the new platform simultaneously.
From that point forward, I stopped planning platform deployments and started planning system retirements. The objective shifted from “build the new” to “retire the old.”
How we broke the parallel-run cycle
1. We made the coexistence cost visible
| Cost layer | What we tracked |
| Legacy Run Cost | Hosting, licensing, patching, audit, support hours |
| Modern Run Cost | Cloud consumption + platform operations |
| Coexistence Overhead | Dual testing, dual workflows, integration bridges |
| Delivery Drag | Lead time impact when changes crossed both stacks |
| Opportunity Cost | Innovation delayed because “run” consumed budget |
When we visualized coexistence as a tax on transformation, the conversation changed.
2. We defined retirement before migration
Retirement was no longer something that would “eventually” happen.
Instead, we created the criteria for retirement readiness:
- Data migrated and archived
- User groups transitioned and validated
- Compliance and risk sign-off complete
- Legacy in read-only mode
- Sunset date committed
If these conditions weren’t met, the system was not considered cut over.
3. We ring-fenced the legacy system
- No new features
- No new integrations
- UI labeled “Retiring”
- Any spend required CFO/CTO exception approval
Legacy shifted from operational system to sunsetting asset.
4. We retired in capability waves, not full system rewrites
We stopped thinking in applications. We started thinking in business capabilities.
McKinsey’s research reinforced this: modernization advances fastest through incremental operating-model restructuring, not wholesale rewrites.
This allowed us to retire value in stages and see real progress earlier.
How we measured progress
| Metric | Strategic purpose |
| Legacy Run Cost ↓ | Proves modernization is creating financial capacity |
| Parallel-Run System Count ↓ | Measures simplification |
| Integration Surface Area ↓ | Reduces coordination cost and fragility |
| % of Spend to Innovation ↑ | Signals budget velocity returning |
| Lead Time ↓ | Indicates regained agility |
| Retirement Throughput Rate | Measures modernization momentum |
If cost was not decreasing, modernization was not happening.
What I learned
Modernization becomes real only when legacy is retired. Not when the new platform goes live. Not when new engineering practices are adopted. Not when cloud targets are met.
Modernization maturity is measured by the rate of legacy retirement and the shift of spend from run to innovation. If the cost base does not go down, modernization has not occurred. Only complexity has increased.
If retirement is not designed, duplication is designed. Retirement is the unlock. That is where modernization ROI comes from.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?
Read More from This Article: Stop running two architectures
Source: News