PUBLISHED DATE: 2025-08-25 05:29:51

Purposeful Coexistence in Your Journey to a Digital Core

March 2023

Prepared by:
Fraser Morant, Migrations Lead (APAC) and Ben Harrison, Migrations Lead (UK)
Abhishek Bhattacharya, Vice President Technology, Publicis Sapient
Cian Ó Braonáin, Senior Director Product Management, Publicis Sapient


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. By moving core technology into the cloud, banks can unlock greater flexibility, enhanced resilience, and lower operational costs.

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.


Transition States Overview


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, we’ve compiled some 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.
  5. Tactically invest in legacy
    • Changes to the source system or data are likely needed to enable a successful transformation. For example, additional flags or tags may be required on legacy accounts to indicate which have been migrated.
    • Plan these changes early with the teams supporting the legacy core—including third parties.
  6. Separate migration and coexistence
    • Migration, or more specifically, data migration, is moving data from A to B: legacy core to new core. Conversely, coexistence is a state, or set of states, in which the bank will operate for a period ranging from several weeks to several years.
    • It is unlikely that the migration team, focused on managing the build of the ETL pipeline, will have the required knowledge of the bank to enable and implement coexistence across the stack successfully and independently. While migration and coexistence have interdependencies, they each have distinct and separate objectives and should be treated as such.
  7. Building a common data layer
    • Consider building a common data layer that aggregates data and feeds downstream systems like ledger and reporting. This will minimise the downstream impact and ensure easier adoption and execution of the coexistence programme.
  8. Create a routing layer
    • A routing layer is needed to feed data into the core banking systems. This is essential to successful coexistence. A data cache solution will allow the routing layer to make efficient and transparent routing decisions.
  9. Consider domains and capabilities
    • It is essential to think about the domains and capabilities within the bank and start building some critical enabler domains like customer or payment. We often refer to this as ‘hollowing out the core’. This ensures certain capabilities and domains are already disaggregated, enabling ready-to-use modules that both legacy cores and new core banking systems can use.
  10. Invest in automated reconciliation
    • The need to reconcile data sources will materially increase during coexistence. As a programme, make sure to formally invest in building regular and repeatable operational and financial reconciliation capabilities that combine varying data sources seamlessly by utilising the latest best-of-breed technology.
  11. Go deep on the coexistence data analysis
    • Don’t run on assumptions and perceived understandings of your core legacy data and which potential coexistence states you do and do not need to cater for. Extract and profile your full data sets to determine the approach that minimises coexistence complexity and customer and colleague impact. Knowing your data will better inform the unit of migration that drives the data tranches. For example, will each tranche represent a customer set, product set, or perhaps another attribute (e.g., a legal entity)?
  12. Test and prove coexistence in production early
    • Depending on your local risk and regulatory landscape, there may be an opportunity to de-risk any cutover to a coexistence state. For example, could you move a small number of customers impacted by coexistence into the live environment to prove the end-to-end behaviour before moving to a larger and more formal coexistence state?
  13. Plan for decommissioning of the legacy estate early
    • This is critical to ensure the cost savings horizon for the core modernisation programme is understood, tracked, and happening in line with the earliest possible opportunities in the migration plan. This is vital to ensure stakeholder buy-in on the journey and to recognise the full benefits of the core modernisation programme.

It is now the case that the cloud is the only viable option for technology infrastructure. Therefore, the question of moving to the cloud is critical, given the complexity of bank technology estates today. We will likely see fewer big bang migrations as large banks look to digitise their core; this approach will be reserved for smaller markets and more specific products. In most cases, coexistence is here to stay and should be treated as a first-class concept across the programme on your journey to a new digital core.

To learn more about how we’re supporting banks in Asia and beyond with coexistence and migration programmes, read more in our recent joint whitepaper with IDC: https://info.thoughtmachine.net/clear-path-ahead.


Thought Machine and Publicis Sapient

Through our work with Publicis Sapient, we’re helping banks to improve customer outcomes, reduce costs, and drive innovation. Discover how our partnership can help you. Learn more at https://xbank.publicissapient.com/partners/thought-machine


About Thought Machine

Thought Machine has developed the foundations of modern banking with its cloud-native core banking and payments technology. Its cloud-native core banking platform, Vault Core, is trusted by leading banks and financial institutions worldwide, including Intesa Sanpaolo, ING Bank Śląski, Lloyds Banking Group, Standard Chartered, SEB, Lunar, Atom bank, Curve, and more. Vault Payments is a cloud-native payments processing platform—launching first with card processing on the Mastercard network, with full coverage available from 2023.

The Vault platform has been written from scratch as an entirely cloud-native system and gives banks full control to build any product required to flourish in a rapidly changing world.

For more information, visit thoughtmachine.net


About Publicis Sapient

Publicis Sapient is a digital business transformation company. We partner with global organizations to help them create and sustain competitive advantage in a world that is increasingly digital. We operate through our expert SPEED capabilities: Strategy and Consulting, Product, Experience, Engineering and Data, which combined with our culture of curiosity and deep industry knowledge, enables us to deliver meaningful impact to our clients’ businesses through reimagining the products and experiences their customers truly value. Our agile, data-driven approach equips our clients’ businesses for change, making digital the core of how they think and what they do. Publicis Sapient is the digital business transformation hub of Publicis Groupe with 20,000 people and over 50 offices worldwide. For more information, visit publicissapient.com.


www.thoughtmachine.net
www.publicissapient.com