At Thought Machine, we invest a lot of effort in helping clients migrate away from their legacy core banking systems.
Accordingly, we have a deep knowledge of modernising banks and the best practices for migrations.
We recently undertook a core migration programme with a client that started and finished within a year. This is impressive in and of itself, though made more so when you consider that this client successfully migrated over three million customer accounts in a phased manner with only a small delivery team aligned to the programme.
This level of execution excellence is not something that we see every day.
With this successful project and many others under our belt, we can share some of the common migration challenges and what the client did well to overcome them and consider how realistic it is for this success story to be replicated by other banks worldwide.
The client operates in a large APAC market and approached Thought Machine because their legacy core banking software did not support the level of product flexibility that they required to meet their product and company objectives.
The client already offered its customers a range of lending products and wanted to migrate its three million existing buy-now-pay-later accounts to our next-generation platform.
As stated, it took less than a year from the beginning of the client’s delivery programme to the conclusion of the final migration. This included scoping and building the migrated product using smart contracts in Vault Core. Smart contracts are a uniquely powerful tool in our platform, enabling the creation and execution of banking products decoupled entirely from the platform code.
Delivering a project at this speed, considering the relative complexity of the scope (a lending product with high volumes), is beyond the norm and well above industry standards. This is the power of smart contracts and their unique ability to replicate existing backbook products quickly.
The following stood out as key differentiators for this client that can help to explain their delivery success:
1. Deep knowledge of the legacy banking products across the team
In most migrations, a key objective is to replicate the behaviour of the legacy product onto a new core.
While that sounds simple enough, when discussing in detail the inner workings of a banking product, there will often be a single point of failure.
In many cases, only one or a handful of people in the bank understand exactly why and how the product works the way it does. This one person (or, at best, a small team) can quickly become a bottleneck, with their time continuously being demanded left and right by newly created programme squads, slowing down delivery.
This particular client had deep product knowledge across multiple stakeholders involved in the programme.
Those leading the Vault Core migration knew intimately the most appropriate tables and columns for retrieving the extracted data because most had been integral in building it.
Questions could be fielded by almost any team member, allowing for immediate feedback and quick decision-making.
Banks looking to replicate this ‘deep knowledge accelerator’ may run on older cores with less readily available knowledge. In these scenarios, upfront investment is key.
You could enable an internal and/or partner team to learn the legacy core before you even start the fully fledged programme; some incentives may be necessary.
Additionally, recognise the reliance on this source system knowledge and ringfence key source SMEs from their day jobs when they are likely to be called upon. Formally bring them into the programme structure, funding this as necessary, to remove the risk of conflict between their programme and BAU roles.
The more people understand how it currently works, the more likely you are to complete your migration quickly and safely. It's as simple as that.
2. Empowered small teams with a clear focus
A core migration is one of the most technically challenging programmes a bank will undertake.
While this means it needs to be carefully managed and watched, it can often lead to slower decision-making and overall progress. Generally speaking, the bigger the bank, the more cumbersome this ‘control at the top’ can become.
Often said but rarely done, this client truly empowered small teams to make decisions quickly. Design and implementation issues and the associated go-forward options were decided upon live by the people who knew what was going on, with the desire to get the migration done consistently being the guiding principle across their teams.
There was minimal need to “escalate to validate” with little direct involvement from the executives. Additionally, minimal purposeful governance and few layers kept things moving quickly when wider involvement was needed.
Empowerment and a clear migration focus can be hard to achieve across a large institution. Conflicting priorities derail progress, with the level of delegated authority getting ever smaller. Replicating this requires a fundamental rethink of the organisational structure and governance to execute the migration and wider transformation. It can be done, but often isn’t.
3. Modern technology paradigms in the DNA
Executing a core-to-cloud migration requires a sound level of technical knowledge and awareness across the bank and deep knowledge and experience in particular domains (for example, running cloud infrastructure).
In many banks today, there may be none or only some workloads across the bank in the cloud, with modern technical knowledge likely only existing within siloed pockets that are often far from the legacy core(s).
Having built most of their technology estate on the cloud, this client already understood what this meant and consequently had a minimal learning curve when adopting Vault Core.
Integrating their new core was less of a discussion. The client self-served through Thought Machine’s Documentation Hub and only asked ad-hoc questions to discuss the pros and cons of integration and migration options.
In short, their architecture was already well aligned with a Vault Core integration. We avoided a protracted architecture debate at the programme's outset and the investment needed to bring it to a minimum viable level.
Clients migrating their core to the cloud must procure and embed the correct skills and knowledge. This accelerates the adoption of the new cloud technology and the design and set-up of the extract, transform, load, and reconciliations pipeline needed to execute the migration. It also drives benefits outside the migration workstream. While not a prerequisite for success, having Cloud in the DNA, for example, quickly adding and removing cloud services as required, is a material accelerator.
4. Simplicity of their technology stack
Often, clients start with an aim to migrate to a new cloud core but quickly see the arms and legs of the migration grow as upstream and downstream dependencies complicate the migration routine.
Migration complexity typically increases with the amount of interconnected components in the legacy environment. Unpicking tightly coupled legacy services and migrating them to a loosely coupled set of distributed services is a hugely valuable exercise and sets the bank up for success.
This client had kept their loosely coupled technology stack around the legacy core simple—or at least simpler than most traditional banks. This foundational simplicity was beneficial for delivery, with fewer data movements and upstream/downstream data decisions needing to be made.
There is little argument that this is harder for other banks to replicate cost-effectively ahead of their core migration. Simplifying the technology stack around the core, often including a degree of hollowing out the core, is a multi-year journey distinct from the core migration.
Banks that do not have this simplicity in their technology stack today need to carefully and realistically plan their programme. Attempting to do it all at once will, more often than not, lead to a painful programme for all.
5. Continuous migration of accounts in a simpler state
Many technology executives have dreamed about a continuous or streaming core migration for years. In reality, many have started with this approach but quickly retreated to a phased or big-bang migration, often worried about the lack of ‘control’ with such an automated process.
This client attempted such a routine, and while it did not work perfectly, it did help to simplify the migration.
In their migration process, the client frequently checked the state of the non-migrated accounts, identifying those in a simple state with fewer data points, specifically account balances, that needed migrating.
This migration approach simplified the entire process, including data mapping, data quality, transformation, load, and reconciliations. The product's cyclical nature meant multiple opportunities for the account to be ‘caught’ by the process and successfully migrated.
At the end of the programme, a one-off ‘tidy up’ or more traditional migration was completed for the smaller number of non-migrated accounts that never reached this simple state.
Banks should aspire to migrate most of their accounts when in a simpler state. Big-bang migrations are rarely advised, and phasing the migration via this approach is not a major leap forward.
The trickier part is gaining buy-in from business and technical leadership to execute this less ‘fixed scope’ approach successfully.
6. Willingness to take a level of risk
For many years, risk has been something to try and fully mitigate or eliminate when it comes to a core migration, for good reason. While this client did not seek out risk, the threshold for accepting it as a trade-off for a simpler and quicker migration was much higher than we have traditionally seen.
Specifically, during the latter phase of the programme, the migration for a proportion of customers went so well and so fast that the client opted to complete a subsequent load of more than double the volume of accounts originally planned on the same night. Effectively, they brought their production migration plan forward to use the extra time that had appeared in their schedule of events. This ‘upside’ tactic is not unheard of when completing core migrations. However, this relative volume is outside the norm and not something other clients would traditionally adopt, where sticking rigidly to predetermined loads is the norm - come rain or shine.
So what can other clients thinking of a core migration take away?
Firstly, none of the six points above are groundbreaking or new. While the client benefitted from having the right foundations to swiftly execute at scale, the standout themes were the decisions made up front that were consistently followed through and the quality of the team. This client walked the talk to use two maxims, and a great team led to great results.
Stepping back, though and as mentioned already, it wouldn’t be realistic to say that all banks globally can replicate this result. Large organisations often come with complex problems outside the control of the programme leadership. However, despite this, all banks planning their core migration can:
- Instil a top-to-bottom bias for core migration action/execution in the face of ambiguity. Complex migrations can be easily derailed without a clear and consistent focus on achieving outcomes in the face of adversity.
- Be realistic about the trade-offs. There is no such thing as a free lunch. Tough decisions need to be made to deliver great outcomes.
- Find and empower business and technical SMEs. This doesn’t mean recruiting an army but leveraging and investing in the specific internal and external skills needed to execute your migration. Recognise those SMEs that are already critical to your operation and recognise the additional support needed to execute a core migration.
This client deserves huge credit for their achievement. They had a unique opportunity to execute a core migration swiftly, and they jumped at it with both hands. While this likely cannot be fully replicated by all, every bank can critically reflect on their migration plans to incorporate these lessons learned and ultimately accelerate progress and outcomes.
