Fewer modernization initiatives fail because the technology doesn't work than most leaders assume. That's how a recent Devsu webinar opened, hosted by Matt Deaton with CTO Alvaro Lopez and CEO Felipe Cornejo as speakers, built around a question most banking technology leaders have lived through at least once: why do modernization initiatives struggle before an engineering team writes a single line of code? [LINK: webinar recording] 

We've already published three deep dives from that session: on why modernization budgets explode, on architecture drift, and on what bank examiners already expect. This one pulls back to the five things worth taking away from the full session. 

1. The failure is usually understanding, not technology 

Fewer modernization initiatives fail because the technology doesn't work than most leaders assume. The more common failure is an organization that doesn't fully understand the system it's trying to change, something that only becomes visible once the work has already started. 

Felipe shared a case that shows what that looks like at scale. The UK's Co-operative Bank started a core replacement project estimated at about £180 million. Two years later, the estimate had grown to £460 million. Two years after that, an outside party doing due diligence on an unrelated deal put the real number at £1.8 billion. The bank eventually cancelled the project and wrote off £300 million. Its ability to execute never changed. What changed was what it knew. 

2. The loop: understand, prioritize, execute, measure, improve 

Rather than opening with a roadmap, Alvaro described a five-step cycle. First, build an evidence-based picture of the environment from source code, infrastructure, telemetry, and the people who run it. Second, prioritize based on risk, cost, security exposure, and business value, not simply which system is oldest. Third, execute in increments small enough to learn from. Fourth, measure the result against concrete indicators. Fifth, feed what you learned back into the next cycle. 

The goal shouldn't be to reach some perfect final architecture. The goal should be to make the architecture easier and safer to change. 

3. The core doesn't have to go first 

There's a strong instinct to treat core replacement as the definition of "real" modernization. But the biggest modernization challenges usually aren't inside the core. They sit in the systems around it, and because the core is connected to all of them, it's one of the highest-risk places to start rather than the natural one. Modernizing the systems around it, channels, pipelines, internal applications, first creates cleaner boundaries. If replacing the core still makes sense afterward, that decision gets made from evidence instead of urgency. 

4. Incremental beats big-bang, because it produces feedback 

A large transformation program carries every assumption made at the start all the way to the end, often years later, before anyone finds out which of those assumptions were wrong. Incremental modernization surfaces that feedback continuously: change something, observe what happens, apply it to the next decision. That is a meaningfully different risk profile, not just a smaller version of the same plan. 

5. Modernization doesn't have an end date, and that's the point 

The session's clearest reframe: modernization isn't a program you finish, it's a capability an organization builds. That means continuous visibility instead of rediscovering the architecture every five years, continuous prioritization as the environment changes, incremental delivery so value never waits for year five, and feedback, where every change teaches you something that shapes the next decision. Put those four together and modernization stops being a project with an end date and starts being how the organization operates. 

Put together, these five points describe a fairly different posture than most modernization pitches take. Nothing here argues against ambition. It argues for sequencing: build the understanding first, prioritize on evidence instead of instinct, and treat every increment as a chance to learn something that improves the next one. That's a slower-sounding plan on paper. In practice, it's usually the faster one, because it's the version that doesn't get derailed by a discovery nobody saw coming twelve months in. 

Three questions to ask next 

Felipe closed the session with three questions any banking technology leader can take back to their team: 

1. Do we actually know what depends on our most critical systems? 

2. Which modernization decisions are we currently making based on assumptions rather than evidence? 

3. Are we running modernization as a temporary program, or are we building the capability to continuously change our technology safely? 

If any of them is hard to answer with evidence, that's where to start. Devsu's Modernization Diagnostic is built for that first step. 

Request your Modernization Diagnostic