Packaged Core Banking Upgrade Strategy and Vendor Lock-In
Staying on the Upgrade Path When Every Customisation Pulls You Off It
Buying a packaged core is a reasonable decision that most banks make for sound reasons: the vendor absorbs regulatory change, the functionality is proven, and the alternative is building a ledger. What follows is almost always the same story. The package covers eighty percent of requirements, the remaining twenty percent gets customised, and five years later the institution is four versions behind, out of mainstream support, and quoted a number for upgrading that looks like a replacement project.
That outcome is not inevitable and it is not really the vendor's doing. A packaged core banking upgrade strategy that works is mostly a set of disciplines about where your logic lives and what you are willing to modify.
What actually creates lock-in?
Six mechanisms, of which customisation is the most damaging and the most self-inflicted.
| Mechanism | How it binds you | Avoidable? |
|---|---|---|
| Customisation of vendor code | Must be reapplied and retested each upgrade | Largely |
| Integration through internal data structures | Vendor changes break your integrations | Yes |
| Proprietary extension language | Skills and logic are vendor-specific | Partly |
| Vendor-only implementation skills | No independent capability to change or assess | Yes |
| Contract terms | Export, exit, and upgrade rights weak | At signature |
| Data model coupling | Reporting and downstream systems read vendor tables | Yes |
Why is customisation the primary driver?
Because it converts every upgrade from a vendor activity into a bespoke project of your own.
An unmodified package upgrades on the vendor's schedule with the vendor's tooling and testing. A heavily modified one requires each modification to be reviewed against the new version, reapplied, and regression tested, which multiplies the effort and the risk. Past a certain volume of modifications, upgrading costs more than the business benefit of the new version, so it gets deferred, and deferral increases the next upgrade's cost. That is the loop, and it is entered one reasonable-sounding change request at a time. The general debt dynamic is set out in this guide to reducing technical debt in policy systems.
Do you know how many modifications your last upgrade required reapplying?
What is upgrade debt, and how do you measure it?
Versions behind, support status, and the regression effort your modifications impose per upgrade.
Measure four things and publish them. How many versions behind the current release you are. Whether your version is in mainstream support, extended support, or unsupported. How many modifications exist, classified by type and by whether the vendor supports the extension point used. And the effort of the last upgrade, split between vendor-driven work and reapplying your own modifications. That last split is the number that changes conversations, because it makes visible that the upgrade cost is largely a consequence of internal decisions rather than vendor pricing.
Why does falling behind accelerate?
Because the delta grows, vendor tooling targets recent versions, and institutional knowledge decays.
Each skipped release increases the difference to reconcile, and vendor migration utilities are generally built to move customers from recent versions rather than from a release five years old. Meanwhile the people who wrote your modifications move on, so the reapplication work becomes archaeology. The GAO's June 2019 review of critical federal legacy systems illustrates the destination: systems running for decades, some on hardware as old as the system, with dwindling availability of the skills needed to support them. A packaged core that stops upgrading becomes a legacy system on a faster timescale than a bespoke one, because you also lose the vendor's regulatory maintenance.
How should extension be architected?
Outside the package wherever possible, using supported interfaces and event streams.
| Approach | Upgrade safety | Use for |
|---|---|---|
| Configuration within the product | Safest | Anything the product supports natively |
| Vendor-supported extension points | Safe if the contract commits to their stability | Logic that must run inside the core |
| Side-car services consuming events | Safe, your code your lifecycle | Most differentiating logic |
| Orchestration outside the core | Safe | Workflow, routing, decisioning |
| Reading vendor internal tables | Unsafe | Nothing, use published interfaces |
| Modifying vendor code | Unsafe | Genuine last resort with a retirement plan |
What belongs outside the package entirely?
Differentiating logic, orchestration, decisioning, and anything that changes frequently.
The package should hold accounts, balances, postings, and the product mechanics it was built for. Pricing decisions, eligibility rules, customer journeys, fraud and risk decisioning, and workflow all change faster than a core release cycle and should live in your own services, invoked through supported interfaces. That division also improves delivery speed independently of lock-in, because your teams can change your logic without touching the vendor's release calendar. The interface discipline is the same one in this guide to API integration capability when selecting vendors.
Why is an anti-corruption layer worth its cost?
Because it stops the vendor's data model spreading through your estate.
Wrap the package behind your own interface expressed in your domain language, and let every internal consumer talk to that rather than to vendor structures. It costs real effort and it means a vendor change, or a vendor replacement, becomes an adapter change rather than an estate-wide rewrite. Without it, reporting systems, downstream services, and analytics all bind to vendor table structures, and the package becomes unremovable regardless of what the contract says. The same reasoning drives seam design in strangler fig core banking migration.
How do you get back on the upgrade path?
Inventory the modifications, classify them, delete aggressively, then commit to a cadence.
Start with a complete inventory of modifications including who requested each, when, why, and whether the reason still holds. Then classify: retire, reimplement outside the core, migrate to a supported extension point, or keep as a modification with an owner and a review date. Expect a meaningful share to fall into the first category, because requirements expire, standard functionality catches up, and some modifications serve populations small enough to handle operationally. Then set an upgrade cadence and hold it, since regular smaller upgrades are dramatically cheaper than occasional large ones, which is the same finding the DORA research reports for software delivery generally: speed and stability correlate rather than trade off.
Which customisations should be deleted rather than migrated?
Those whose requirement has lapsed, those duplicating standard functionality, and those serving trivial populations.
Ask the business owner to re-justify each modification as if requesting it today, with the current upgrade cost attached. That conversation removes more customisation than any technical analysis, because the original requester frequently no longer needs it and nobody had asked. Where a modification serves a handful of accounts, price the operational workaround against the perpetual upgrade cost, and the answer is usually obvious once both numbers are visible.
Could each of your core modifications be re-justified today at its true upgrade cost?
Which contract terms reduce lock-in?
Data export, upgrade support, roadmap visibility, exit assistance, pricing protection, and clarity on supported customisation.
| Term | What to secure |
|---|---|
| Data export | Full export in documented, usable formats on demand, not only at termination |
| Upgrade support | Commitment to support your version for a defined period and to assist upgrades |
| Extension point stability | Which interfaces the vendor commits not to break, and for how long |
| Roadmap visibility | Advance notice of deprecations and architectural changes |
| Exit assistance | Defined transition help, duration, and cost, agreed at signature |
| Pricing protection | Caps on maintenance and volume-based increases |
| Source code escrow | Access conditions that are actually triggerable and tested |
| Third-party access | Right to use non-vendor implementation partners |
Negotiate all of it before signature, because leverage disappears the moment the platform is live. Escrow deserves scepticism unless the release conditions are realistic and someone has verified the deposit is complete and buildable, since escrow that cannot be used is a comfort clause. Supervisory expectations reinforce the substance here: the EBA's guidelines on outsourcing arrangements set out criteria for assessing whether a function is critical or important and the associated obligations, and the FSB's December 2023 toolkit provides tools for managing third-party risk across the relationship lifecycle, which includes upgrade and exit. Exit specifically is covered in cloud exit and stressed exit planning.
How do you keep knowledge independent of the vendor?
By owning the test suite as your specification and keeping internal people who understand the configuration.
Your automated test suite is the most valuable vendor-independent asset you can build, because it expresses required behaviour in a form no vendor controls. It makes upgrades safer, gives you leverage in disputes about whether something is a defect, and becomes the specification if you ever replace the platform. Alongside it, document configuration decisions with rationale rather than only settings, and retain internal staff who can assess vendor proposals critically. An institution wholly dependent on the vendor for understanding its own configuration has no negotiating position and no ability to judge an upgrade estimate.
How do you evaluate a replacement without repeating the mistake?
By scoring integration, extension model, and upgrade history rather than feature lists.
Feature comparison drives most core selections and predicts very little about the next decade. Weight instead the extension model and its documented stability, the published interface surface, the vendor's actual upgrade history with reference customers on comparable customisation levels, the availability of non-vendor skills, and the contract terms above. Then ask reference customers one specific question: how many versions behind are you, and why. The answers to that question are more informative than any demonstration. The general framing is in this guide to build versus buy decision-making, and where a merger has left you with two packages, the disposition logic is in bank merger technology integration.
How should the programme be sequenced?
Measure, inventory, delete, externalise, then upgrade on a cadence.
| Phase | Duration | Deliverable |
|---|---|---|
| Upgrade debt measurement | 1 month | Versions behind, support status, modification count, last upgrade cost split |
| Modification inventory and classification | 2 to 3 months | Every modification with owner, rationale, and disposition |
| Deletion wave | 2 to 3 months | Retired modifications, operational workarounds agreed |
| Anti-corruption layer | 3 to 5 months | Internal interface, consumers migrated off vendor structures |
| Externalisation of logic | 6 to 12 months | Differentiating logic moved to side-car services |
| First upgrade on the new footing | 3 to 6 months | Measurably lower reapplication effort |
| Sustained cadence | Ongoing | Regular upgrades with declining cost per upgrade |
The deletion wave is the phase with the best return and the least engineering, which makes it the right place to start once the inventory exists.
Which metrics matter?
Versions behind, modification count and trend, upgrade effort split, share of logic outside the core, and consumers reading vendor internals.
Report versions behind current release and support status as a standing risk item, since that framing gets executive attention in a way technical debt does not. Track modification count with its trend, because the direction matters more than the absolute. Split upgrade effort between vendor-driven and reapplication work, as that ratio is your lock-in measure. Report the share of business logic running outside the core. And count internal consumers still reading vendor internal structures, driving it to zero, because each one is a constraint on every future vendor decision.
Packaged core lock-in is mostly accumulated consent. Each customisation was approved, each integration shortcut saved time, and each deferred upgrade was locally rational. Reversing it needs the same incrementalism: measure the debt honestly, delete what nobody can re-justify, move your logic outside the package, and then upgrade often enough that it stays routine.
Frequently Asked Questions
What actually creates lock-in with a packaged core?
Customisation, integration through internal data structures, proprietary extension languages, vendor-only skills, and contract terms that make leaving or upgrading expensive.
Why is customisation the primary driver?
Because every modification has to be reapplied and retested at each upgrade, so the cost of staying current rises until upgrading stops happening at all.
What is upgrade debt?
The accumulated work required to reach the current supported version, measured in versions behind, support status, and the regression effort your customisations impose per upgrade.
Why does falling behind accelerate?
Because each skipped version increases the delta, vendor migration tooling targets recent versions, and the people who understand your modifications gradually leave.
Where should extensions live?
Outside the package wherever possible, as side-car services consuming events and calling supported interfaces, so the vendor can upgrade the core without touching your logic.
Which customisations should be deleted rather than migrated?
Those whose original requirement no longer exists, those duplicating standard functionality added since, and those serving a handful of accounts that can be handled operationally.
Which contract terms matter most?
Data export in usable formats, upgrade support commitments, roadmap visibility, exit assistance, pricing protection, and clarity on what customisation the vendor will support.
How do you keep knowledge independent of the vendor?
Own your test suites as the executable specification of required behaviour, document configuration decisions with rationale, and keep internal staff who understand the configuration.
