Application Decommissioning in Banks – Triggers, Risks and Mitigation

Not too many of us give a lot of thought to decommissioning applications that are past their useful shelf life. For mature organizations, particularly in banking, this can become a serious hurdle if not managed thoughtfully.

Technology is changing rapidly today compared to the past resulting in newer applications with much better architecture and features being made available. The cloud is now more accessible with more applications that are being designed as cloud native. While new organizations can easily migrate to the contemporary applications, it’s a far more challenging task for organizations that are using legacy platforms. Any application deployed over five years ago is considered legacy. The longer the application has been used, the more challenging it is to migrate out and decommission the same.

Let’s look at key reasons for application decommissioning in the context of the banking industry.

1. Technology obsolescence – Availability of newer, faster, more scalable applications and infrastructure. E.g., Legacy platforms may not be able to harness the true power of any of the modern cloud platforms unless they are completely rearchitected – in most cases this would be an expensive, time consuming and risky proposition
2. Lack of functionality – over a period changing customer needs, regulatory requirements and new business needs will need a platform replacement when it becomes impossible to enhance the legacy system in a cost effective and satisfactory manner.
3. End of support – where systems used in the bank are no longer maintainable due to lack of suitably trained manpower for the same (either with the bank or the vendor) and will trigger a replacement effort
4. System vulnerabilities – increased risk to the bank of exposure to cyber threats due to system vulnerabilities. When remediation is not possible due to technical limitations or the inability of the team to address the issue suitably, the bank will need to trigger a replacement of the system
5. Mergers or amalgamation of the bank – when one set of applications needs to be retired

Key considerations and risk mitigation when planning to retire an application in the bank (“target”)

1. Support Manpower – the risk of losing trained resources once the decision to retire a target platform has been made. IT personnel either chose to leave the bank or to transfer to a different department rather than continue to be associated with a platform that is to be sunset. Select staff can be retained with suitable financial incentives. However, the bank must partner with an experienced service provider to deploy a team for knowledge transfer and take on the ongoing support and maintenance of the target system to mitigate the risk. Support will include critical fixes and enhancements (e.g., regulatory changes) till such time processing is moved to the new platform
2. Project management and governance – bank needs to work with the partner to have a carefully constructed timeline with clear milestones, risk factors and dependencies, leading to the sunset of the target system. This will require a central PMO having representatives from the bank as well as partners along with an established governance mechanism for periodic reporting to senior management and an escalation path to review issues that will come up from time to time
3. Data management – if processing will migrate to a new platform, there will be a need to carefully plan data migration from the target system to the new system. This will include the movement of static data and transaction information.
   1. Static data – an inventory of static data needs to be made and data quality to be evaluated to determine the extent of cleansing needed so data quality issues are not propagated to the new platform. If the data from the target system is insufficient to meet the requirements of the new system, there has to be suitable data enrichment
   2. Transaction data – decision on all or limited historical transaction data to be migrated to the new platform
   3. Data archival – this is required to meet statutory obligations of the bank. This will be a combination of storing historical reports as well as the raw data in a manner that enables easy access when needed. Data is to be stored so that it can be accessed without the need for the target application to be running. Complete documentation of data structures needs to be in place
4. Interface management – Certain applications like the core banking platform will have numerous interfaces to various other systems in the bank as well as external-facing interfaces. These need to be inventorised and isolated from the target system to disentangle the spaghetti and enable the target replacement
5. Functional customization – legacy systems will have bank specific customization built over the years. These features need to be identified and redundant changes can be discarded while the rest will be made available in the new platform
6. Operational processes – Operational processes usually designed around the legacy platform will have to be re-engineered to function optimally in the new environment

With the above considerations and an experienced and committed partner for support the decommissioning process of large and complex applications can become smoother for the bank.

Written by

Shrinath Bolloju – Chief Strategy Officer, KGISL.