Cloud migration for banking and financial services
A bank or NBFC moving to cloud infrastructure is not doing the same project as a retailer. The applications are older, the data has rules attached to it, and the regulator has an opinion about where it lives. What follows is how the work is sequenced, the arithmetic that decides your cutover window, and the small number of measurements worth keeping afterwards.
What makes financial services different
Three constraints shape every decision in this sector, and they all show up in the first week.
Data residency is a design input, not a compliance sign-off
The Reserve Bank of India’s 2018 direction on Storage of Payment System Data requires payment system data to be stored in India. The Digital Personal Data Protection Act, 2023 adds obligations around personal data more generally. Neither is something to hand to a compliance team after the architecture is drawn: they determine which regions are available to you, which managed services you can use in those regions, and whether a vendor’s default multi-region replication is an asset or a breach. Decide it first, because reversing it later means rebuilding the data layer.
The core is usually the last thing to move, and sometimes never
Core banking, the loan management system and the general ledger tend to be the oldest, most integrated and least portable systems in the estate. A migration plan that starts with them stalls. A plan that starts with the systems at the edge — the customer portal, the contact centre, reporting, document storage, test environments — delivers something in the first quarter and builds the operational habits the harder migrations will need.
Auditability has to survive the move
Whatever you could previously prove about who accessed what, you still have to prove. In practice this means log retention, access review and change records need designing into the target environment rather than being reconstructed after an audit asks for them.
Sorting the estate before moving any of it
The standard disposition set gives six answers for any application, and most estates use four of them:
- Retire.Applications nobody has opened this year. On most estates this is the largest single saving in the programme, and it costs nothing to act on.
- Retain.Systems that stay where they are, because the regulator, the vendor contract or the remaining depreciation says so. Naming these early stops them being re-litigated every month.
- Rehost.Move the server as it is. Fastest, cheapest per application, and it carries every existing problem with it.
- Replatform.Move it, and change one thing — usually the database onto a managed service, or the OS onto a supported version.
- Repurchaseand refactor are real options, but both are software projects wearing a migration’s clothes. Budget them as such or leave them out of this programme.
The useful output of this exercise is not the classification. It is the dependency map you are forced to build to do it, which is what tells you which applications have to move in the same weekend.
The arithmetic that decides your cutover window
Migration plans slip on data transfer more often than on anything else, and it is the one part that can be calculated exactly before the project starts.
Two consequences follow. If the number is larger than the outage the business will grant you, the answer is not a longer outage — it is pre-seeding the data and replicating the delta, so the cutover moves only what changed since the copy. And if you are shipping physical media because the link genuinely cannot carry it, that decision needs to be made in planning, not discovered in the rehearsal.
Rehearse the cutover against a real copy of the data at least once. The rehearsal is where you find the undocumented batch job, the hard-coded IP address and the certificate nobody owns.
Choosing an availability target you can afford
Availability targets are agreed in percentages and paid for in architecture. It is worth converting the percentage into minutes before anyone signs it.
Each step up the table roughly doubles the cost and complexity of the design: single instance, then multi-zone, then multi-region with automated failover, then active-active with the data problems that brings. The question to answer is not “how much uptime would we like” — everybody likes five nines — but “what does an hour of this system being down actually cost us, and at what point does the architecture cost more than the outage”. Different applications in the same estate will land on different rows, and that is the correct outcome.
What to measure once you are there
Cloud migrations generate an enormous number of available metrics, most of which tell you nothing. Three are worth a standing report:
- Cost per environment, not total cloud spend.A rising total is meaningless on its own. Cost broken down by environment almost always shows that non-production is the thing that grew, usually because nothing turns it off at night.
- Time to restore, measured by actually restoring.A backup job reporting success is evidence that a backup job ran. See why an untested backup is not a backup.
- Change failure rate.The proportion of changes that require a fix afterwards. If it rises after migration, the environment is not yet understood by the people running it, and more training will help more than more monitoring.
Where this fits
This page describes the approach. The service itself is Cloud Migration, and the sector context is Banking and Finance. Migration is usually one phase of a longer programme — Cloud Advisory Services comes before it, and Cloud Managed Services is what happens after the last workload lands.
