Core banking system migration is anything but easy. Moving from a legacy system to a cloud-based, future-proof core banking solution can be especially daunting. Our team at Ikigai Digital recently supported Judo Bank, a leading business bank in Melbourne, Australia, to successfully migrate its system from Temenos T24 to Thought Machine Vault Core. After successfully completing the migration of three products for the bank, we looked back at the process to highlight some key learnings.

Focus on Financial Behavior, Not Just Data

While data transfer is often considered the most challenging task in the migration process, it is critical not to overlook the financial behaviour and logic matching between the legacy system and new platform, given their huge technological differences. With Ikigai’s Subject Matter Experts (SMEs), we quickly realised that understanding data structures alone wouldn’t suffice to deliver the project. Data alone rarely reflects the complexity of the business logic that drives the product. During this migration from Temenos T24 to Thought Machine Vault Core, SMEs from both systems play a vital role in translating the intricate business logic of the product into Vault Core’s Smart Contract rules. Instead of merely replicating (partly undesired) product behaviour and function, our ultimate goal was to ensure Vault Core’s dynamic, rule-based system could deliver the same business and financial outcomes without disrupting the expectations customers had developed with the legacy system.

And what does that mean exactly? Take for example the interest accrual data between T24 and Vault Core. Depending on how real-time rules are applied, the two sets of data can behave completely differently. In T24, interest is accrued on a predefined schedule, with weekends calculated in advance due to its 5-day system, while the bank’s desired target design was a 7-day system, which was applied to the Vault Core smart contract design. Such seemingly subtle/minor differences must be addressed and adjusted to prevent duplicate accrual during the course of migration over weekends. By addressing these differences with careful planning and solution design via expert collaboration, we ensured a smooth transition and maintained the integrity of the financial products, minimising disruption to customers.

Think Outside the Box for Testing and Validation/Reconciliation of Migrated Outcomes

Migration testing must go beyond data transfer, and historical data is crucial in this case to reflect actual use cases and potential risks. In our migration to Thought Machine Vault Core, we followed a comprehensive multi-step test pyramid, including unit tests, simulation tests, end-to-end tests, fast-forward tests, manual QA, and UAT.

To achieve even higher accuracy, we introduced a creative approach: post-migration simulation and comparison. This involved simulating account behaviour after the migration and comparing it with projected schedules from the legacy T24 system. This method uncovered discrepancies in migrating parameter values that weren’t initially obvious. While a parameter may seem correct, the real test was carried out with an aim to see if the long-term financial outcomes of the old and new systems matched. We ran simulations through the end of the product life cycle, comparing changes across both systems. Incorrect mapping would be signalled if discrepancies emerged. This approach allowed us to test both immediate and future financial behaviours, catching potential issues early to prevent operational disruptions.

This way, we ensured two things: Accuracy of the migration and ongoing reliability of the new system. Thinking outside the box during testing helped us navigate through a complex migration, ensuring a seamless post-migration performance and avoiding costly surprises.

Enable Long-Running Parallel Runs to Surface Issues

Running both old and new systems in parallel for an extended period also helps limit the “blast radius” of any issues that arise during the migration process. Each step in the migration should include key life cycle events, such as end-of-month processes, which often expose latent defects that may arise at a much later stage. We recommend each stage of the migration last about a month to capture the critical end-of-month cycles, so that validation can be done without the pressure of an immediate cutover, thereby reducing the risk of post-migration disruptions and remediations at scale.

Our recommended migration approach includes the following stages:

1. Individual Pilots (NTB - New To Bank Accounts) on the New Stack: Start by onboarding new accounts onto the new system. This provides a clean slate to monitor how the system performs under smaller, controlled conditions.
2. Cutover of NTB Accounts to the New Stack: Gradually transition all NTB accounts to the new platform, ensuring stability and addressing any early-stage issues before migrating larger volumes.
3. Small-Scale Migration: Migrate a select number of existing accounts to the new system, but make sure to include at least one account from each product type. This is crucial for identifying migration-specific bugs that might not surface during regular usage.
4. Gradual Ramp-Up of Larger Migrations: Slowly increase the number of accounts migrated in each product type, ramping up volumes incrementally. This phased approach allows for continuous monitoring and validation of system performance as the load increases, while keeping any potential issues contained.
5. Final Cutover and Decommissioning of the Old System: Once the system has proven stable at scale, proceed with the full cutover and begin decommissioning the legacy system. By this point, the likelihood of defects will have been minimized through careful, staged migrations and rigorous parallel validation.

