The path to turning off legacy platforms for financial services firms

Introduction

Financial institutions need to shut down legacy systems to modernize and enable greater innovation. Multi-decade old legacy platforms are primarily black boxes. In most cases, current teams do not know the details and inner workings of these legacy platforms. Despite this high degree of uncertainty, leadership teams steer replacement initiatives toward fixed-milestone, fixed-budget projects. Missed expectations, higher-than-planned budgets, and suboptimal end solutions are the reality.

As an example, A global trademark processing firm sought to replace their legacy data onboarding and ingestion mainframe. The internal trademark search products relied on decades-old data acquisition and conversion logic. The leadership team determined that a 1.5-year effort would be sufficient to replace the legacy technology with a modern data ingestion platform. Making this commitment before building out a conversion playbook and identifying the de-risk approach to reduce knowledge uncertainty guaranteed that the 1.5-year target began moving as soon as detailed analysis began. The result was a nearly doubling of the timeline and, consequently, the budget. 

Situations like this one can be avoided. The success rate can be dramatically increased if executives focus on critical levers.

Key risk-avoidance measures

Preventing missed expectations comes down to acknowledging that replacing a legacy body of technology comes with a high degree of unknowns that cannot be accurately boxed and quantified.

The need to ring-fence the investment required to modernize is necessary to accurately measure ROI is understandable. However, simply wishing it be so doesn't do the trick. Ensuring a successful modernization that comes within expectations of the timeline, resources, and budget required — without the unmanageable surprises — comes down to four main risk-avoidance measures:

1. Fund and drive due diligence as an independent activity to the modernization effort
2. Leverage accelerators and tools as much as possible
3. Build the replacement platform from scratch
4. Lead the importance of modernization from the top and appreciate the loss-aversion psychology

Avoidance Measure 1: Fund upfront risk reduction

Funding and driving due diligence as an independent activity to the modernization effort allows the team to be reasonably thorough in upfront risk reduction and discovery. Successful teams drive this phase aggressively, assessing all the big rocks in the architecture — the platform’s most complex functional module.

Each module in the future-state solution architecture should be assessed on three dimensions:

1. Alternate options: Should this module be re-built from scratch, or is there an off-the-shelf product that could serve its purpose?
2. Accessibility of the legacy module: How obfuscated is the legacy module? What is the feasibility of the transformation team to be able to forward- and reverse-engineer it? In one instance, where a bank was attempting to migrate off an old portfolio performance application there is no way to access the original logic without sitting at the workstation it was developed on. In contrast, there are other cases where the baseline code can be exported and analyzed by a distributed team. Each of these circumstances implies a different level of analysis effort and risk.
3. Migration approach: Can this module be migrated independently of the overall solution? Where does it fit in the migration approach? 

These inputs serve to produce a migration Playbook that will contain:

• The future-state solution architecture 
• Essential requirements and remaining unknowns for each module
• The migration approach that will govern the transition 
• Most significant risk areas and unknowns

This Playbook enables deep conversations with all the business and operations teams to create a robust business and operations plan to support the migration. These conversations include detailing the end-state technology and organization design before building the bottom-up transition plan.

These inputs now serve to estimate a more accurate migration timeline and budget. Plans should also account for switching off the legacy technology stack to avoid multiple stacks and extra cost. 

As an outcome of this phase, the team now has a roadmap toward the end state and a detailed profile of the expected benefits to cost, risk, and delivery speed.

Avoidance Measure 2: Explore and invest in accelerators

A byproduct of skipping avoidance measure No. 1 is the subsequent reluctance to explore or invest in accelerators as teams discover the complexities of opening up legacy code with no access to the original authors.  

Accelerators come in three primary flavors:

1. Code converters aid in converting mainframe code to java, javascript, and other languages. There is an upfront cost to use tools in this category.
2. Code translators can export code to formats that are more readable by today’s engineers. Similar to converters, there is an upfront cost incurred to use these tools.
3. Code containers can run legacy code in a container in the cloud. These tools are generally licensed annually for the duration that they are running the legacy code.

Reluctance to make investments in these tools stems from a concern about paying the associated fees and adding to a now-growing program budget. Teams are also reluctant to hand over the crown jewels to conversion tools that convert these modules into a black box. 

