Core banking migration, and the team that does not fail it

The Indian landscape

Indian banks run a mix of long-established core platforms and, increasingly, newer cloud-native systems alongside them.

The practical consequence for hiring is that the skills pools barely overlap. An engineer with ten years of Finacle customisation and an engineer who has built on a cloud-native core are solving different problems with different tools, and a brief that asks for both is describing a very small number of people.

A second consequence worth stating: most Indian migrations are not a clean replacement. They are a coexistence, where the new core takes new products or a new customer segment while the old core continues running the back book, sometimes for years. Designing and operating that coexistence is the actual job, and it is more demanding than either platform alone.

Why banks migrate, and why they delay

The reasons to move are consistent: product velocity, because launching a new deposit or lending product on a heavily customised legacy core takes quarters rather than weeks; cost, both licensing and the specialist maintenance skills that get scarcer each year; resilience, which the regulator now has firm views on; and the integration surface, because partner and embedded-finance arrangements assume APIs the older platforms were not built around.

The reasons to delay are equally consistent, and more persuasive in the room: the current system works, the migration risk is existential, the benefits are diffuse, and nobody's career improves by volunteering to run it. This is why migrations tend to be triggered by an external forcing function, a regulatory finding, a vendor end-of-support date, or a merger, rather than by a strategic decision taken calmly.

What the 2026 resilience directions changed

The Reserve Bank of India (Commercial Banks - Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, issued on 31 July 2026 and effective immediately, apply to commercial banks other than Small Finance Banks, Payments Banks and Local Area Banks, with foreign banks operating through branches on a comply-or-explain basis for selected chapters.

They matter to a migration because they raise the bar the target state has to clear.

The last row deserves attention from anyone planning a programme. The security assessment of your migration is given by someone who does not report to the person running it, and who reports independently to the board. Programmes structured on the assumption that security is an internal technology matter encounter this late.

The migration patterns

Big bang. Everything moves in one cutover weekend. Lowest total cost, shortest coexistence, and the highest risk, because there is no meaningful rollback once customers transact on the new system. Still used, mostly by smaller institutions where the account count is manageable and the product set is simple.

Phased by product or segment. Move savings accounts, then current accounts, then term deposits; or move one region or one customer segment at a time. Lower risk per event, but creates a long period where customer data spans two systems and reconciliation between them becomes a permanent function.

Strangler, or coexistence. The new core takes all new business while the old core runs the back book, with a routing and aggregation layer in front so customers and channels see one bank. The old system is retired when its book naturally depletes or is migrated last. This is the dominant pattern for banks with a long tail of legacy products, and it trades a short sharp risk for a long operational cost.

Parallel run. Not an alternative to the others but the verification method for all of them: run both systems on the same inputs and compare outputs daily until they agree. It is the only honest proof that the new system does what the old one did, and it is almost always the first thing compressed when the programme slips. Programmes that cut parallel run discover their differences in production, with customers.

Where migrations actually fail

Data quality, which is the main one. A twenty-year-old book contains accounts with no valid address, interest computed by a rule nobody can now explain, products withdrawn a decade ago with a handful of customers still holding them, manual adjustments posted by people who have retired, and balances that are correct but unreconstructable from history. The new system has validation rules. The old data will not pass them. Every exception then needs a decision: fix, transform, carry across as-is with an override, or leave behind. There are usually tens of thousands of these.

Interest and charge calculation differences. The new core computes interest correctly by its own rules, which produce a slightly different number from the old core on some accounts. Slightly different, multiplied by the book, is a customer-facing and regulatory problem. Finding these before cutover requires a full recomputation comparison, which requires the parallel run.

The integration estate. A core system typically has between fifty and three hundred integrations: channels, payment rails, reporting, regulatory returns, the data warehouse, partner interfaces, and a long tail of small internal tools that nobody has documented. The inventory is always incomplete, and the items missing from it are discovered in production.

Batch and the daily cycle. End-of-day processing, interest accrual, charge application, regulatory extracts, statement generation. The online path gets the testing attention because it is visible. Batch is where the cutover weekend overruns.

Reconciliation during coexistence. Two systems holding parts of one bank must agree, continuously, and proving it is a daily operational function for the duration. This is the same discipline as reconciliation and breaks, applied internally rather than against external parties, and it is routinely under-resourced because it is seen as temporary.

The rollback that does not exist. Once customers have transacted on the new system, rolling back means reversing real money movement. Most programmes have a rollback plan on paper and a point of no return in practice, usually a few hours into the cutover. Knowing precisely where that point is, and who decides, is a programme discipline rather than a technical one.

Who you need

The person who matters most is the first row, and the qualifier is finishing. A great many people in Indian banking technology have worked on a core migration. A much smaller number have taken one through cutover, parallel run and decommissioning of the legacy platform. Those people are identifiable, they are employed, and they are approached individually. The method is described in how we search.

How to assess

Ask what they decommissioned. The clearest question in this domain. A migration that has not retired the old system has not finished, and a large share of programmes never do. Candidates who have switched off a legacy core remember the date.

Ask about the data exceptions. How many, how they were categorised, who decided, and how long it took. Specific numbers indicate real ownership. Vague answers about data cleansing indicate someone who was adjacent to the work.

Ask what they found in parallel run. Every parallel run finds differences. A candidate who says theirs matched immediately either did not run one properly or is not telling you about it.

Probe the cutover decision. "Who made the go or no-go call, on what evidence, and did you ever call no-go?" Programmes that have never deferred a cutover have usually been lucky rather than disciplined.

Test the coexistence thinking. "You will run two cores for three years. What does that cost you operationally?" Strong candidates immediately discuss reconciliation, reporting consolidation, dual skills and the risk of the legacy platform becoming unmaintainable.

Check the resilience understanding. Ask how they would meet a near-zero recovery point objective in the target design. This is now a regulatory requirement rather than an aspiration, and a candidate who treats it as a post-migration concern is planning a rework.