As of July 2025
Banking cloud migrations fail for one repeated reason: teams treat cloud as a faster data center instead of a fundamentally different computing model, then force banking workloads into assumptions built for web apps.
The cloud-native playbook assumes you can tolerate occasional failure, scale horizontally, and rebuild state from scratch. Banking systems require four-nines uptime, vertical scaling for peak loads, and stateful transactions that cannot be lost. Lift-and-shift a COBOL mainframe to the cloud and you get the worst of both worlds.
The mismatch is about assumptions, not tooling. Web-scale architecture is built to shrug off a dropped request and re-create state. A payment authorization cannot be dropped and cannot be approximate. When that gap is ignored, the migration produces cloud bills on top of mainframe complexity - and the project stalls.
Uptime bar
99.99%
what banking systems require. The cloud-native playbook assumes you can tolerate occasional failure - a different model entirely.
Auth latency
sub-100ms
the payment-authorization budget; multi-region cloud adds latency that kills it. Use edge and caching.
Data gravity
Egress
payment data is massive and sticky - egress costs destroy budgets. Process near the data, not in a distant region.
What actually works
Go hybrid: keep core banking on-premise or private cloud, and use public cloud for analytics, customer-facing apps, and batch. Wrap the mainframe in APIs so you can modernize gradually instead of betting the bank on a big-bang cutover.
Where budgets and latency die
Data gravity: payment data is massive and sticky, and egress fees wreck budgets - so process near the data. Latency: authorization needs sub-100ms, and multi-region hops blow that budget, so reach for edge compute and caching, not a distant region.
The banks succeeding with cloud are not going cloud-first - they are going business-outcome-first, and using cloud where it actually makes sense.
