“Move to the cloud” stopped being useful advice around the time every enterprise IT team already had at least some workloads running on AWS, Azure, or GCP. The actual question we get now isn’t whether to be in the cloud - it’s why a five-year-old “cloud migration” still feels like running a legacy system, just with a bigger hosting bill. That’s usually because the original migration was a lift-and-shift, not a modernization.
The difference between migrating and modernizing
Lift-and-shift means taking your existing application, more or less as-is, and running it on cloud infrastructure instead of on-prem servers. It’s fast, it’s low-risk in the short term, and it genuinely does solve some problems - you stop maintaining physical hardware, you get easier scaling of raw compute. What it doesn’t fix is anything architectural. A monolithic application that couldn’t scale independently on-prem still can’t scale independently in the cloud; you’ve just moved where the bottleneck lives.
Modernization means actually re-architecting - breaking a monolith into services that can scale independently, moving state out of the application layer into managed databases and caches, replacing custom infrastructure code with managed cloud-native services. It’s more work upfront. It’s also the difference between a cloud bill that scales linearly with traffic and one that scales because you’re paying for capacity you don’t need most of the time.
What “multi-cloud” actually means, and when it earns its complexity
Multi-cloud gets used for two quite different things, and conflating them is how organisations end up paying for complexity they never wanted. The first is running genuinely independent workloads on different providers - your data platform on one, your customer-facing application on another - usually for reasons of history, acquisition, or a specific managed service that only one provider does well. This is common, it is mostly harmless, and it needs little more than consistent identity management and a single view of spend.
The second is running the same workload across providers so that either one can serve it. This is the version people mean when they say multi-cloud gives them resilience or negotiating leverage, and it is dramatically more expensive than it sounds. Portability has to be designed in and then continuously defended: the moment you adopt a provider-specific managed database, queue, or identity service, you have taken on either a rewrite or an abstraction layer to maintain. Data gravity makes it worse, because the data has to be either replicated continuously between providers or kept somewhere both can reach, and both options cost money every day whether or not the second provider is ever used.
Our honest position: pick one primary provider and go deep on its managed services, unless you have a specific, stated reason that survives scrutiny - a regulatory requirement to keep certain data with a particular provider or in a particular jurisdiction, a genuine contractual obligation, or a concentration risk your board has explicitly asked you to reduce. “Avoiding lock-in” on its own is not that reason, because the abstraction layer you build to avoid provider lock-in becomes its own thing to maintain, and you are now locked into that instead, with none of the support a provider gives you.
Where we usually find the biggest gains
- Database layer first. A single, oversized database instance handling everything is almost always the first bottleneck we find in a “cloud migrated but not modernized” system. Moving to properly managed, right-sized services - read replicas for reporting, a cache layer for hot data, purpose-built stores for specific access patterns - usually delivers the fastest, most measurable improvement of any single change.
- Autoscaling that actually autoscales. A lot of “cloud” deployments are still running on a fixed number of always-on instances sized for peak load, which means paying peak-load prices 24/7. Proper autoscaling based on real traffic patterns routinely cuts infrastructure cost by a third to half for workloads with meaningful traffic variation.
- Decoupling the slow parts. Background jobs, report generation, email sending - anything that doesn’t need to happen in the request-response cycle - moved to async queues instead of blocking the main application, which both speeds up the user-facing app and makes the whole system more resilient to load spikes.
The costs that do not appear in the migration plan
Migration budgets are usually built from compute and storage, because those are the line items a provider’s pricing calculator makes easy to estimate. The costs that surprise people afterwards are the ones that scale with architecture rather than with size.
- Data movement. Traffic leaving a provider is charged, and so, on most platforms, is traffic crossing between availability zones. An architecture that chats constantly between services placed in different zones can generate a meaningful bill purely from conversation, and it is invisible until the invoice arrives because nothing about it looks like a performance problem.
- Observability. Log and metric ingestion is usually priced by volume, and a newly decomposed system emits far more of both than the monolith it replaced. Teams that move to microservices without setting sampling and retention deliberately often find monitoring has become one of their larger line items.
- Idle managed capacity. Managed services remove operational work, which is the point, but several of them bill for provisioned capacity rather than for use. A non-production environment left running at production sizing is one of the most common sources of waste we find, and one of the easiest to fix.
- The second environment nobody decommissioned. Lift-and-shift projects frequently leave the original system running “just in case” long after cutover, and the case for keeping it is rarely revisited on a schedule.
What we tell enterprises before they commit to a rewrite
Full modernization doesn’t have to mean a full rewrite, and we push back hard on clients who assume it does - a full rewrite is the highest-risk, highest-cost path, and it’s rarely necessary. The strangler pattern works well here: wrap the legacy system behind an API, build new functionality as properly modernized services, and gradually migrate pieces of the old system over as it makes sense, rather than a single high-risk cutover where everything has to work perfectly on day one.
This also means you get measurable wins early - the first modernized piece (usually the database layer or the highest-traffic endpoint) proves the approach and the cost savings before you’ve committed the whole budget, rather than betting everything on a single big-bang launch eighteen months out.
Sequencing the work so it survives a budget review
Modernization programmes rarely fail on engineering. They fail in month seven, when the sponsor who approved the budget is asked what it has produced and the honest answer is “foundations”. The way to avoid that is to sequence the work so that something demonstrable lands before the first review, and to decide in advance what will be measured.
In practice that means agreeing a small number of figures at the start and capturing them before anything changes: the cost of running the system for a month, the time from a merged change to that change being live, and the latency of the two or three endpoints the business actually cares about. None of these are difficult to collect, but collecting them afterwards is impossible, and without a baseline every improvement becomes a matter of opinion. It also means resisting the temptation to start with the most architecturally satisfying component. The right first target is usually the one with the clearest measurement and the least coupling, because its job is to make the second phase easy to approve.
What we look at first in a modernization audit
Before recommending anything we want to see four things, and they are all readable from a system that is already running. Where the money is going, broken down by service rather than by total, because the shape of a bill tells you what the architecture is really doing. What the deployment path looks like from merge to production, since a long or manual path caps how quickly any other improvement can be delivered. Which components share a database, because that is what determines whether services can genuinely be separated or only appear to be. And what happens under the worst real traffic the system has seen, rather than under a synthetic load test built around assumptions.
Those four answers usually make the priority order obvious, and they frequently show that the expensive rewrite someone had in mind was aimed at the wrong component.
What this actually costs versus what it saves
Modernization work is genuinely more expensive per hour than a lift-and-shift migration - you’re doing real architectural work, not just changing where servers live. But the ongoing infrastructure savings from proper autoscaling and right-sized services routinely pay that back within a year for any system with meaningful traffic, and the improved reliability and deployment speed are worth more than the infrastructure savings alone for most enterprises we work with.
If you’ve already migrated to the cloud but the bill and the performance don’t reflect it, that’s usually a sign the architecture never actually changed. We do this kind of cloud architecture work as a standing engagement, not just a one-time project - get in touch and we’ll audit what’s actually happening in your current setup before recommending anything.