Core Banking Upgrades

Core banking solution upgrades is not an easy task as it's not a computer or some gadget where you might want all the latest and greatest features available along with latest bugs. Yes, bugs are also common especially with "dot zero" versions. Core banking solution actually is a heart of your financial institution or fintech and here you need stability and minimise risks as impacts could be devastating, if something goes wrong, and thus with a system at heart of your organisation you won't play just to get "latest and greatest". You are looking stability for your heart.

Decision to do an upgrade on your core system or not is not the easiest as there are many risks involved. Yes, there are financial institutions who are happy to pay extended support fees and not to upgrade for years just to have stable environment. On the other side there are financial institutions who do an upgrades regularly. Ok, not every year, but frequently enough to keep up with latest technologies and opportunities latest core system versions offers. Decision which side to take is not the easiest, especially complicated it becomes, if core system allows local customisations, like Temenos Transact.

We have seen and participated in quite a few upgrades of Temenos Transact. Although further I will be talking more about Temenos Transact, just because we are more experienced in it, the same actually applies to any core system to some extent.

Many financial institutions think that core system upgrade to newer version is pure technical and no business involvement is needed. I can agree to it only to some extent. If you do frequent core system upgrades, yes, it will be more technical as mostly you will have to adapt your local customisations to latest version, fix bugs encountered in testing and sure very extensively test to make sure there are no core issues that might impact your business and customers. Though, sometimes even minor jump to the next version, can make this upgrade where business also should be involved. One such case might be when there are some significant functionality changes or improvements where there is an opportunity to get rid of some local customisations. Yes, every core system upgrade is an opportunity to move to core functionality as well thus minimising risks, time and effort in local customisation support. When you get rid of some local customisation, if something doesn't work, it becomes a problem for the solution vendor who has to provide fixes and not your IT team who can focus on something else that is critical for you.

If we speak about upgrades where you skip 5, 6, 7 ... 10 versions, it is tough. Such upgrades should be treated as new core system implementation and require business involvement as well. In such cases there are many local customisations, in some cases even customisations that are against vendor guidelines and impact core as well, that need to be changed in order they are supported by new version. There are situations as well when some functionality that financial institution relies on, is not supported by vendor any more and there is something else provided instead with similar functionality. As you can imagine, things can get messy and upgrade can take years, especially if upgrade is treated as purely technical and all customisations that can be replaced with core functionality are kept. 

Recently I was speaking with fellow consultant from another company and about upgrades he mentioned that sometimes it is much easier to implement new version as it is provided by vendor, do necessary customisations from scratch, sure after rigorous review on which should be kept and which can be abandoned due to latest version provides alternative functionality, and migrate all the date into new and fresh environment. I fully agree with him on this as it will take less time, gives better opportunity to review all customisations you have done and with upgrade also migrate all the data onto latest core functionality. Some might be afraid of "migration" as it might be painful on its own. Don't be afraid, well planned, it can go seamlessly as well.

To conclude here are some takeaways from what I wanted to say:

• Each upgrade should be evaluated, if it can be treated as technical upgrade or business is impacted as well.
• Involve business when there are functionality changes in core where business might benefit.
• Upgrade is great time to evaluate which local customisations should be carried over and which can be substituted with new core features.
• Sometimes it makes more sense to set up environment with latest core system version and migrate data onto it to benefit from features core provides.
• Upgrade is a risk and opportunity at the same time.
• How often to upgrade your core system - it depends on how you will benefit from the latest version, but don't postpone upgrade too much. For stability, less risks and financial gains, don't be the one who upgrades your core every year, but don't wait until core system vendor will drop extended support for the version you are using.

PS. Advice before upgrade, check with other financial institutions how do they find latest version. As always, there will be versions more stable and there will be versions which can be nightmare.