The costs and complexity of legacy banking technology have firmly established the need for financial institutions to modernise their systems.

Banks must move away from legacy infrastructure that constrains innovation and prevents them from providing the real-time, personalised banking experiences that customers have come to expect. Banks can unlock greater flexibility, enhanced resilience, and lower operational costs by moving core technology into the cloud.

In the past, banks may have adopted a big bang migration approach to move to a new core platform. This would entail a single migration phase in which all product data was extracted, transformed and loaded in the shortest time possible.

This approach was risky but more feasible in the era of 9-5 banking schedules, with customers accepting a lack of service for long periods at night and over weekends. In many cases, the batch-based nature of legacy cores only compounded the difficulty in bridging between old and new when phasing migration events.

Due to the delivery methodologies of the day — where the scope was delivered as a big bang, with only the most innovative banks managing releases quarterly — it often made sense to migrate data in this way.

The dissatisfaction customers have had with frequent failures of the big bang migration pattern has been well publicised – notwithstanding the intense regulatory scrutiny that follows.

Understandably this can cause enormous concern for any bank looking to modernise its core. Given this reality, and the strong desire to de-risk migration events, banks have accepted that the core coexistence migration pattern is a more effective route to success.

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

The coexistence pattern aligns migration with modern software practices, allowing the bank to deploy, migrate, test, and learn from small tranches of its portfolio in a far more controlled approach.

While the coexistence pattern offers a breakthrough for migration – lack of preparation presents significant issues. Too often, migration is treated as a footnote: seen as hindering progress towards new capabilities, features and products that core modernisation will provide.

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

Our experience in migration shows that planning for coexistence is critical, especially as the size of the bank increases. Coexistence is a complex journey that will be different for each programme.

Nevertheless, here’s a compilation of thirteen common lessons that delivery teams can use to smooth the coexistence journey:

1. Embrace coexistence and empower a central team

Recognise coexistence and actively plan for it during your transition state or states. Don’t leave it as a low-level design issue.

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

This team needs to be empowered and have the appropriate senior sponsorship. Coexistence will have a ripple effect across many teams. Difficult decisions must be made, often at pace, to keep the programme and its stakeholders aligned while moving forward with a holistic change-management strategy.

2. Don’t try to answer all questions at the start

Defining the answers for all coexistence situations at the beginning of a significant transformation programme is impractical. The central coexistence team will set the north star in terms of coexistence early in the programme. From there, they will lay the required implementation path, working through each challenge in bite-sized chunks.

3. Use technology to better support coexistence

Gone are the days of stitching together a manual process which would inevitably place additional pressure on operations colleagues. Instead, utilise the programme’s target architecture to enable technology-centred coexistence.

Banks can be safe knowing that any interim builds can more easily be changed as you transition from one state to another with a more loosely-coupled architecture. For example, a dedicated service could be stood up to serve as the ‘control centre’ for managing coexistence indicators across various systems of record.

4. Identify your coexistence control points

Identify where in your technology stack you can most easily control data flows needed to operate in coexistence. The fewer points you must control 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 operates as the central foundation for the bank.

Access the full paper here.