A core banking migration is like getting spinal surgery whilst juggling bundles of burning dollar bills. Even if successful, it’s expensive, dangerous and you will get burned.
Before we get into the expense, the burning and the pain of core banking migrations, we first need to define what a core migration is, and also describe all the aspects involved in making a core migration project something that is risky, costly and ultimately doomed to fail.
What is a Core migration?
A core banking system is essentially the nerve centre of a bank. Every transaction regardless of how or where it is generated eventually ends up at the core where reconciliation, reporting and accounting is finalised.
The vast majority of banks have been in operation for more than 30 years, and as such are tied to vintage software running on hardware which, even if new, has a design blueprint older than most of the staff operating it.
But before we discuss why Banks need to change their IT capabilities to compete effectively, we need to discuss the current banking IT landscape to ensure we understand the imperative for change.
What is a legacy system?
A legacy system is effectively any system whose base hardware or software design predates the internet. So we’re talking pre-1980’s here.
Typically you find the following hardware systems in banks (with associated and suitably geriatric software)
- Mainframe Z/OS
- iSeries AS400
- HP Integrity/Superdome OpenVMS
These old legacy systems have (in general) the following positive and negative attributes;
- Bulletproof and proven – Often highly resilient with longstanding and well-understood processes. What they do, they do very well.
- Backwards compatibility – Can still run C/C++, COBOL, Assembler, REXX, Fortran code from the 60’s right up to today
- High Cost – Costly maintenance and support requiring niche skills and costly staff.
- Lock-in – Vendor of the platform controls the pace of innovation, if they don’t do it, you can’t have it.
- Utilitarian Culture – Culture is utilitarian and focused on the system, not the customer.
- Limitation of code compatibility – Can’t run the latest version of the software or exploit new capabilities.
- Perception of security vs. reality – Legacy systems rely on obscurity and to some degree, isolation to provide security. “The mainframe has never been hacked” is often quoted but is not correct. Few people understand mainframe security. So this is essentially a detection problem, not a proof that the system is, in fact, secure.
- Design – The core design of these systems assumes a castle and fortress surrounding them as opposed to the interconnectedness by design approach of modern systems.
What is a legacy process?
A legacy process is a process that is designed to work around or compensate for the limitations of a system. A “greenfield” process, however, is a process which is designed to ensure that specific attributes (such as efficiency, customer experience, speed) are maximised without reference to the underlying system.
In short, a legacy process is made to fit the system, a greenfield process is made to fit the requirement.
a legacy process is made to fit the system, a greenfield process is made to fit the requirement. Click To Tweet
Why is this important?
Legacy systems limit the ability of banks to operate in an agile fashion, reacting to change effectively and in a timely manner.
Legacy processes tend to be found where you find legacy systems. They further limit the ability of banks to bring innovation to fruition.
It’s important to note that banks don’t have an issue thinking up innovative ways to do things, the issue is in actually bringing these approaches to market and getting them in front of customers.
These limitations are generally imposed by the following constraints;
- Process inertia – (don’t change what works, even if it would have a customer benefit)
- Organisational inertia – changing things requires sign-off from everybody even if the change is cosmetic
- Rule paralysis – changing something might have an impact on regulation, security, compliance and requires analysis by all and agreement by all
- System constraints – “computer says no” – can’t be done because the underlying IT won’t support the change or would cost too much time and effort to deliver outweighing the advantage to the customer.
What are the effects of a core migration?
While such a major transformation is going on – and a program of this nature would take anywhere from 2-5 years – the Bank has to continue operating as usual.
A massive transformation process running in parallel to “normal” operations has the following adverse effects:
- Permanent change freeze
- Changes to the existing core system have to be frozen for the entire duration of the project.
- Innovation that in any way touches the core cannot be implemented as it would impact the configuration of the new core leading to cascading delays and potential disruption and instability if the change goes ahead (this means that the time to attack a competitor in banking is during a core migration as they cannot respond for at least several years….More on this in a later post)
- Resource Shortage
- A core migration is so complex that any bank will have their “A” team working on it, leaving no resources for anything else.
- Cut over
- The cutover date will be shared with the regulator and cannot be missed as it is irrevocable. Once you cutover you cannot go back.
- This means that any threat to the timeline will be dealt with by cutting features so a new core that gets delivered generally is less capable in the short term than the one had just replaced.
the time to attack a competitor in banking is during a core migration Click To Tweet
So if bank transformations are so fraught with danger, what alternatives does a bank have?
5 alternative approaches to banking Innovation
There are 5 approaches banks can take to maximising their innovation capability return on investment for IT. Core system migration is one, but there are other approaches as well which I have summarised below.
1. Tear off the Sticking Plaster
Build a new system from scratch and cut over to it, greenfield on-premise build with irrevocable cutover. For most banks, this means a newer system from the usual suspects (IBM, Temenos etc…) Replacing a legacy system with a legacy system in waiting.
2. Lipstick on a Pig
Middleware integration with no backend changes. Use a middleware solution to mask and ‘tidy-up’ the limitations of the legacy backend systems by doing integrations at the middleware layer via API’s and translating the results back to the legacy environment. This can be combined with option 3.
Put a nicer looking front end on the existing solution without changing or altering capabilities. UI/UX changes with no middleware or backend changes.
4. Ostrich Approach
Do nothing and hope your competitors and your customers don’t notice
5. A Balanced Approach
Leave the legacy system as-is, build a new separate cloud-based non-legacy environment with minimal integration with existing IT and innovate and integrate there – offers the option to cut over (or not) as desired, when desired with no disruption.
Which of the approaches works best for an individual customer depends on what strategic imperatives, once those are known then they can be matched to the best approach.
1 is lowest, 5 is highest, 0 is no effect.
|Greenfield with cutover||Middleware integration||UX/UI enhancement||Ostrich approach||Balanced approach|
|Cost to implement||5||2||1||0||3|
|Cost to maintain||5||3||1||0||2|
|Effect on complexity (long term cost)||3||4||1||0||2|
|Effect on TCO (long term)||3||4||1||0||3|
|Innovation capability improvement||5||3||1||0||5|
|Effect on staff costs (initial)||5||3||1||0||3|
|Effect on staff costs (long term)||3||3||1||0||2|
|Re-training and education costs||4||4||2||0||4|
|Futureproofing (3+ yrs)||4||2||1||0||5|
|Effect on customer experience||5||3||2||0||5|
|Speed to implement||1||3||5||0||3|
|Integration capability improvement||5||3||0||0||5|
|Process re-engineering enablement||5||3||0||0||5|
|Project Success probability||1||4||5||5||4|
Core Banking migrations are enormously painful and have a high failure rate – even success can be painful due to feature poverty on the new system. It is possible to reap the innovation benefits of a modern flexible banking core by soft migration (see next post for more detail). A soft migration doesn’t stop the innovation clock because it builds a parallel low-cost core which allows banks to innovate on. It can focus on doing new business there and eventually roll existing customers to it over time.
Doing nothing is not an option, and going halfway by using a middleware solution only kicks the can down the road. This creates a bigger mess to unravel when core migration cannot be put off any longer.
In my next post, I will cover the migration process in detail.
At Leveris we help banks to bring disruptive innovation to bear faster and with far less cost and risk. Get in touch to see how we can help you.