There’s a special kind of optimism that only appears at the start of a renovation. It’s the moment you stand in a perfectly functional kitchen, point at a few tired cabinets, and say something like,
“How hard can it be?”
In banking, that optimism shows up in PowerPoint form. It is usually a neat diagram that says Blue → Green, with a confident arrow and a heroic go-live date. It suggests that if we just build the new thing carefully enough, and test it thoroughly enough, we can make the old thing disappear on a single weekend. Then on Monday morning,
everyone turns up,
logs in,
and wonders what all the fuss was about.Reality, unsurprisingly, has other plans.
Because the core is never just “an application”. It’s plumbing,
electrics,
load-bearing walls,
and twenty years of duct tape hidden behind cupboards.The modernisation effort is rarely defeated by code in isolation. It gets defeated by time, uncertainty, and the sheer awkwardness of keeping the bank alive while you replace its organs.
When people talk about core modernisation, they tend to circle around three main approaches. They often use different names, and vendors tend to describe whichever one matches their product strategy as “best practice”, but the patterns are recognisable. Each comes with real benefits, real disadvantages, and a particular kind of risk that is easy to underestimate until it is sitting on your desk at 03:00.
Let’s walk through them properly, in plain language, without pretending the bank can stop being a bank while we rebuild it.
The Big Bang: Build the Whole New Kitchen, Then Move In Overnight
This is the approach most people imagine first, because it makes intuitive sense. If the old kitchen is the problem, then the cleanest solution is to build a new kitchen. Not a renovated kitchen. A new one. Full replacement. Shiny cabinets, modern appliances, fresh wiring, proper plumbing, no mould behind the skirting boards.
Translated to banking, you build the “green” core as a full replacement for the “blue”. You design, engineer, configure, integrate, and test until you believe the green environment can run the entire bank. You run the full procession of test phases. You create a migration plan. You rehearse cutovers. You do dress rehearsals of dress rehearsals. And then you do the actual cutover.
On paper, it feels disciplined.
It feels safe.
It feels like control.The problem is not that the approach is inherently stupid. The problem is that it compresses a huge amount of uncertainty into one dramatic moment, after a very long period of assumptions.
Big bang programmes usually have a long stretch where the new world exists mostly in meeting minutes and test environments. The bank carries on evolving in the meantime. Regulation changes. Product teams change pricing. Fraud patterns shift. The business tries new partnerships. The security team introduces new controls. People leave and new people arrive. And somewhere in that churn, the modernisation programme has to keep up, while still trying to hit its grand cutover date.
That is where the approach starts to rot from the inside.
Because once the programme gets long, the bank does not stand still. And the programme doesn’t just have to build a new core. It has to build a new core while constantly rebuilding parts of it to reflect a bank that is already moving on.
You also end up with a peculiar kind of “testing confidence” that I’ve learned to treat with suspicion. It is entirely possible to test a big bang core replacement to death and still discover the real system behaviour only when you hit production, under real load, with real customers doing the messy, unpredictable things customers do. That isn’t because teams are incompetent. It is because the bank is not a lab environment. It is a living organism. And the first time you truly run the whole organism on the new heart is when it either works, or it doesn’t.
The commercial profile (time, ROI, and the honest balance sheet)
Big bang is the approach that most often produces the most dangerous ROI narrative.
The business case usually leans on long-term savings and future agility. But the investment curve is front-loaded, and the benefits are back-loaded. For a long time, you are spending heavily while customers see very little. That creates pressure to “show progress”, which often results in cosmetic wins that don’t materially de-risk the cutover.
Time-to-market is the obvious casualty. If your bank needs to respond quickly to market or regulatory change, a long build-and-wait phase can become a competitive self-harm strategy.
And there’s another uncomfortable element. The longer the programme runs, the more value evaporates through what I call strategic drift. You build for a bank that existed when you started, and you go live in a bank that has already moved on.
Where big bang can still be the right choice
Sometimes you really are boxed in. Sometimes the legacy platform is so constrained, the vendor path so fixed, or the operating model so resistant to dual-run complexity, that trying to do coexistence would be even more dangerous than a single cutover.
But if you choose big bang, you should be honest about what you are buying: a clean end state, at the cost of concentrated cutover risk and a long period of delayed value.
If you tell yourself it is “the safest approach”, you will design it with the wrong psychology.
Progressive Migration: Still Dual Core, But You Cut Over in Slices
The second approach looks similar at first glance, and this is where language matters. People sometimes describe it lazily as “big bang, but phased”. That is a misunderstanding. If you treat it as big bang with smaller steps, you will still fall into the same traps, just with more moving parts.
Progressive migration accepts a basic reality.
You do not need to move the whole bank at once. You can move slices. You can migrate by product line,
by segment,
by region,
by journey,
by domain.
You can start small, learn, improve your method, and then expand.In kitchen terms, you are not tearing the whole thing out and living on takeaway for two years. You are replacing the appliances and the cabinets in stages.
Annoying? Yes.
Messy? Absolutely.
But at least you can still make coffee.The benefits are real. You reduce the blast radius of each cutover. You can test under real conditions earlier. You start to learn where your assumptions are wrong while there is still time to correct them. And, crucially, you can begin the process of actually decommissioning parts of the old world earlier, rather than carrying all the legacy cost right up until the end.
But the price you pay is also real, and it is mostly paid in coexistence complexity.
The moment you run two worlds in parallel, you introduce a set of questions that a big bang programme can postpone.
They become immediate.
They become operational.Which system is the source of truth for this data element?
Which system is authoritative for this event?
How do we ensure that a transaction executed in green can be traced, reconciled, and audited in the same way as one executed in blue?
What is the stable accounting interface to the general ledger while we progressively shift the origins of postings behind that interface?If those questions sound like finance and control rather than technology, that’s because they are. And they are usually the questions that separate “a nice modernisation story” from “a bank that can still close its books”.
This is where progressive migration can quietly fall apart. If teams are vague about source of truth, they create two versions of reality. If they allow dual-write as a convenience, they build a time bomb. If they treat coexistence as a temporary inconvenience rather than a designed discipline, they produce an integration layer that slowly becomes the new duct tape.
There is one nuance I want to make explicit, because it is a common misunderstanding and it matters to your framing.
Progressive migration does not have to mean “build the full green duplicate first”. Some programmes try that, and occasionally it makes sense, particularly when the bank insists on broad functional equivalence before moving anything critical. But if you wait for “complete green” before you move real workloads, you often recreate the long dead period of big bang, just with a different label.
A stronger pattern is to build enough green to host the next slice safely, then move it, then expand. That is not an agile slogan. It is a risk control mechanism. It reduces the time you spend validating assumptions in a sealed environment.
The commercial profile (time, ROI, and the cost of the hybrid)
Progressive migration usually improves time-to-value compared to big bang, but it introduces a different business-case reality. You are paying for a hybrid estate.
For a while, you are funding two operational worlds with two sets of controls, incident patterns, monitoring, releases, reconciliation routines, vendor relationships, and sometimes even duplicated capability teams.
That hybrid cost can be worth it and often is, because you are buying risk reduction and learning. But it needs to be priced honestly. I’ve seen too many business cases pretend dual-run is a short “transition” and then quietly accept a three-year hybrid reality as normal. Or in the case of a large Nordic bank, accept that this is the new normal as the program failed to deliver on the migration scope.
The ROI logic works best when the bank can actually retire legacy progressively. If the legacy estate is politically protected, contractually locked, or culturally untouchable, progressive migration can degenerate into “green growth” without “blue reduction”. That is when the CFO starts asking why the modernisation programme is increasing run costs rather than decreasing them.
So the success condition is not “phased cutover”. The success condition is “phased cutover with ruthless decommissioning”.
Progressive Modernisation: Start Renovating in Waves From Day One
The third approach sounds similar to progressive migration, and that is because they share a core idea.
Coexistence and controlled movement.
The difference is not that one is “phased” and the other isn’t. The difference is what you treat as your primary unit of progress.
Progressive modernisation is not “let’s migrate faster”. It is “let’s modernise by capability, and only migrate what we need, when we need it, as part of building the future bank”.
In practice, this means you stop thinking in terms of “replacing the core system” and start thinking in terms of building the platform and capability spine that allows the bank to run differently. You deliver slices early, but those slices are not random. They are anchored in a target capability model and a target architecture. They exist because you have defined what the future bank needs to be able to do, and you are building that ability incrementally.
This is the approach that fits the “renovate while living in the house” metaphor properly. You start replacing plumbing and wiring in the sections that matter first, with a clear plan for how the house will function when it is done. You do not try to recreate every strange quirk of the old kitchen in the new one. You decide what you are keeping, what you are replacing, and what you are removing because it never should have existed in the first place.
The advantage here is speed to meaningful change. You can start delivering real value earlier. You can reduce the programme uncertainty that builds up over time. You can avoid the trap of rebuilding the old bank in new technology, which is one of the most expensive ways to achieve no meaningful transformation.
But you pay upfront in discipline.
Progressive modernisation is not forgiving. It requires operational maturity early. It requires clean engineering practices, strong observability, and an acceptance that “production” is not the finish line, it is the learning environment. It requires governance that can say no, because the freedom to deliver in increments can easily turn into a sprawl of half-finished modern pieces that never add up to a coherent bank.
Most of all, it requires coexistence that is treated as the backbone of the programme, not as “integration work” delegated to a team in the basement.
So when people say progressive modernisation is “riskier” because you go live earlier, I tend to push back a little. It can feel riskier because you are exposing new components to reality sooner. But in many programmes, that is exactly what reduces the overall risk. The greatest risk in long transformations is not the first production release. It is the years spent confidently building a future that the bank has already outgrown.
In other words, progressive modernisation moves risk forward in time, where you still have options. Big bang moves risk to the end, where you have none.
The commercial profile (time, ROI, and why this can win when it’s done properly)
Progressive modernisation is usually the best time-to-market option because it can start delivering capability improvements early. That matters, not just for customer features, but for cost and risk reduction. Things like automation, straight-through processing, better observability, reduced incident rates, and simplified integration are all “boring” benefits that show up on the P&L long before a full core replacement ever would.
But the ROI is conditional. If the bank treats progressive modernisation as “build some modern stuff next to the old stuff” without a coherent target and a decommissioning path, it becomes a permanent innovation tax. You end up funding modern capabilities indefinitely while the legacy core still dictates constraints.
The programmes that win here are the ones that treat every wave as both value delivery and legacy run-down. They don’t just add green. They remove blue.
A Necessary Detour: Full Transformation vs Lift-and-Shift Modernisation
The industry, and I, repeatedly warn against treating core modernisation as a purely technical project. If the goal is “new technology” rather than “new capability”, you often end up spending a fortune to land in the same business position, just with a more modern stack.
But there is a category of work that is genuinely worth doing even when it is mostly technical. Moving away from technologies that are becoming unsustainable, unstaffable, unpatchable, or simply too operationally fragile to carry into the next decade.
This is where lift-and-shift comes in, and it is where people either oversell it or dismiss it too quickly.
What lift-and-shift is (in plain kitchen language)
Lift-and-shift is like rewiring the kitchen and replacing the pipes, but keeping the layout the same.
It does not make the kitchen modern in how it functions. It makes it safer, more maintainable, and sometimes cheaper to run. Sometimes that’s exactly what you need.
When lift-and-shift is a sensible choice
Lift-and-shift can be the right move when:
- the current tech stack is becoming a risk in itself (skills, patching, vendor support, hardware constraints)
- the bank needs to reduce operational fragility quickly
- the bank needs time to design the real business-led transformation properly
- the transformation appetite exists, but the organisation cannot absorb a full behavioural change yet
In other words, lift-and-shift can be a stabilisation step that creates breathing room.
The trap: lift-and-shift sold as transformation
The danger is not lift-and-shift. The danger is calling it a transformation and building a business case that depends on benefits it cannot deliver.
Lift-and-shift rarely delivers major agility gains on its own. It may improve deployment mechanics and operational stability, but it usually does not remove the underlying semantic mess, product complexity, or architectural coupling that makes change slow.
So if the bank says, “we’ll lift-and-shift the core and then we’ll be a platform bank,” that is wishful thinking. You might end up with a faster horse. But it is still a horse.
A more honest framing is that lift-and-shift can reduce risk and buy time, but it does not substitute for capability-led change.
The Thing Everyone Mentions But Few Treat Seriously: Coexistence
At this point, it is tempting to say that
big bang is simple but dangerous,
progressive migration is sensible but complex,
progressive modernisation is fast but demanding.That is true as far as it goes, but it still misses the heart of the matter.
In both progressive approaches, coexistence is the transformation.
If you cannot define source of truth with brutal clarity, you do not have a controlled migration. You have two systems producing competing realities.
If you cannot correlate events and postings across blue and green deterministically, you do not have a dual-run bank. You have a reconciliation nightmare.
If your coexistence layer becomes a dumping ground for legacy quirks, you have not modernised anything. You have simply relocated the duct tape.
This is why the most serious modernisation conversations are not really about technology stacks. They are about control.
Financial control,
operational control,
semantic control.
They are about being able to prove, at any point in the journey, that the bank still knows what happened, why it happened, and where it is recorded.Regulators do not give you a temporary exemption because you are “mid-flight”. Your customers do not suspend their expectations because you are “transforming”. And your CFO definitely does not accept “we are migrating” as an explanation for why the numbers don’t reconcile.
So Which One Is Best?
There isn’t a universal answer, and anyone who claims there is, is trying to sell you something.
Big bang can work when the conditions are right, the scope is contained, and the bank can genuinely absorb a concentrated cutover risk. It is sometimes the only practical option when the legacy is so constrained, or the vendor path is so fixed, that coexistence is more dangerous than cutover.
Progressive migration is usually the most credible middle ground for large incumbent banks. It reduces the blast radius, creates learning loops, and allows gradual retirement. But it only works if the bank treats coexistence as a product, not a project task, and if it budgets honestly for the hybrid period.
Progressive modernisation is the approach that aligns best with the idea of a coreless future, because it shifts the focus from replicating the old bank to building the future bank. It can deliver value sooner and reduce long-term uncertainty, but it demands a level of delivery discipline and governance that some organisations do not yet have. If you choose it, you are not just changing the core. You are changing the bank’s relationship with change itself.
And lift-and-shift sits underneath all of this as a separate axis. A technical stabilisation move that can be wise, but that must not be sold as business transformation unless it is paired with a capability-led roadmap.
And whichever route you choose, the real question is not “how do we build green?”
The real question is:
How do we keep cooking while the plumbing is being replaced, without poisoning the family?
That is the job. That is the craft.
And that’s why so many core modernisation programmes fail. Not because they don’t know how to build a new kitchen, but because they never truly learned how to renovate one while living in it.Stay tuned for more insights on this journey. In my book Rip Out the Core, A Practical Path to Coreless Banking, I dive deeper into the methods and real world examples of making this transition. Until then, keep questioning the old assumptions and imagine what your bank could do when it’s freed from the chains of a monolithic core.
Rip Out the Core, or Renovate It While You’re Cooking?
