What Gets Presented to Leadership — and What Is Left Out
When infrastructure teams bring a mainframe offload proposal to a CTO or board, they typically present a comparison of two destination states: the cost of running the current platform versus the projected cost of the proposed alternative. The comparison is usually compelling. The distributed alternative looks cheaper, more modern, and better aligned with where the industry is heading.
What is almost always missing from that comparison is an honest account of the transition itself — the cost of getting from the current state to the destination state, the time it will take, and what the organisation is paying while the transition is in progress.
I have spent years advising C-suite leaders on strategic platform investment decisions across government and defence environments. The pattern I see most consistently is not technical failure — engineering teams are generally capable. The pattern is a gap between what leadership is shown and what the evidence actually supports. That gap, left unexamined, has derailed major programmes, consumed budgets that were committed to other priorities, and in some cases resulted in organisations reversing course and returning to the platform they had tried to leave.
The decision I want to walk through here is one I was brought in to advise on for a national Department of Defence. The specific department is not mine to name. The lessons are.
The Question That Reframes the Decision
The Department’s existing mainframe infrastructure had reached end of life. Hardware that had served mission-critical functions across the defence enterprise — HR, financial management, medical systems, supply chain, and operational applications — for years could no longer be upgraded. A decision was required, and there was political appetite within the leadership team to use the refresh as an opportunity to modernise the platform entirely.
My first question to the leadership team was not about the destination. It was about the journey.
Specifically: how long will the transition take, and what are you paying while it is underway?
These two questions consistently produce the most important numbers in any infrastructure migration decision, and they are consistently the numbers that receive the least rigorous treatment in the proposals that reach executive level.
The answer, when properly developed for this organisation, reframed the entire discussion.
The Transition That Does Not Fit the Study Window
A responsible evaluation of a migration proposal requires understanding the scope of what is being moved. In the case of a Department of Defence estate that has operated for decades, that scope is considerable: not one application in one language against one database, but dozens of applications spanning multiple programming languages, transaction processing middleware, database platforms, batch systems, and third-party products — each with its own integration dependencies and its own migration complexity.
When a credible, independent methodology was applied to estimate the migration effort for an estate of this size and complexity, the output was not what the initial proposal had assumed. The migration would not complete within the five-year period that the cost comparison was modelled against. It would take considerably longer — closer to a decade, accounting for realistic productivity assumptions, the proportion of code that code generators could not handle, and the validation requirements for systems that genuinely cannot fail.
This is the finding that changes everything. A five-year cost comparison that assumes migration is complete by year five is not a comparison of two options — it is a comparison of one complete option and one incomplete option, evaluated as though they were equivalent. It systematically understates the cost of the migration path.
The question this raises for any CTO reviewing such a proposal is not whether to trust the destination cost projections. It is whether the timeline assumption embedded in the proposal has been tested with the same rigour as the cost projections. In my experience, it almost never has been.
The Costs That Do Not Appear in the Proposal
Beyond the migration timeline, there are specific cost categories that routinely appear in the fine print of offload proposals — if they appear at all — rather than in the headline comparison.
The most significant of these is parallel running cost. During a migration of this complexity, the organisation cannot switch off the existing platform until each workload has been successfully migrated, tested, and validated in the new environment. That process takes years. During those years, the organisation is paying for both platforms simultaneously: the legacy environment to keep mission-critical systems operational, and the new environment to run what has been migrated so far. In a Department of Defence context, where zero downtime on operational systems is not a preference but a national security requirement, the validation burden alone extends this period significantly.
For the organisation I was advising, the parallel running cost was substantial — not a rounding error, but a material component of the total cost that fundamentally altered the comparison when included. Combined with the migration services cost and the disaster recovery infrastructure required for the distributed environment from day one, the full picture looked very different from the initial proposal.
The question for any leader reviewing an infrastructure migration proposal: ask your team to show you the parallel running cost as a standalone line item. If it is not there, it has either not been modelled or it has been absorbed into a general contingency that obscures its magnitude. Either way, you do not have the full picture.
Why Complexity Is Not Linear
One of the most consequential misunderstandings in executive discussions about infrastructure migration is the assumption that complexity scales roughly with size. A larger estate takes longer and costs more than a smaller one — but the difference is one of degree.
In practice, software complexity in long-lived enterprise environments does not scale linearly. It compounds. Each additional programming language in the estate adds not just its own migration workload but a new layer of integration dependencies with everything else. Each additional data platform adds testing surface. Each additional third-party middleware product adds a replacement mapping exercise. The organisations that have successfully migrated smaller, simpler mainframe estates — typically running a narrow software stack against a single workload type — have not thereby demonstrated that the same approach will work for a heterogeneous, multi-decade environment.
The cases I have seen where migrations were abandoned — with significant expenditure written off and leadership accountability enforced — were not cases where the engineering was poor. They were cases where the complexity of the estate was not honestly understood at the point the programme was approved. The proposal was built around the simpler estates that had worked. The organisation’s estate was not one of those.
For the CTO, the right question is not “has anyone migrated from a mainframe successfully?” — the answer to that is yes, in specific contexts. The right question is “does our estate resemble the contexts where that has worked, and if not, what would an honest projection look like?”
The Outcome of Honest Analysis
When the full picture was visible to the organisation’s leadership — the realistic migration timeline, the parallel running costs, the disaster recovery requirements, the software complexity — the comparison changed. Upgrading to current mainframe technology delivered comparable costs to the offload options over the same period, with the critical advantage that the upgrade included full disaster recovery capability the existing configuration lacked, and capacity for workload growth the existing hardware could not accommodate.
The decision to invest in the platform — rather than migrate away from it — was made with confidence, not defensiveness. That distinction matters. Leaders who are talked out of a modernisation path without understanding why tend to revisit the question at the next cycle. Leaders who understand the evidence make a committed decision and move forward.
The Department subsequently invested in new mainframe infrastructure. That investment is still running the systems it was designed to run — the HR, financial, medical, and operational applications that a functioning defence enterprise depends on.
Three Questions Every CTO Should Ask
I work with executive leaders to build the analytical foundations and narrative frameworks that turn complex infrastructure decisions into confident, defensible commitments. Over time, three questions have proven consistently valuable at the point where a major platform proposal is under review.
What is the migration timeline, and what assumption underlies it? A credible timeline is not a project plan. It is an estimate grounded in the actual scope of what is being moved, validated against comparable migrations of equivalent complexity. If the proposal does not show you how the timeline was derived, it has not been derived — it has been assumed.
What are we paying while the migration is underway? Parallel running costs, migration services, and the disaster recovery requirements of the new environment during transition are the three categories most likely to be underrepresented. Ask to see each as a standalone figure, not buried in a contingency or omitted from the headline comparison.
Does our estate resemble the cases where this has worked? Reference to successful migrations elsewhere is only useful if the reference cases are genuinely comparable. Scope, software diversity, operational continuity requirements, and the consequences of failure are all dimensions on which your estate may differ from the examples being cited.
The right infrastructure decision for a mission-critical environment is rarely the one that looks most modern in a slide deck. It is the one that holds up when the full picture is visible — timeline, transition costs, complexity, and risk all included. Getting to that full picture is what executive advisory support is for.
