Since releasing Rip Out the Core, one of the most interesting parts has been the feedback and the discussions it has triggered. And one subject keeps coming back, my rather strong view on how banks should think about, analyse and treat legacy as part of a modernisation or transformation. Unsurprisingly, some of those views have created a bit of contention, particularly the argument that legacy should not be allowed to define the future state. So I thought it was worth expanding on that thinking here and explaining why I take that position. This article is the shorter version, of course. If you want the full argument, the method behind it, and perhaps to join the debate properly, I would recommend picking up a copy of Rip Out the Core. 😉
Let me just start with the statement that “Legacy is not automatically bad”
We use the word legacy rather strangely in technology.
In most parts of life, having a legacy is something we aspire to. A family legacy. A cultural legacy. The reputation somebody leaves behind. Knowledge passed from one generation to the next. Even the dictionary definition is broader than the slightly dismissive way we use the word in banking technology: something transmitted or received from a predecessor or from the past.
And banks have plenty of legacy worth protecting.
Decades of accumulated trust. Risk expertise built through crises. Knowledge of customers and markets. Controls that exist because somebody once discovered, usually painfully, why they were necessary. People who understand how the institution really works rather than how the operating model says it works.
Legacy can be an asset.
But inheritance has another characteristic that matters here. You receive it. You do not choose it.
That, for me, is where the word becomes much more interesting in the context of banking transformation. Something can be valuable because we inherited it without earning the right to determine what we build next.
In banking technology we have narrowed legacy until it has almost become synonymous with old IT. The mainframe. The core. The ageing application estate. The integrations nobody wants to touch because the person who built them retired twelve years ago.
Those things matter. I wrote an entire book about them.
But I increasingly think that describing them as the legacy gives them too much importance.
They are part of the legacy.
They are also part of the map.
And the map is not the territory.
The map is useful, but it is still a map
In 1931, Alfred Korzybski presented the idea for which he is still best known:
“A map is not the territory it represents.”
His point was more subtle than the slogan sometimes suggests. Korzybski was not arguing that maps are useless. Quite the opposite. In Science and Sanity, published in 1933, he explained that a map is useful when its structure corresponds sufficiently well with the territory it represents. The problem begins when we confuse the representation with reality itself.
That feels remarkably relevant to the way banks approach transformation.
A typical legacy analysis creates a map.
Applications. Interfaces. Databases. Products. Batch processes. Infrastructure. Dependencies. End-of-life technologies. Vendors. Data flows. Workarounds that began as temporary fixes and somehow became permanent architecture.
All of that work has value.
In fact, once a bank begins changing things, much of it becomes essential. You need to understand dependencies before breaking them. You need to know where data sits. You need to understand which systems support which processes and what happens when one of them disappears.
I devote a substantial part of Chapter 9 of Rip Out the Core to exactly that work. A good legacy analysis is what eventually grounds ambition in facts. It exposes the hidden capabilities, dependencies, product complexity and operational realities that a future-state model alone will never reveal.
The problem begins when that map becomes the starting point for deciding what the future bank should look like.
Because the architecture diagram is not the bank.
The application inventory is not the bank.
The core banking platform is certainly not the bank.
Those are representations of particular aspects of the institution, usually drawn through a technology lens.
And every map leaves something out.
That is not a flaw. A map that contained everything in the territory would be indistinguishable from the territory and rather difficult to fold into your pocket.
The important question is what has been left out.
In a banking transformation, that can be where the real legacy is hiding.
The bank’s deepest legacy is behavioural
The hardest legacy in most banks is not written in COBOL.
It is written in the way the organisation thinks.
It sits in assumptions that nobody remembers choosing.
It appears in a governance process designed for a different technological era. In annual planning cycles that struggle with continuous change. In product structures that reflect how the bank historically organised itself rather than how customers live their financial lives. In procurement models that assume important capabilities must be bought as large systems. In technology teams that instinctively want to build. In business teams that assume technology is somebody else’s problem.
It appears in a sentence every transformation leader eventually hears:
“That isn’t how we do things here.”
This is where Korzybski’s distinction becomes more than a useful metaphor.
The IT estate is one map of the bank’s accumulated history. The operating model is another. The organisational chart is another. The product catalogue is another.
But the territory includes the habits, incentives, beliefs, decision rights, risk appetite, institutional memories and unwritten rules beneath them.
I make this point quite explicitly in Rip Out the Core. In Chapter 2, I describe culture as perhaps the most overlooked and potentially fatal risk in a banking transformation, fear of failure, legacy silos, resistance to change and organisations prioritising their internal structures over customer value. Technology programmes do not simply encounter technical constraints. They run directly into cultural ones. Fixing those requires more than replacing a core. It requires changing how the organisation thinks. (Rip Out the Core, p. 26.)
One page later I widen the definition of legacy further. Banks have to acknowledge that legacy exists “not just in the stack, but in our mindset, the operating model, and the budget committee”. (Rip Out the Core, p. 27.)
That distinction is critically important.
Research into organisational learning has been making a related point for decades. Barbara Levitt and James March described organisational learning as routine-based and history-dependent. Organisations encode lessons from experience into routines, procedures and beliefs which then influence how they behave in the future.
Their idea of the competency trap is particularly relevant to banking. An organisation can become increasingly competent at an inferior way of doing something. Familiarity creates efficiency. Efficiency reinforces use. The newer alternative initially looks harder because the organisation has not yet accumulated the same competence around it.
That sounds uncomfortably familiar.
A bank becomes very good at navigating its own complexity. Specialist teams emerge because the systems are complicated. Governance grows around those teams. Processes adapt to the limitations of the systems. Controls adapt to the processes. Products adapt to the controls. Reporting adapts to the products. People build careers around understanding how the whole arrangement works.
Eventually, the organisation has accumulated enormous competence in operating something it would never deliberately design today.
Then the transformation starts.
And what do we do first?
We map it.
In extraordinary detail.
Where you start changes what you are capable of imagining
This is where my argument becomes uncomfortable, particularly for architects.
The obvious response is:
“How can you plot a journey if you don’t know where you’re starting from?“
It is a reasonable challenge. I hear it almost every time I present this approach, and I address it directly in Chapter 9 of Rip Out the Core.
For many change programmes, starting from the current state is entirely sensible. If you are improving a process, reducing cost or addressing a compliance gap, understanding the current problem is the natural place to begin.
But transformation asks a different question.
If you begin by analysing existing systems, products, processes and constraints, you inevitably start framing future decisions in terms of what already exists. Capabilities become descriptions of today’s functions. Architecture bends around existing dependencies. Product requirements inherit historical exceptions. Sourcing decisions are influenced by contracts already in place.
The current bank quietly becomes the design authority for the future bank.
As I put it in the book, “Legacy has weight.” It has history, people, workflows, contracts and politics. Start there and the options begin to narrow. The conversation moves away from what the bank should become and towards how today’s processes, reports and products can be reproduced somewhere else. (Rip Out the Core, pp. 116–117.)
This is not an abstract risk.
Take something as simple as a mortgage application.
A bank can take its existing paper application, turn it into a web form, request exactly the same attachments, send it into exactly the same back-office queue and proudly announce that the journey has been digitised.
Technically, that statement is true.
But the legacy has defined the answer.
A genuinely transformed mortgage journey might pre-fill information already known about the customer, validate information as it arrives, orchestrate third-party data automatically, dynamically price the product, change the credit decisioning model or embed origination somewhere completely outside the bank’s own channels.
Those possibilities are difficult to see if the first requirement is: make the new thing do what the old thing does.
Chapter 6 of Rip Out the Core describes the same problem through the capability model. Had I designed my new kitchen around its old plumbing, wiring and layout, I would have ended up with what looked like a new kitchen but was structurally the old kitchen underneath.
Banks do precisely the same thing.
Without a future-looking, business capability-led target state, they reproduce legacy functions in modern wrappers. They move account-centric, batch-heavy logic into cloud-native technology and are surprised when the resulting bank remains fragmented and slow.
Or, as I wrote rather more succinctly in the book:
“They replicate the past, forgetting to invent the future.”
Start with what the bank wants to become. Start with the business strategy, the customer and market outcomes that strategy requires, and the capabilities the bank will need to deliver them.
Only then ask how those capabilities should be realised.
Some will be built. Others bought. Increasingly, many should simply be consumed as services. The choice should follow strategic differentiation and business value, not an instinctive desire to recreate whatever happens to sit inside today’s core.
I explore that build-buy-consume decision in detail in Chapter 8. The important point for this argument is that the decision is made against the capability and the future business intent. Legacy constraints enter the conversation afterwards because they affect execution. They should not define the ambition.
Legacy analysis comes later, not never
This is where the argument I make is sometimes misunderstood.
I am not suggesting that banks ignore their legacy.
That would be reckless.
I am suggesting that they stop allowing legacy analysis to define the future.
In the Blueprint approach described in Rip Out the Core, legacy analysis can begin in parallel, ideally independently from the team defining the future state. I even suggest putting a virtual brick wall between the two for a while.
That separation is deliberate.
One group asks “What bank are we trying to become, and what capabilities will that require?“
Another asks “What do we actually have today, how does it work, and where is the complexity hiding?“
Both maps matter. They simply answer different questions.
Once the future-state capability model, strategic intent and architectural principles have been defined, the walls can come down.
Now the legacy analysis becomes enormously valuable because we are no longer asking the old estate what the future should look like. We are asking how the old estate affects our ability to get there.
That changes the conversation.
The legacy becomes a material inventory rather than a blueprint.
Some of it may already align surprisingly well with the future and should be retained. Some capabilities may need replacing immediately. Others can coexist with newer capabilities for years. Some products may be better left on the old platform to run off naturally rather than polluting the new environment with decades of obsolete product definitions and exceptions.
This is where progressive transformation becomes practical rather than ideological.
There is no prize for switching off a mainframe.
There is no intrinsic value in replacing technology merely because it is old.
And there is certainly no rule that says every capability has to move.
What matters is whether the capabilities of the bank are moving towards the future business model.
In Chapter 9, I describe legacy anchoring as a strategic tool rather than an admission of failure. Done deliberately, it can reduce transformation risk, protect customers and keep the future platform cleaner. The capability model remains the guide because, as I put it there, “systems are packaging. Capabilities are value.” (Rip Out the Core, p. 120.)
That also explains why progressive transformation should never be confused with simply replacing the old estate piece by piece.
Progressive describes how we move.
Transformation describes what we are trying to achieve.
Sometimes you should just modernise
There is another side to this argument that I think we need to be more honest about as an industry.
Not every bank programme needs to be a transformation.
Sometimes modernisation is exactly what is required.
Perhaps an infrastructure platform is approaching end of life. Perhaps the cost of running a particular environment has become unacceptable. Perhaps resilience needs improving, specialist skills are disappearing, recovery is too difficult or a platform creates an operational risk the bank no longer wants to carry.
The bank may be perfectly happy with the business capability.
It simply wants that capability delivered on better technology.
That is a legitimate objective.
And in that situation, I would turn much of the argument in this article around.
Start with the legacy.
Understand exactly what the existing system does. Map its interfaces, functionality, data, batch processing, operational behaviour and non-functional characteristics. Determine what must be preserved. Then decide whether the appropriate answer is rehosting, replatforming, refactoring or replacement.
If the explicit goal is to reproduce today’s capability on modern technology, the current estate is the correct starting point because it defines much of the requirement.
But call it what it is.
Technology Modernisation.
And make sure everybody, including executive leadership and the board, understands that this is what has been funded.
That matters because the promised value needs to match the objective.
A technology modernisation programme might be justified through lower infrastructure cost, reduced technology obsolescence, improved resilience and recoverability, better security, easier support, reduced operational risk or a more sustainable skills position.
Those are real and worthwhile outcomes.
What they are not, on their own, is evidence of business transformation.
This distinction appears elsewhere inRip Out the Core. I describe programmes that finish on time, on budget and technically sound while leaving the institution no better positioned competitively than before. They “modernised without evolving”. They upgraded systems, but not capabilities. (Rip Out the Core, p. 53.)
There is nothing inherently wrong with doing that if it was the intention.
The problem starts when a technology modernisation programme is sold to a board as a transformation and loaded with promises of new products, new business models, radically better customer experiences and dramatically faster innovation that the programme was never actually designed to deliver.
Then everybody can technically succeed and still be disappointed.
The technology team can deliver exactly what it committed to. The old infrastructure can disappear. Costs can fall. Availability can improve. The programme can go green on every dashboard.
And three years later somebody asks why the bank itself does not feel very different.
Because nobody transformed it.
They modernised the technology underneath it.
That may have been the right decision. We just need to stop pretending the two things are interchangeable.
The legacy gets a say in the journey
There is a line running through Rip Out the Core that probably summarises my position better than any architecture diagram could.
Your legacy should not get a vote on your future.
That does not mean legacy is irrelevant. Quite the opposite.
Once you know where you are trying to go, you need a brutally accurate understanding of where you are today. Legacy analysis reveals the dependencies, risks, embedded regulatory logic, product complexity, hidden processes and forgotten capabilities that will determine how quickly and safely you can move.
That map becomes indispensable.
It tells you where coexistence will be required. Where a capability can be replaced cleanly. Where migration makes sense. Where leaving something untouched may be the most sensible economic decision. It informs the build, buy and consume choices. It exposes where cultural and organisational change will be harder than replacing the technology.
But it is still a map of where you are.
It should not become a design for where you are going.
Korzybski’s century-old observation therefore feels surprisingly contemporary in a banking transformation.
The map is not the territory.
An application landscape is not a bank.
A core banking system is not a business model.
And replacing everything shown on an architecture diagram will not necessarily transform the institution represented by it.
If you want to modernise the technology, start with the technology. Understand it properly, improve it deliberately and measure the technology outcomes honestly.
But if you genuinely want to transform the bank, start somewhere else.
Start with the bank you want to become.
Then define the capabilities required to make that bank possible.
Only after that should you unfold the legacy map and work out how you are going to get there without driving into a lake that somebody forgot to draw.
That sequencing is one of the central arguments inRip Out the Core. Chapter 6 goes much deeper into defining the future bank and building the capability model without allowing legacy to win by default. Chapter 8 deals with the build, buy and consume choices that follow. And Chapter 9 tackles the part of turning back towards the legacy, understanding it properly, and deciding what deserves to come with you.
Because legacy is not automatically bad.
Some of it may be worth preserving.
Some of it may even be part of what makes the bank successful.
