Most cloud programs in banking begin with a savings number. Somebody models the current infrastructure spend, applies a percentage, and the business case gets signed. Two years later the workloads have moved and the monthly invoice is higher than the data centre it replaced.
Nobody lied in the business case. The math was just applied to the wrong variable.
Simply Moving Servers is Not Modernizing
The quickest way into the cloud is to pick up what you have and set it down somewhere else. Same application, same database, same architecture, different landlord. Projects that take this route usually finish close to schedule, which keeps everyone happy right up until the first full quarter of billing.
Here is the mechanic behind it. On premises, a server running at 12 percent utilisation at three in the morning costs nothing extra. You already bought it. The waste is invisible because it was capitalised years ago. In the cloud, that same idle capacity bills by the hour, every hour, indefinitely.
Autoscaling is supposed to solve this. It only works if the application can genuinely run on two instances overnight and forty at peak. A monolithic card management system written in 2004 cannot. It was designed for a world where scaling meant ordering a bigger box and waiting six weeks for delivery.
So a workload that was quietly inefficient in the data centre becomes an inefficiency you now pay for, line by line, on a statement someone in finance reads every month.
The Rising Bills Due to Unattributed Spend
Then there is the operating side. On-premises, a small number of people controlled provisioning, and getting new capacity meant asking them. In the cloud, a development team can spin up an environment on a Tuesday afternoon and forget it exists. Multiply that across forty teams and the rounding error stops being a rounding error.
Untagged resources are the usual culprit. If you cannot attribute spend to a team or a product, you cannot credibly ask anyone to reduce it. Finance sees one large number, engineering sees no signal, and the conversation goes nowhere for another quarter.
Storage tiering is the other one. Transaction logs that must be retained for seven years sit in hot storage because nobody wrote a lifecycle policy. That is a configuration choice, not a cloud problem, and fixing it is often worth more than any renegotiation with the provider.
Doing It The Right Way
The institutions that get this right tend to do three fairly unglamorous things.
They assess before they move. Which applications benefit from elasticity, which are fine where they are, and which should be switched off rather than migrated. A surprising share of most legacy estates consists of systems nobody has logged into in years.
Migrating those is pure cost transfer with extra project risk.
They pick refactoring targets deliberately. Not everything needs to become microservices. Usually a handful of components drive most of the compute cost and most of the release friction, and those are the ones worth breaking apart first. The rest can stay as they are until there is a reason to touch them. This sequencing is broadly why structured cloud modernization services open with a readiness assessment and a total cost of ownership model rather than a migration calendar.
And they give cost an owner. Someone reviews the number monthly and has the authority to turn things off. Without that, optimisation happens once, gets celebrated, and then decays over the following year.
The Uncomfortable Truth
Cloud economics only work when the software above them is built to take advantage of them. Elastic infrastructure underneath rigid applications gives you the cost profile of renting with none of the flexibility of owning.
That is a harder conversation than a migration timeline, because it means conceding the application portfolio needs work and not just the hosting arrangement. It is also the conversation that decides whether year two of the program reads better than year one.
Migration is a project. Cost efficiency is a habit. Programs that confuse the two end up explaining an invoice to a CFO who was promised the opposite.
About Author
Derek Francis
Derek manages content marketing at Opus Technologies, a domain-native engineering partner for banks, payment providers, and fintechs, and writes on the various aspects of financial institutions navigating change in a real-time, digital-first world.
Top comments (0)