Stop running two architectures – cio.com

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.
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.
It’s common to track modernization progress with:
I have used all of these metrics myself. But none of them indicate value. The real indicators of modernization success are:
If the old system remains operational and supported, modernization has not occurred. The architecture footprint has simply expanded.
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.”
When we visualized coexistence as a tax on transformation, the conversation changed.
Retirement was no longer something that would “eventually” happen.
Instead, we created the criteria for retirement readiness:
If these conditions weren’t met, the system was not considered cut over.
Legacy shifted from operational system to sunsetting asset.
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.
If cost was not decreasing, modernization was not happening.
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?
John Doss is an enterprise architect and technology strategist passionate about reframing architecture from a documentation function into a decision discipline that shapes how organizations scale. His work centers on designing shared meaning, capability boundaries and governance models that enable autonomy without fragmentation, and on linking strategy, data, operating models and platform design into a coherent whole.

John has led enterprise architecture and modernization initiatives at Novelis and in global consulting practices at Wipro and Tata Consultancy Services, guiding organizations through cloud and data platform transitions, application portfolio simplification and the shift from project-driven delivery to product-aligned operating models. His approach prioritizes clarity over complexity, business language over technical abstraction, and measurable outcomes over architectural theater. John writes and speaks about system coherence, architecture debt and how organizations can move faster by reducing the need to negotiate meaning.
Sponsored Links

source
This is a newsfeed from leading technology publications. No additional editorial review has been performed before posting.