For the program that has not yet been approved
Modernise Legacy Systems
A CIO does not lack the technical playbook for modernising an old system; the harder call is whether the organisation can commit to a multi-year program and survive contact with it. This practice sits above any single rebuild: the business case, the sequencing across a portfolio, and the governance that keeps the company running while systems change underneath it.
The decision above the rebuild
Building the business case, sequencing a portfolio and governing a program in stages.
90 secSample frame · video pending01Before a single system gets touched
Committing to a program is a governance decision, not an engineering one.
Executives often wait for a perfect technical plan before committing, when the real blocker is usually governance: who approves what, and when the business can safely stop.
What does another year of standing still actually cost?
Delay has a price even when nobody has calculated it. Naming that number is usually what unlocks the budget conversation.
Can the board approve this in stages?
A single enormous ask invites a single enormous no. A staged program lets the board approve the next stage on evidence.
Who owns the decision to stop a stage?
Without a named owner, a struggling stage drifts rather than getting stopped, which is how programs quietly become expensive failures.
What would a reversible failure actually look like?
Every stage should have a defined point of no return, known in advance rather than discovered under pressure.
| Single large program | Staged, governed program | |
|---|---|---|
| Approval | One large commitment upfront | Approved stage by stage on evidence |
| Risk exposure | Concentrated across the whole effort | Bounded to the current stage |
| Business disruption | Hard to predict until underway | Managed with a reversibility check per stage |
| Board visibility | Infrequent, high-stakes updates | Regular, evidence-based reporting |
02Agreed before the first stage gate
The ledger that keeps the program honest
Modernisation programs stall when governance and technical execution get tangled together. This ledger fixes what you bring, what the program owns, what returns to the business, and what stays an executive decision at every stage.
- Your side
You bring
- The systems everyone already complains about, named plainly
- The cost of standing still, even if nobody has priced it yet
- The board or executive appetite for a multi-year commitment
- Our side
We build
- A costed case for committing, including the cost of not committing
- A staged program shape instead of one large, undifferentiated ask
- A governance model naming who approves each stage gate
- Your side
You receive
- A board-ready business case with the risk stated honestly
- A staged program plan the executive team can approve in pieces
- A defined point at which the program can stop without loss
Never leaves you
- The decision to commit, delay or decline the program
- Budget authority and the pace of every stage
- The right to stop after any completed stage
Where the line sitsThe honest answer is sometimes not yet. This decision earns a straight business case either way, not a program pitch dressed up as one.
03From an unpriced risk to a governed program
Four stages, each closing on evidence
Programs that stall usually skipped one of these stages. Each one closes with something the board can act on before the next commitment is asked for.
Build the costed case for committing
Aging systems, their risk exposure and the cost of delay are assessed together into a business case the board can act on.
The real cost of standing still, namedSequence the portfolio by business risk
Systems are ranked by what actually threatens the business first, producing a roadmap owners can see themselves in fairly.
A sequence based on risk, not politicsStand up program-level governance
Stage gates, reporting lines and reversibility checks are established before the first system's technical work begins in earnest.
Governance running above the technical workRun the program on staged delivery
Each stage delivers a measurable result and a genuine stop point, so the business sees progress well before the program concludes.
Value shipping every quarter, not just at the end
04What actually moves the number
Four drivers, priced from the portfolio
Program pricing follows portfolio size and governance complexity, never one flat rate. These four factors set the shape of the cost.
Size and age of the portfolio
A handful of critical systems costs less to sequence and govern than an estate spanning dozens of aging applications.
Board and governance complexity
An organisation with several stakeholders and approval layers needs more structured governance than one with a single accountable executive.
Risk tolerance and reversibility requirements
A lower tolerance for disruption raises the cost of parallel running and rollback capability built into every stage.
Number of systems requiring simultaneous attention
Sequencing systems one at a time costs less than a portfolio where several systems are failing on the same timeline.
05Evidence and proof
Programs that kept the business running throughout.
Program proof is a board that approved the next stage on evidence, and a business that never noticed the transition underneath it. These previews carry that standard while written client approvals are collected.
Explore case studiesA four-system portfolio sequenced by risk instead of politics.
Nexa Foundry had four aging systems and four owners, each certain theirs came first. A risk-ranked sequence gave the board a roadmap every owner could accept.
- Systems sequenced
- 4
- Board approval
- Granted on the first review
A business case that turned a stalled conversation into a budget line.
Pillar Learning had discussed modernising for two years without committing. A costed case naming the price of delay finally moved the program into a funded stage plan.
- Years the decision had stalled
- 2
- Time to a funded first stage
- One budget cycle
The board finally approved something because it could say yes to a stage, not a decade.
Sample · pending client approval
06Read this first
When program-level governance is the wrong move
Committing to portfolio governance before the business case is made wastes executive attention on a program that may not survive its first board review. The exits are marked plainly. When the program is justified, its technical execution runs through the modernisation practices built for exactly that work.
- Application Modernization
Only one system actually needs modernising
A single aging system does not need portfolio-level governance; it needs the technical practice scoped to that one system.
- Legacy Modernization
The technical approach is already the open question
If the business case is settled and the question is re-platforming, decomposing or rescuing a system, that belongs to the technical practice.
- Team extension
You need governance capacity, not a rebuild
If your team already runs the technical work and the gap is program oversight, embedded governance capacity fits better than a rebuild engagement.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Business case only | The commitment itself is still undecided | What happens with the findings | A costed case and a staged shape |
| Program governance | Multiple systems need sequencing and oversight | Sequence, budget and risk appetite | Governance, reporting and stage gates |
| Technical execution | The program is approved and sequenced | Priorities within each system | Delivery, handled by the modernisation practices |
07Straight answers
Asked before a modernisation program gets approved.
01How is this different from your legacy modernization practice?
That practice executes the technical rebuild once a program is approved: decomposition, re-platforming or rescue work on the systems themselves. This page is the decision layer above it, covering whether to commit and how to sequence a portfolio.
02How is this different from application modernization?
Application modernization scopes and rebuilds one specific system as its own bounded project. This page addresses the portfolio and governance question that usually comes before any single system gets chosen.
03Do we need a business case before talking to you?
No, building that case honestly, including the cost of not modernising, is often the first deliverable. Many programs start here precisely because the case does not exist yet.
04How do you sequence which system modernises first?
By ranking business risk and criticality across the whole portfolio, not by which owner argues loudest. The system most likely to fail first usually belongs first in the sequence.
05Can the program stop partway through?
Yes, by design. Every stage has a defined stop point and delivers value on its own, so halting the program never discards the investment already made.
06What does program-level governance actually involve?
Stage gates, risk reporting and a reversibility check before each stage proceeds, sitting above the technical delivery teams. It exists to surface a problem before the business finds it.
07What does this cost?
A standalone business case is priced small and fixed. Ongoing program governance is priced against portfolio size and the number of systems requiring simultaneous oversight.
08Who should be in the room for this conversation?
Whoever owns the budget decision and whoever will answer for the risk if it goes wrong. That is typically a CIO alongside financial and operational stakeholders.