Purposeful Coexistence in Your Journey to a Digital Core

The cost and complexity of legacy banking technology has firmly established the need for financial institutions to modernize their systems.

Banks must move away from legacy infrastructure that stifles innovation and prevents them from providing real-time, personalized banking experiences to customers. By moving core technology to the cloud, banks can unlock greater flexibility, enhanced resilience and lower operating costs.

In the past, banks would have taken a big bang migration approach to move to a new core platform. This would require a single migration step in which all product data is extracted, transformed and loaded in the least amount of time.

This approach was risky but more viable in the era of the 9–5 banking schedule, with customers accepting a lack of service for long periods at night and on weekends. In many cases, the batch-based nature of legacy core exacerbated the difficulty in bridging between old and new when phasing migration events.

Because of the distribution methods of the day – where scope was delivered as one big bang, with only the most innovative banks managing quarterly releases – migrating data in this way often made sense.

Customer dissatisfaction with the frequent failures of the Big Bang migration pattern has been well publicized – despite the intense regulatory scrutiny that followed.

Clearly this can cause huge concern for any bank looking to modernize its core. Given this reality, and a strong desire to de-risk migration events, banks have recognized that the core coexistence migration pattern is a more effective path to success.

Coexistence, or running two or more cores simultaneously for a period, is an important issue for banking technology executives. The ability to bridge between cores allows a phased transition from old to new and enables more creative and risk-reducing deployment strategies.

The coexistence pattern aligns migration with modern software practices, allowing banks to deploy, migrate, test and learn from a more controlled approach to smaller portions of their portfolio.

While the coexistence pattern provides a success for migration – the lack of preparation presents significant issues. Too often, migration is treated as a footnote: seen as hindering progress to the new capabilities, features and products that core modernization will deliver.

Banks that expect the process to require little human intervention – and that stakeholders will align at the right time – risk failure.

Our experience in migration shows that it is important to plan for coexistence, especially as the bank grows in size. Coexistence is a complex journey that will be different for each program.

Nevertheless, here is a compilation of thirteen general lessons that delivery teams can use to make the coexistence journey smoother:

1. Embrace coexistence and empower a central team

Recognize coexistence and actively plan for it during your transition stage or states. Don’t dismiss this as a low-level design problem.

Establish a central team of experts to ensure comprehensive planning and decision making. This can be separate and distinct from the business and technical teams that define the target state operating model and architecture.

This team needs to be empowered and have suitable senior sponsorship. Coexistence will have an impact on many teams. Difficult decisions must often be made to keep the program and its stakeholders in alignment while moving forward with the overall change-management strategy.

2. Don’t try to answer all the questions in the beginning

It is impractical to define responses to all coexistence situations at the beginning of a significant change program. The Central Coexistence Team will establish the North Star in terms of coexistence at the start of the programme. From there, they’ll create the necessary implementation path, working through each challenge in bite-sized chunks.

3. Use technology to better support coexistence

Gone are the days of sewing together a manual process that would inevitably put extra strain on operations associates. Instead, use the program’s target architecture to enable technology-centric coexistence.

Banks can be safer knowing that any interim builds can be changed more easily as you transition from one state to another with a more loose architecture. For example, a dedicated service could be set up to serve as a ‘control centre’ for managing coexistence indicators across different systems of record.

4. Identify the control points of your coexistence

Recognize where in your technology stack you can most easily control the data flow needed for coexistence to operate. The fewer points you have to control in order to flip from one coexistence state to another, the better.

In modern architectures, this is less likely to be in the customer or product systems themselves, but rather in the integration layer that serves as the central foundation for the bank.

Access the full paper here.