Assessing the benefits of using these tools during the discovery phase allows teams to factor in the necessary costs into the overall program budget upfront. The future-state architecture will also dictate whether the team feels they need to know the internals of a legacy module and need it translated. If a core module is not considered part of the firm’s core IP, it can be more advantageous to containerize it and run it in the new platform and defer translation/retirement until a time when more appropriate.

Avoidance Measure 3: Bias toward building from scratch

As more and more digital-native firms establish their footing, examples continue to abound of what were once considered mission-critical platforms being written from scratch by teams. Robinhood designing and writing their brokerage platform from scratch is one such example. Larger enterprises still reliant on legacy infrastructure deemed critical couldn't fathom re-writing a platform like that one.

There are a few primary reasons. One of them is the inertia to dig into the product capability depth that legacy systems have accumulated. Some of that can be attributed to motivation or urgency to do so. Some of it can also be attributed to the fear of missing out on some big gaps in a large financial services platform.

In evaluating an old piece of technology’s size and scale, teams get frozen attempting to untangle and make sense of the original code. A deeper assessment might reveal that the percentage that is proprietary is only 15% to 20% in reality. The remaining modules tend to be mainstream and generally understood components. 

AWS Migration Playbook Pathways

Avoidance Measure 4: Hammer home executive support and reduce loss aversion

Employees in large enterprises are biased to be conservative. 

A 2012 McKinsey global survey that surveyed managers at large enterprises highlighted this pull toward extreme loss aversion. On average only 10% of the managers surveyed were willing to move forward with investments when the chance of a negative event increased over 40%. The majority backed investment paths that stayed neutral.

Why are managers in large, hierarchical organizations so risk-averse? Syracuse University professor Ralph O. Swalm tentative conclusion was that corporate incentives and control processes actively discourage managers from taking risks—a conclusion he felt was supported when managers he interviewed acknowledged that although their risk aversion was bad for their companies, it was good for their careers. We share his belief. CEOs are evaluated on their long-term performance, but managers at lower levels essentially bet their careers on every decision they make—even if outcomes are negligible to the corporation as a whole.

https://hbr.org/2020/03/your-company-is-too-risk-averse

There are no rewards for approving modernization scope and finding out that a particular use case or customer scenario was missed in an initial build. No one wants that risk.

As an example, a legacy component in a platform performed Investment Rate of Return calculations. In re-writing this module, a team member might be paralyzed to decide on the number of decimal places it might need to produce on an FX rate. Rather than analyze it in more detail, it is safer to say, “Do what the current system does.”

Getting past this type of mental block requires strong and continued reassurance from the executive team. Team members need to know that discovery is expected as the new system goes live, and it is impossible to capture 100% of the current scenarios and still be expedient and agile. The nature of the migration is that the teams will need to be responsive to new discoveries long after the new system is live and in customers’ hands.

Obviously, this risk tolerance is also dependent on the industry, regulatory, and customer circumstances of the platform being migrated. But by and large, leaders must help make sure this fear doesn't slow teams from making decisions and maintaining momentum with the migration.

Conclusion

Following the avoidance measures above, a North American Asset manager avoided making similar commitments to their board. The asset manager sought to upgrade existing legacy data feeds used to discover new insights on commercial real-estate data, and to run deeper analytics for fund managers. Internal data platforms relied on 1,500 inbound data feeds and converters each over a decade old. These feeds needed to be re-written to support modern architectural principles and enable more product innovation. 

The client leadership team was seeking to build a case for a fixed-price project. A large number of unknowns about each feed made accurate estimation and commitment impossible. After assessing the unknowns and uncertainty, the team steered toward funding an architecture and migration analysis first. The outputs informed a more accurate build and transition plan for the new platform with much lower uncertainty. Fewer surprises during the modernization also aided in higher team morale and retention through the effort.

The challenges of modernization are real. The risks are very high, yet lower-than-expected returns have led organizations to abandon or delay modernization projects. Yet, in the face of economic and digital transformation pressures, the need for modernization is growing stronger. As leaders prepare themselves for legacy system replacement and implementation, the success rate can be dramatically increased by focusing on the four risk-avoidance measures outlined in this article.