Written by:
Last Published:
15 September 2026
•
Can you really save 40–50% by moving to cloud?
Yes. But not how you think.
Most companies talking about cloud savings describe it like is some kind of physics: "Move from expensive on-premise infrastructure to scalable cloud, and the costs will drop." Clean. Also logical. But wrong. The reality is messier. It's less about the technology and more about what you're actually paying for right now.
But most organisations have no idea of this. They see one line item for "infrastructure costs" and call it a day. Then they try to modernise without mapping what's hidden, like licences locked into multi-year contracts, redundant hardware, an ops team that exists specifically to keep the lights on in legacy systems. Until you pull those threads, modernisation looks risky. The good news: it is, until it isn't.
That's where this story starts. TrustPortal, a UK-based fintech and automation platform, was burning money on legacy infrastructure. They didn't set out to save 40–50%. What they did was to understand what they were actually paying for, and that clarity changed everything.
Here's what most legacy costs really look like. Let's split them three ways: software licenses (often locked into multi-year contracts at penalty rates), infrastructure and hosting (sometimes redundant, always historically expensive), and operations labour (the invisible tax). Most companies don't measure labour as a cost driver and they should. An ops team dedicated to keeping legacy systems running is dead weight against cloud-native teams that operate through automation.
TrustPortal was mid-size and global. Their legacy infrastructure looked standard: enterprise databases, legacy application servers, on-premise storage, a managed hosting arrangement. But here's what made the cost invisible: it was scattered. Licensing lived under IT budget, infrastructure under facilities, and labour under operations. Finance couldn't see the full picture, so leadership couldn't justify modernisation.
Most legacy costs break down into three patterns:
Add those up. Most mid-size companies have multi-million-pound infrastructure that isn't generating competitive advantage. It's just... there. Running.
Most companies hide this cost across multiple budgets. You probably do, too.
Systematic modernisation starts with ruthlessness. Which systems generate revenue? Which are overhead? Which are so entangled with compliance that moving them would be regulatory suicide?
TrustPortal faced a real constraint: their payment-processing core was locked into legacy infrastructure for regulatory and audit reasons. Rearchitecting that for cloud would've taken years and cost millions. That wasn't the move. Instead, they split their workloads using a simple framework:
Move to cloud: TrustPortal's core RPA and automation platform, customer dashboards, internal reporting tools, employee productivity systems. These had no compliance lock-in. They were built on modern architectures (Angular, NodeJS, containerised deployments on cloud infrastructure). They generated business value and were customer-facing.
Keep legacy: Payment processing. Core transaction handling. The regulatory burden was too high. The risk of a failed migration was unacceptable.
Hybrid: User identity systems and fraud detection. These needed to talk to both legacy and cloud systems, so they split the workload: cloud for the user-facing parts, legacy for the sensitive core.
The result: 70% of their infrastructure moved to cloud. 30% stayed legacy. Hybrid architecture.
Why does this split matter? Because it's realistic. Most companies assume "cloud migration" means "everything goes to cloud." It doesn't. It can't, if you want to keep revenue flowing and regulators happy. The fintech's hybrid approach meant they could modernise aggressively where it was safe and strategically where it mattered most. Licensing savings would come from the 70% they moved. Everything else was risk management.
The technical migration was ambitious but methodical. It took months, not years, and it required a plan, budget, and team bandwidth dedicated to the effort.
Here's what the modernisation involved:
Technical migration: Data replication, application refactoring (especially the move to modern frameworks like Angular and NodeJS), testing, validation. They used an Agile Development Process with multiple waves to reduce risk and gather feedback.
Parallel running: The fintech ran legacy and cloud side-by-side for an extended period. Why? Insurance. If the cloud deployment failed catastrophically, they could flip back to legacy in hours, not days. That safety net meant the team could move faster because they weren't terrified of irrevocable decisions. The psychological value of an escape hatch is underrated.
Team retraining: The ops team knew legacy infrastructure. They didn't know Kubernetes, cloud observability platforms, cost management tools, or CI/CD pipelines. The company invested in external training, internal workshops, and gave the team time to learn. Some people left during this phase: too much change, too fast. Others stayed and became architects instead of infrastructure janitors.
Tooling switchover: Moving from legacy monitoring and logging to cloud-native tools was noisier than expected. The new tooling had more alerts. The team had to tune, configure, and learn what "normal" looked like in cloud systems.
Contingency: Unexpected cloud architecture redesigns, data transfer costs, performance tuning that required rearchitecting application queries. Real money, unglamorous expenses that the business case had to absorb.
But here's what surprised them most: their cloud bill was higher than expected in month one. Data transfer costs were steep. They over-provisioned resources while tuning performance. The ops team didn't know how to optimise cloud costs yet (different paradigm: you're paying for compute, not hardware). So it took months to dial in actual cloud-efficient configurations. This is the gap between "we moved to cloud" and "we're running cloud efficiently," which most companies miss.
TrustPortal's cloud modernisation delivered 40–50% operational cost reduction, which is the result of systematic, methodical work across multiple dimensions.
Where did the savings come from? The typical pattern looks like this:
Licensing: Multi-year legacy contracts ended. The company didn't renew them. Costs eliminated.
Infrastructure: Cloud hosting for 70% of their workload, once optimised, cost less than on-premise infrastructure plus the managed hosting arrangement. Not as dramatic as you'd hope, but real.
Labour redeployment: The company didn't lay off the ops team. They redeployed them. Team members moved into platform engineering (building infrastructure-as-code pipelines, internal tooling), site reliability engineering (observability and incident response), and other higher-leverage roles. Same headcount, different output. That freed up capacity for new projects. Not "savings" in the accounting sense, but value creation that didn't exist before.
Operational efficiency: Automation-first deployment pipelines, predictable scaling, fewer manual interventions. Incidents dropped. Time spent firefighting legacy infrastructure decreased. That compounds over time.
The 40–50% range (rather than a single number) reflects the reality that Year 1 had one-time costs (migration, retraining, contingency). Year 2 onwards is more predictable. Plus, the company grew their cloud usage (new features and platform capabilities) but growth didn't proportionally increase costs. This happened because cloud scales, but legacy doesn't. That leverage is where the long-term wins come from.
Cost isn't the only measure. Operations also changed fundamentally.
Before: the ops team was reactive. Deployments were manual, scripted, error-prone. Monitoring was alert-storm chaos: too many false positives, too many pages for things that resolved themselves. Scaling required hardware procurement and budgets approved months in advance.
After: automation-first. Continuous deployment pipelines running containerised applications on cloud infrastructure. Predictable scaling (cloud handles it). Monitoring is noisier initially, but once tuned, it's actually intelligent. Incidents are faster to respond to because the team isn't context-switching between legacy firefighting and new work.
The staffing shift: four legacy ops engineers became two platform engineers, two site reliability engineers, plus some contractor support that could be dialled up or down. Same headcount (mostly), different leverage. The platform engineers own infrastructure-as-code, CI/CD pipelines, internal tooling, and containerisation strategy. The SREs own observability and incident response. Both roles are high-impact, hard to replace. The old roles were execution-heavy, low-impact.
The hidden win: time freed up by automation. The platform team could now own more of the application infrastructure. Features shipped faster and customer-impacting incidents dropped 60%. That compounds over time.
The challenge: cloud observability is different, the logs are noisier and traces are complex. The team had to learn new mental models for debugging distributed systems and containerised deployments. There were months where "we're getting more alerts" felt like a step backwards. It wasn't, they were just seeing what legacy infrastructure had been hiding.
If they ran this project again, four things would change:
Map your true legacy costs first. Before you can justify modernisation, you need to know what you're modernising away from. Start with an audit: licensing, infrastructure, labour, everything. Put it in one spreadsheet.
Start with an easy win. Don't move your revenue-generating core first. TrustPortal was smart here: they started with internal tools and customer dashboards while building their new cloud-native platform in parallel. Low risk. High learning. If that pilot project had failed, they'd lose months and money, but not customer trust. Pick one workload or system that's isolated, non-critical, but expensive to run. Modernise that first. Learn and then scale.
Run legacy and cloud in parallel longer than you think necessary. The psychological value of an escape hatch is worth the cost. That safety net meant the team could move faster because they weren't terrified of irrevocable decisions. Budget for it upfront.
Invest in team retraining and repositioning early. This was the hardest part. Infrastructure teams built their identity around "keeping systems running." Cloud modernisation obsoletes that identity. You're asking them to learn new tools, new paradigms, and accept that their old expertise is suddenly less valuable. TrustPortal did this well: they reframed it as an opportunity to do higher-leverage work (platform engineering, SRE, infrastructure-as-code). Not everyone bought it. Some left. That's normal. But the ones who stayed became architects. So, invest in that transition. It pays back.
Systematic cloud modernisation makes sense if:
If all four apply to you, modernisation is probably worth exploring. If only one or two, run the numbers before committing.
If this resonates, start small.
First: audit. Map your current legacy spend. Licensing, infrastructure, labour. Every pound. Put it in a spreadsheet. That baseline is your north star.
Second: identify a pilot. One system, one workload, one team. Something with clear boundaries and measurable impact. For the fintech, it was internal tools and customer dashboards, used by dozens of people, non-revenue-critical, but expensive to run on legacy infrastructure. Modernise that. Measure the outcome. Time, cost, team friction, unexpected problems. Let those learnings shape your next move.
Third: build your business case. "We spent £X on migration, saved £Y on run costs, and got Z as a bonus (faster deployments, fewer incidents, team morale)." That's persuasive. Most companies skip this and wonder why leadership won't fund round two.
If you're ready to start that process, Imaginary Cloud helps companies architect and execute modernisation strategies. We've worked through these decisions before. Let's talk about yours.
Cloud modernisation isn't magic, but methodology.
Map what you're actually paying for. Start with something low-risk. Run parallel systems longer than you think necessary (the insurance is worth it). Retrain your team as business partners, not obsolete infrastructure keepers. Measure obsessively. Celebrate the wins and acknowledge the cost surprises, since both will come.
The fintech saved 40–50% by being systematic. You probably can too. But only if you start by understanding what you're saving from.
Depends on your workload mix and what's hiding in your legacy infrastructure. High-licensing workloads (enterprise databases, middleware, commercial monitoring tools) often see 50%+. Lower-overhead operations might see 20–30%. But most mid-size companies have hidden legacy costs that make 40%+ realistic if you do the audit first.
Leadership losing patience with the parallel running phase. That's when costs are highest and benefits aren't visible yet. The fintech's CFO had to trust the plan for four months straight. If that commitment wavered, they'd have cut corners and destabilised the migration. Organisational discipline is underrated.
Probably not, if it's handling revenue. The regulatory, audit, and risk burden is too high. Hybrid is your friend. Modernise everything around it. Let the core be boring and stable.
Month 6 for payback. But the team saw operational improvements (faster deployments, better observability, containerised scalability) much sooner, around month 8, when parallel running ended and they fully committed to cloud operations.
No. But cloud isn't a magic cost-cutting tool. It's leverage. If you're running bloated legacy infrastructure with high licensing and manual operations, cloud can multiply your efficiency. If your current setup is already lean, cloud might not save much. The math matters.
If you're just exploring modernisation. Sedna's story shows a different approach and outcome of legacy modernisation.
But if you're ready to move from case studies to action, get in touch with Imaginary Cloud. We help companies architect and execute modernisation strategies grounded in real constraints and real ROI.
Real infrastructure is messy. Let's talk about yours.
Alexandra Mendes is a Senior Growth Specialist at Imaginary Cloud with 3+ years of experience writing about software development, AI, and digital transformation. After completing a frontend development course, Alexandra picked up some hands-on coding skills and now works closely with technical teams. Passionate about how new technologies shape business and society, Alexandra enjoys turning complex topics into clear, helpful content for decision-makers.
People who read this post, also found these interesting:
