Most programs only do half the math.
Most modernization programs do the first half. They design the destination, deploy the new services, and declare success. The legacy infrastructure keeps running. Duplicate licenses accumulate. Temporary integrations become permanent. The organization pays for two platforms and gets the benefits of neither.
That is addition without subtraction. It is not transformation.
The real work is controlling every operational state between the legacy platform and its complete retirement. That is where the risk lives, where the money leaks, and where most programs quietly stall.
Five lessons from leading that transition on platforms that could not go offline.
1. You Cannot Subtract What You Have Not Measured
Before any architecture decision, the program needs a documented baseline: latency, throughput, error rates, deployment frequency, recovery time, and cross-service dependencies.
Without it, the program cannot prove that the new state is better than the old one. A team deploying twice as often while generating twice the reactive repair work has increased activity, not improved delivery. The 2024 DORA State of DevOps Report added deployment rework rate as a fifth metric specifically because speed measures alone hide that pattern.
During my work modernizing a national digital platform serving millions of users, embedding performance validation into the delivery process contributed to roughly 50 percent improvement in speed and stability. That result meant something only because the starting condition was measured. OpenTelemetry provides consistent traces, metrics, and logs across legacy and modern components simultaneously, making behavioral comparison possible at every stage of the transition.
The baseline is not a pre-project formality. It is the only way to know, at any point in the program, whether addition is actually winning over what remains.
Establish the evidence before changing the system, or the program will confuse motion with progress.
2. The Transition Is a Production Environment
Platforms do not move directly from legacy to target state. For months or years, old and new services run in parallel, routing layers split traffic, data pipelines duplicate, and operational ownership divides between teams supporting the legacy and teams building the replacement.
This coexistence state is where subtraction has not yet happened. It is also where most modernization incidents occur.
The 2018 TSB Bank migration is the clearest documented case. The FCA and PRA fined TSB £48.65 million for failing to organize and control the migration program adequately. The root failures were not in the destination technology. They were in planning, testing, supplier coordination, and transition governance. Roughly 5.2 million customers were affected. TSB did not return to normal operations until December 2018, eight months after go-live.
The strangler-fig pattern reduces large-bang cutover risk but extends the coexistence period rather than eliminating it. Every temporary interface needs an owner, a retirement date, and rollback conditions. A RAID log treated as an operating control, not administrative paperwork, keeps those conditions visible as the platform moves through each intermediate state.
Addition creates the new architecture. Subtraction retires the transition layer. Programs that govern only the destination leave the most dangerous part unmanaged.
Do not govern only the destination. Govern every operational state through which the platform must pass.
3. Dependencies Are the Ledger of What Has Not Yet Been Subtracted
Most programs maintain dependency logs with entries frozen on “in progress” for weeks while downstream plans assume on-time delivery. That is documentation, not management.
Every unresolved dependency is a liability on the subtraction side of the ledger. It delays retirement, extends coexistence, and keeps the legacy burden running longer than the business case assumed.
A material dependency requires an accountable owner, a specific deliverable, a required-by date, and a defined escalation threshold. Dependencies cluster predictably: security approval before infrastructure promotion, data contracts between producer and consumer services, and vendor-controlled environments affecting multiple workstreams.
Backstage, maintained under the Cloud Native Computing Foundation, centralizes service ownership, lifecycle status, and dependency metadata. Visibility, however, is not control. The program must ensure owners are accountable for retirement criteria, not merely listed in a catalog.
A dependency without an accountable owner is not being managed. It is keeping the legacy alive.
4. Slow Decisions Are a Legacy Tax
Every day a decision sits unresolved during coexistence, the organization pays to operate both the old and new environments. That is a legacy tax levied by decision latency.
Governance in large programs frequently becomes status collection: decks, dashboards, steering committees that receive information and do nothing with it before the next meeting. When a workstream stalls because an assumption failed, an architecture choice is unresolved, or a dependency slipped, governance should surface the problem and move it to whoever can resolve it that week, not that quarter.
Delayed decisions prolong temporary integrations, increase duplicated support effort, and allow migration exceptions to become embedded practice. Each one extends the time between addition and subtraction, which is the only period during which the business case is not being realized.
The purpose of governance is not to collect more status. It is to shorten the distance between uncertainty and decision.
5. The Program Is Not Complete Until the Subtraction Is Done
Deploying the new architecture is a milestone. Completing the transformation requires removing what it replaced.
Legacy infrastructure still running, duplicate licenses, parallel release processes, manual reconciliation, and teams staffed around temporary exceptions are all items on the subtraction side that have not yet been crossed off. While they remain, the program has added a new platform without delivering the business case that funded it.
Retirement metrics belong alongside delivery metrics: legacy traffic removed, interfaces decommissioned, infrastructure shut down, licenses eliminated, services with confirmed production ownership. Backstage tracks component lifecycle status and surfaces ownership gaps. DORA metrics confirm whether the new delivery model actually outperforms the old one.
Legacy retirement requires explicit ownership, deadlines, compliance review, and exit criteria. It requires leadership discipline, because organizations frequently declare success at deployment and redirect funding before the subtraction is complete.
A new service creates progress. A retired dependency creates transformation. The difference is the math most programs never finish.
The Equation
New architecture added minus legacy burden removed equals transformation.
Every lesson above is about closing that gap: measuring the starting state, governing the transition, converting dependencies into commitments, accelerating decisions, and continuing until the legacy is actually gone.
The programs that deliver run the full equation. The ones that stall stop at addition and wonder why the business case never materialized.
Platforms that cannot afford to stop require programs that know not to flinch.
Nabeil Sarhan, MBA, is a dynamic technology delivery manager with over 15 years of experience in tech, cybersecurity, and computing scalability. He excels in leading diverse teams and delivering enterprise-class systems across industries such as healthcare, finance, and retail. Nabeil’s passion for solution design, systems architecture, and performance optimization makes him a sought-after consultant. He holds degrees from Harvard, MIT, and Bryant University. Connect with Nabeil on LinkedIn