A thirty-year-old core system doesn’t fail all at once — it fails by degrees, in the form of client onboarding you have to turn away because the platform can’t scale, and mainframe expertise that gets harder to find every year. Luxembourg’s own banking sector has recently lived through exactly this transition, and the lessons are specific enough to be genuinely useful.
Banque Internationale à Luxembourg — the country’s oldest bank, and its second largest — spent five years modernising a core system that had accumulated three decades of incremental change into what the bank’s own team described as “a plate of spaghetti.” The bank had reached the point of refusing client onboarding volumes the legacy platform couldn’t handle, while the pool of people who still understood the underlying mainframe technology kept shrinking. This is a reading of what that kind of modernisation actually requires for an institution running private banking alongside retail and corporate lines simultaneously — where client service continuity carries a different weight than in a purely retail replatforming.
Who this is for
- The CTO at a Luxembourg private bank or universal bank with private banking operations, evaluating a core modernisation.
- The board weighing the risk of a “big bang” cutover against the risk of continuing to run an ageing core.
Why replatforming and best-of-breed both get rejected in practice
Institutions facing this decision typically consider three paths: incremental replatforming of the existing system, a best-of-breed assembly of specialist modules, or a full platform replacement. Replatforming an ageing core tends to be dismissed as effectively unending — each layer modernised reveals another dependency, and the institution never actually exits the legacy estate. A best-of-breed build, assembling specialist point solutions for payments, wealth front office, and core accounting separately, is frequently judged too costly and operationally complex to integrate and maintain over the long run. That leaves a full platform replacement as the realistic option for an institution that has genuinely outgrown its core — not because it’s risk-free, but because the alternatives carry risks of their own that are easy to underweight.
Free · 4 minutes
If your most senior engineer left tomorrow, would anyone still understand the system?
Fourteen questions on documentation, dependencies, and the gap between how the architecture works and how many people know it. Banded finding on screen, full sheet by email.
The case for a single cutover across all business lines
BIL’s approach was to replace core banking, payments, and wealth front office in a single “big bang” deployment across retail, corporate, and private business lines simultaneously, rather than migrating line by line. This is a materially higher-risk approach than a phased migration — but a phased approach creates its own specific risk for a private bank: running client-facing private banking on the old platform while retail moves to the new one means maintaining two fully operational cores in parallel for an extended period, with the integration and reconciliation burden that implies, and with private banking’s traditionally more bespoke, relationship-driven processes often the hardest line to migrate last. The single-cutover approach demands total confidence in the new platform before go-live — the twenty-month implementation involved extensive user testing and business operability testing specifically to build that confidence before the cutover date, rather than treating testing as something to continue after go-live.
What actually changed for client service
The concrete post-implementation gains are instructive for what a private banking-specific benefit looks like: the bank was able to significantly increase pricing segmentation granularity — dividing wealth management pricing conditions by a factor of three, and retail and corporate by five to six — because the new platform’s modular pricing structure allowed a matrix approach the old system couldn’t support. For a private bank specifically, this kind of pricing and service segmentation flexibility is often the actual commercial justification for the modernisation, more than the underlying technical architecture — the ability to differentiate service and pricing precisely by client segment is a private banking capability question, not just an IT question, and should be evaluated explicitly against the bank’s actual client segmentation strategy rather than assumed as a generic platform benefit.
The vendor ecosystem is still consolidating
Worth factoring into any current platform decision: the major private banking and wealth technology vendors are actively acquiring to fill gaps — a leading core banking vendor’s 2026 acquisition of a wealth orchestration specialist, aimed explicitly at strengthening its wealth proposition and AI-driven capability, is a recent example of the pattern. A bank selecting a platform today should expect the vendor’s product portfolio and roadmap to look different in three to five years than it does at signature, and should weigh vendor acquisition activity as a signal of where genuine product investment is heading, not just a corporate development footnote.
What a private-banking-aware modernisation plan includes
- An honest choice between phased migration (with the dual-core operational burden that implies) and a single cutover (with the pre-go-live testing confidence that requires) — made deliberately, not by default.
- Testing and business operability validation extensive enough, before go-live, to justify the confidence a single cutover demands if that path is chosen.
- An explicit mapping from the new platform’s pricing and segmentation flexibility to the bank’s actual private banking client segmentation strategy, not a generic assumption of benefit.
- Vendor roadmap and acquisition activity reviewed as part of the selection decision, not just current-state feature comparison.
How we engage with this
We read core modernisation plans against the specific risks a private banking business line adds to the decision — client service continuity, segmentation strategy, and cutover approach — as an Architecture Review. The output is a written assessment of the plan’s readiness before the board commits to a cutover date.
We don’t implement core banking platforms. We don’t sell migration services. We read what’s planned, identify what’s missing, and write it down for the people who have to decide.
Pricing is published at /pricing/. If you’re planning a core modernisation that includes a private banking line, the place to start is a conversation.
Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.
Build and rescue work
Hands-on delivery of this kind is handled by Sixteen Pillars Studio.
Looking at an acquisition, supplier, or major project?
The greatest risks are rarely visible in the executive summary. The Sixteen Pillars framework surfaces the technology risks that diligence usually misses.