Your vendor signed you up for a ten-year relationship. Your business needs changed in three.
That gap is where most banking modernisation debt lives. Not in the code itself, but in the vendor contracts that govern it. Long-term agreements with inflexible vendors have left engineering managers in an uncomfortable position: accountable for delivery velocity, but dependent on partners whose roadmaps, escalation paths, and commercial models were designed for a different era.
This guide is for engineering managers who know something needs to change and need a practical framework for making it happen. Not a boardroom strategy deck. A working guide to assessing your current vendor landscape, identifying where the real constraints are, and moving forward without triggering a full-scale transformation crisis.
Why Vendor Lock-In Is a Delivery Problem, Not Just a Commercial One
There's a tendency in banking to treat vendor dependency as a procurement issue. The contracts team handles it. Legal reviews it. The engineering team inherits it.
That framing gets it backwards. Vendor lock-in has direct, measurable consequences for engineering output, and engineering managers are the ones who feel them daily.
McKinsey's research on bank IT spending found that the average number of application vendors at banks increased from 131 to 209 between 2013 and 2022, a jump of nearly 60 percent. More vendors means more integration overhead, more contract management complexity, and more surface area for delivery delays when any one of those vendors is slow to respond, slow to deliver, or slow to support a change request.
The consequences show up in sprint planning. Every new product or compliance requirement routed through a legacy vendor introduces delays that teams have no direct ability to address. According to IDC research cited by Software Improvement Group, banks that fail to modernize could lose over $57 billion by 2028, with 42 percent of that figure representing missed revenue in payments alone. That is not an abstract strategy number. It is the sum of every feature that shipped late, every integration that took twice as long as it should, and every compliance deadline that required a vendor change request instead of an internal fix.
According to FIS research conducted with Oxford Economics, the average financial institution loses $93.6 million per year to operational inefficiencies, payment friction, and rework, much of it traceable to legacy systems and the vendors that maintain them.
For engineering managers, the first step in vendor modernisation is reframing the problem internally. This is not a cost-cutting exercise. It is a delivery capacity decision.
The Four Signs Your Vendor Relationship Has Passed Its Useful Life
Not every legacy vendor relationship is a problem worth acting on immediately. Modernisation has real costs and real risks, and prioritisation matters. But there are four specific signals that indicate a vendor relationship is actively constraining your team rather than just carrying technical debt.
Change requests take longer than internal development. If raising a request with your vendor consistently takes more calendar time than building the equivalent functionality in-house, the relationship has inverted. You are paying for a constraint, not a capability.
Your team has built shadow systems to work around vendor limitations. Middleware written to compensate for vendor API gaps. Internal tools that replicate functionality the vendor should provide. Workarounds that live in the team's institutional knowledge rather than documented architecture. These are symptoms of a vendor relationship that has stopped serving the team.
Compliance updates require vendor involvement for what should be internal decisions. If every regulatory change, every PSD3 update, every ISO 20022 migration touchpoint requires a vendor change request, you have ceded control of your compliance posture to a third party with different priorities and timelines.
The vendor's own product roadmap is diverging from your needs. Vendors serving broad markets sometimes make product decisions that suit most of their clients but not you specifically. When your requirements consistently sit outside the vendor's standard roadmap, you are either paying for customisation work that generates ongoing maintenance debt or accepting constraints you did not choose.
If two or more of these apply, the relationship warrants formal review. If all four apply, it warrants a replacement plan.
Understanding What You're Actually Replacing
One of the most common mistakes in banking vendor modernisation is treating a vendor change as a technology change. It is not. Replacing a vendor means replacing a set of capabilities, a set of integration points, a body of institutional knowledge, and a set of people relationships with internal stakeholders who rely on the system.
Before any vendor is evaluated, you need a clear map of what the current vendor actually delivers. Not what the contract says it delivers. What your team actually depends on it for.
This means cataloguing the real usage: which internal systems integrate with the vendor's platform and through what mechanisms, which teams own those integrations, what institutional knowledge lives in the vendor's support organisation rather than your internal documentation, and what the failure modes look like if the vendor relationship ends before a replacement is in place.
Deloitte's analysis of banking system modernisation identifies institutional knowledge capture as one of the most underestimated risks in vendor transitions. Business rules embedded in legacy vendor configurations, business logic that has accumulated over years of customisation, and undocumented integration behaviours are all things that can surface as surprises mid-migration if they have not been catalogued first.
The assessment phase is not glamorous, but it determines the scope of everything that follows. Teams that skip it tend to discover the gaps at the worst possible time.
The Three Modernisation Paths (and When Each One Makes Sense)
Once you have a clear picture of what a vendor currently delivers, you have a genuine choice to make. Banking vendor modernisation does not mean full replacement in every case. There are three meaningful options, each with different risk profiles and timelines.
Encapsulation means building a modern abstraction layer around the existing vendor system without replacing the underlying platform. The vendor continues to handle core transactions. A new API layer provides your internal teams with a clean, modern interface that decouples application development from vendor constraints. This is the right choice when the vendor's core data or processing is sound but the integration surface is brittle or outdated. It reduces delivery friction immediately without triggering a data migration.
Selective replacement targets a specific capability rather than the full vendor relationship. A bank might replace a vendor's reporting layer while keeping their core processing, or replace their fraud tooling while maintaining their payments infrastructure. This approach, sometimes called the strangler fig pattern when applied to architecture, allows teams to modernize incrementally, prove the replacement works in production, and reduce risk by keeping proven components stable during the transition.
Full replacement is the highest-risk option and the one most prone to underestimation. Oliver Wyman's analysis of core banking modernisation notes that banks increasingly prefer progressive replacement strategies over big-bang cutovers, with phased co-existence approaches reducing rollout risk substantially. The small-scale launch model, where a digital banking arm or challenger brand is used to test the replacement in production before full migration, has produced better outcomes than institution-wide cutovers in most documented cases.
The choice between these three is rarely made purely on technical grounds. Timeline, risk appetite, regulatory posture, and internal team capacity all shape which path is viable. What matters most is that the choice is made deliberately and documented clearly, rather than defaulting to full replacement because it feels like the most thorough option.
Evaluating Replacement Vendors: What Engineering Managers Need to Assess
If selective or full replacement is the right path, vendor evaluation is the next critical step. Most evaluation frameworks used in banking focus on feature coverage, pricing, and reference clients. These matter, but they miss the questions that engineering managers actually need answered.
The questions that surface vendor quality most accurately are operational ones.
How does the vendor handle a breaking change in their API? What is their process for communicating breaking changes in advance, and what do their customers say about that process in practice? A vendor who handles API versioning well is fundamentally different to work with than one who treats backward compatibility as optional.
What does their support escalation path look like beyond the first tier? Tier-one support at most enterprize vendors is structured to filter. The question is what happens when a production issue requires engineering-level involvement on the vendor's side and how quickly that engagement actually happens.
How configurable is the platform without custom development? The shift from customisation to configuration that Deloitte's banking modernisation analysis describes as central to modern banking platforms is only valuable if the configuration surface is genuinely deep. A platform that positions itself as configurable but requires professional services engagement for any meaningful change has not actually solved the problem.
Does their roadmap have genuine input from clients, or is it set internally and communicated to clients as fait accompli? The answer to this question, best obtained through reference calls with existing clients rather than the vendor's sales process, tells you more about the relationship you are signing up for than any feature comparison.
Managing the Transition Without Breaking What Works
The operational risk in vendor modernisation is not the new system. It is the period between old and new when both exist simultaneously. Dual-run environments create data consistency challenges, integration complexity, and team focus split across two systems that behave differently.
Several practices reduce this risk materially.
Running the new vendor system in shadow mode against live production traffic before cutover lets you validate behaviour under real conditions without any customer exposure. Discrepancies between old and new system outputs surface before they cause incidents rather than during them.
Defining explicit rollback criteria before the migration begins means the decision to roll back, if needed, is made against objective criteria rather than under pressure in the moment. Without pre-agreed criteria, rollback decisions get made reactively and often too late.
Keeping the migration scope tightly bounded during each phase prevents the natural tendency of modernisation programmes to expand. Every additional system brought into scope during a migration phase increases the number of variables in play and reduces the team's ability to isolate the cause of any issues that arise.
Barclays' January 2025 outage which froze mobile banking, card payments and transfers for more than 20 million customers, was a public reminder that transitions in banking carry consequences that go beyond engineering. A UK parliamentary review found banks recorded 158 IT failures between January 2023 and February 2025, amounting to 33 days of cumulative downtime. The common thread across most of these failures was change management, not technology capability.
The Team Model Question: Build Capacity or Buy It
Vendor modernisation is resource-intensive. It runs in parallel with existing delivery commitments. It requires specialized knowledge of both the departing and arriving systems. And it does not stop requiring engineering attention once the initial migration is complete.
This is where many modernisation programmes stall. The business case is approved. The vendor is selected. The internal team is expected to absorb the migration on top of their existing workload. The timeline slips. The programme loses momentum.
Engineering managers need to be direct with leadership about the capacity gap that modernisation creates. Traditional outsourcing models tend to underdeliver in this context because they are optimized for cost reduction rather than knowledge transfer and embedded delivery. A vendor migration handled by a team with no continuity from the assessment phase through to production support is a team that will encounter the same undocumented surprises the assessment was supposed to surface.
The model that works better for modernisation programmes is dedicated teams with continuity across the full programme lifecycle. Embedded alongside the internal team, with shared context, shared documentation, and shared accountability for outcomes. Not a handover model. A parallel working model that builds institutional knowledge in your team as the programme progresses. If you're weighing how this compares to staff augmentation, the staff augmentation versus dedicated teams guide covers the practical tradeoffs in depth.
What Good Looks Like After Modernisation
A successful vendor modernisation programme does not end with the migration. It ends when the new vendor relationship operates differently from the old one.
That means engineering teams making changes that previously required vendor involvement. It means compliance updates that are handled internally with vendor systems as infrastructure rather than as gatekeepers. It means an integration surface that is documented, tested, and owned rather than inherited and feared.
McKinsey's analysis of banking technology investment notes a clear trend among banks building genuine technology capability in-house, with between 40 and 60 percent of software development now done internally at leading financial institutions, and some pioneering cases reaching 80 percent or more. Vendor modernisation is part of what creates the conditions for that shift. When the external systems your team depends on are well-designed, well-documented, and genuinely configurable, internal development capacity compounds rather than being consumed by integration overhead.
The banks that get this right treat vendor modernisation not as a one-time migration event but as an ongoing governance discipline. Regular vendor performance reviews against defined engineering SLAs. Clear criteria for when a vendor relationship warrants reassessment. Architecture decisions that deliberately limit the blast radius of any single vendor by designing for replaceability from the start.
That is not pessimism about vendor relationships. It is the design discipline that keeps engineering teams in control of their own delivery.
Ready to move beyond your legacy vendor strategy?
Our team works with banking engineering managers to design and execute vendor modernisation programmes without the big-bang risk. Start the conversation →
Thinking about how to staff the programme? Compare staff augmentation versus dedicated teams →