This gradual ramp-up allows for early detection of issues, giving the team ample time to resolve them in manageable chunks, leading to a smooth transition and long-term success for the migration.

Invest in Custom Tooling and a Migration ETL

When it comes to migrating large volumes of complex financial products, one of the biggest lessons we learnt is this: investing in custom-built tools is essential to automate key processes, reduce manual efforts and minimise human errors – because let’s face it, even the smallest mistake in financial data can come with a hefty price tag.

With this in mind, we developed the Ikigai Migration Accelerator ETL pipeline, equipped with reconciliation and reporting features, which allowed us to swiftly detect and resolve data discrepancies, ensuring a smooth transition of accounts and transactions. Ikigai Digital Migration Kit

Custom tools not only save time but also enhance accuracy and efficiency, mitigating risks throughout the migration. As data landscapes grow more complex, organisations that invest in specialised solutions will ensure scalable and reliable migrations with minimal disruption.

Stream-Aligned Teams and Continuous Cross-Team Collaboration

Effective team structures are essential for successful migration projects. Traditional setups, where product development, migration, and data management are handled by separate teams, may seem efficient in theory. However, this fragmented approach often results in delays, increased defects, and costly errors. Dependencies, frequent hand-offs, and, most critically, knowledge gaps, particularly regarding the financial behaviour of products, can derail even the most well-planned migrations. Misaligned assumptions become especially problematic when dealing with complex financial products, leading to errors in data transformation.

A more effective strategy is stream-aligned squads, where each team manages both product development and migration transformation rules within a specific banking domain (e.g., Lending or Deposits). This cross-functional structure minimises hand-offs, closes knowledge gaps, and ensures higher quality outputs. These squads are supported by a migration enablement team and a data platform enablement team, who provide the tools for data access, loading, and reconciliation.

By aligning teams with business streams, all members develop a deep, unified understanding of both the legacy and target systems. This alignment reduces transformation errors, lowers failure rates, and fosters greater ownership. As a result, teams work more efficiently, delivering faster and with fewer defects.

Ultimately, stream-aligned teams not only accelerate delivery but also enhance accountability and collaboration. This approach ensures a smoother, more reliable migration—one where quality and speed go hand in hand.

Summary

In the end, migrating a core banking system from a legacy platform like Temenos T24 to a modern solution like Thought Machine Vault Core isn’t just about transferring data, it’s about preserving the trust customers place in their financial products. By investing in custom tools, running parallel systems for an extended period, and forming stream-aligned squads around specific business domains, we cut down on errors, kept disruptions in check, and ensured financial behaviors remained consistent. These strategies not only safeguard the integrity of complex financial products but also encourage stronger ownership and tighter collaboration, paving the way for faster, smoother, and more reliable migrations in the long run.

Ikigai's Migration Service offerings:

• Digital Banking Expertise
  • Specialised knowledge in core banking system migration to the cloud.
  • Track record on successful migration from legacy core banking to Thought Machine Vault Core
  • Deep understanding of industry regulations, compliance and security standards
• Our Methodology
  • Engaging stakeholders throughout the migration journey
  • Continuous communication, feedback and refinement of solutions
• Ikigai Toolkit
  • Legacy core to Thought Machine Vault Core Migration Data Dictionary
  • Ikigai Migration Kit (Extract-Transform-Load-Reconcile-Report), more information please refer: Ikigai Digital Migration Kit
• Ikigai Simulation Tool
  • Simulate serval accounts within different categories.
  • After running serval days, If the running behaviour are the same with the legacy system