The topic of migration has become more practical than it used to be. Since March 2024, AWS has had a program that allows customers to request free data transfer out through support when moving data to another cloud or to their own infrastructure. One old barrier to leaving has become lower, but that does not make migration a cheap project by itself.
At the same time, businesses do have a real reason to discuss this. According to Flexera, 84% of organizations name cloud cost management as their top cloud challenge. In other words, the question is usually not “should we leave or stay on principle?” but rather: does the current platform still provide enough value for its cost, complexity, and dependency?
The short practical answer usually looks like this:
- Migration looks reasonable when the problem is systemic: costs remain consistently high, data residency requirements become stricter, and the workload profile objectively fits better in another cloud or on your own infrastructure.
- Migration looks questionable when the bill itself is frustrating, but the root cause is poor cost control, an inflated architecture, unnecessary managed services, and idle resources that were never cleaned up.
- Free data transfer out removes only one barrier. The main costs still remain in data, dependencies, service rewrites, releases, and process changes.
Below, we will look at what usually pushes companies toward leaving, where migration can genuinely create value, where the project becomes too expensive, and when the move is actually worth it.
What Usually Makes a Business Start Looking at Leaving AWS
The conversation about migration almost never begins with a beautiful architecture idea. Usually, it is much more practical: the business becomes uncomfortable with the current model, and that discomfort gradually turns into the question, “Is it time to calculate the cost of leaving?”
Most often, it is not one single reason, but several at once. First, the bill becomes irritating. Then it turns out that alongside the bill, dependency on one provider is growing, operations are becoming more complex, and the platform feels less like something that helps and more like something that increasingly dictates its own rules.
The usual triggers look like this:
| What starts creating pressure | How it looks in practice |
| The bill stops being predictable | Costs grow faster than the workload, and explaining the business reason becomes harder |
| Dependency on one provider starts getting in the way | Too many services and processes are tied to one platform |
| Data requirements become stricter | Questions appear around data location, sovereignty, and infrastructure control |
| The architecture accumulates too much complexity | The number of services grows, while transparency and manageability decrease |
| The workload economics change | What was convenient at the start begins to look too expensive over the long term |
| The business wants more control | There is a demand for its own rules, its own pace of change, and fewer external limitations |
But it is important not to confuse the cause with the symptom.
Sometimes the company really has run into platform limitations or an unfavorable cost model. But sometimes the problem is different: costs were not controlled properly, the architecture became bloated, idle resources were never cleaned up, and now the provider itself appears to be the obvious culprit for everything at once.
That is why a serious conversation about leaving should usually start not with the emotional reaction “we need to get out,” but with a more uncomfortable question: has the business really reached the limits of the current model — or has it simply gone too long without putting that model in order?
From there, the next logical step is to ask what migration can actually provide beyond the hope of a more pleasant bill.
Where Migration Can Actually Create Value
What You Can Gain Besides a Different Price
Following from the previous point, migration makes sense not when the company simply wants to “change clouds,” but when the business can genuinely improve its operating model — not just its monthly bill.
And that value can come from more than one place.
Migration can provide:
- Lower cost for a specific workload type, if the current platform is objectively overpriced for your usage profile
- More predictable spending, when a complex mix of services is replaced with a clearer and more stable cost model
- Less dependency on a single provider, if the business does not want too many critical systems tied to one environment
- More control over data, infrastructure, and the pace of change
- A better-suited stack for specific tasks, if the current architecture is too dependent on services that are difficult to scale, operate, or move
- A stronger negotiation position with vendors, because the ability to leave changes the conversation around pricing and terms
The important point is not to romanticize migration itself. A new provider or your own infrastructure does not create value out of thin air. It may simply fit your workload type, geography, data requirements, or desired level of engineering control better. If that fit is not there, the supposed “benefit” quickly dissolves into a new layer of complexity.
Why “Cheaper” Can Sometimes Become More Expensive
This is where the most uncomfortable part of the migration conversation begins. A lower bill from a new provider or from your own infrastructure does not automatically mean the business will actually come out ahead economically.
The reason is simple: cloud costs rarely exist separately from architecture, processes, and cost-management discipline. According to Flexera, 84% of organizations name cloud cost management as their top challenge, average cloud budgets are exceeded by 17%, and 59% of companies are already expanding their use of FinOps teams to regain control over spending. That is an important signal: the problem is often not one specific platform, but the fact that the spending model itself has become hard to manage.
That is why, before migrating, it is worth looking not only at resource prices, but also at what exactly you are trying to fix:
| What looks like a source of savings | Where the new cost may actually appear |
| Lower compute or storage prices | Service rewrites, data migration, testing, and releases |
| Dropping some expensive managed services | More workload for the team and more self-managed operations |
| Moving to a cheaper cloud | New limitations, a different stack, and loss of some familiar tools |
| Moving to your own hardware | CapEx, maintenance, backup, and your own operational environment |
| Reducing the monthly bill | Higher risk of mistakes during transition and a more expensive rollback |
Flexera gives useful context for a sober conclusion here. Nearly a third of organizations already spend more than $12 million per year on public cloud, and expected cloud spending growth over the next year is estimated at 28%. Against that background, the desire to “move somewhere cheaper” is understandable — but by itself, it proves nothing.
Sometimes migration is genuinely a rational step. But sometimes it is an attempt to compensate through relocation for problems that should have been fixed first: cost governance, resource ownership, idle capacity, access discipline, and overall architecture.
That is why the economics of migration should be calculated in two layers at once.
The first layer is the new platform price.
The second is the cost of the exit itself — including data, teams, timelines, risk, and the new operating model after migration.
And that second layer is very often heavier than it looks at the beginning. This leads naturally to the most difficult part of the topic: where migration costs the most, and what tends to break first — the platform, the data, or the processes.
Where a Migration Project Usually Pays the Most
What Breaks First: the Platform, the Data, or the Processes
Most often, migration does not start falling apart in the presentation or in the budget estimate, but in the most practical details. Not in the sense of “the cloud turned out to be bad,” but in the sense of “we are only now seeing how much of our system is tied to specific services, workflows, and team habits.”
Imagine a typical order-processing service. From the outside, it looks simple: an application, a database, a queue, file storage, and a few background jobs. On paper, it seems like something that can be moved to another platform calmly enough. But during the migration, it suddenly becomes clear that part of the logic lives in a managed database, part in queues, part in monitoring and alerting, and another part in scripts and settings that nobody has touched manually for a long time.
At that point, the problem is no longer just the platform itself. The data has to be moved carefully, services have to be reconnected, integrations must not be broken, and the team has to keep working in a new model without losing speed.
That is why migration usually hits not one place, but three at once: data, dependencies, and processes. And very often, it is the processes that start cracking first — because architecture can still be rewritten, but accumulated operational chaos tends to move with the project almost for free.
This leads to the next uncomfortable question: why platform dependency is often deeper than it looked at the beginning.
Why Dependency on AWS Is Often Deeper Than It First Seems
Here too, it helps to use an example — and to avoid going too far, let us take the same one from the previous section. When the team looks at the migration from above, everything seems understandable: an application, a database, files, queues, and a couple of background jobs. But during a real assessment, it quickly becomes clear that “moving” does not affect just one stack, but the entire accumulated way of working inside the platform.
The problem looks like this:
| What seems simple at the start | What appears during a real exit |
| Move the data | Copying, validation, synchronization, and cutover windows are required |
| Move the application | Service bindings, permissions, monitoring, and automation have to be replaced |
| Change the platform | The team has to rebuild releases, diagnostics, and everyday processes |
That is exactly why dependency is often deeper than it first seemed. It does not live only in virtual machines or storage, but also in queues, databases, the IAM model, backups, alerts, scripts, and team habits.
What is especially notable here is that the provider itself has simplified one of the barriers for customers that decide to move data to another cloud or to their own infrastructure. In March 2024, AWS announced that in such a scenario, customers can request free data transfer out to the Internet through support in the form of credits.
Put simply, the program works like this:
- The request is submitted through support
- The decision is made at the account level
- The program applies specifically to migration scenarios, not ordinary production traffic
- After approval, AWS provides credits for data transfer out
- According to the September 30, 2025 update, customers have 90 days to complete the exit; if more time is needed, that should be communicated to support immediately
- The previous requirement to wait until outbound transfer exceeded 100 GB per month was removed in the same update
As of 2026, this option is still relevant, but its scope is fairly narrow. It helps remove one visible cost barrier around data egress, but it does not eliminate the cost of migration itself. The data still has to be moved carefully, service dependencies have to be reconnected, and processes have to be rebuilt in the new environment.
And that leads to the next reasonable question: is the move actually worth it for the business, or is the project trying to solve through migration a problem that would be cheaper to fix inside the current platform?
Is the Move Worth It?
First, it is useful to separate the cases where leaving looks reasonable from the cases where it looks more like an expensive attempt to treat symptoms.
| Scenario | What usually looks reasonable |
| The workload profile is stable and predictable, but the bill does not match the project economics | Calculate a full exit or partial workload migration |
| More control is needed over infrastructure, isolation, or data residency | Seriously consider an alternative platform or own hardware |
| The project is deeply tied to managed services, and the team is not ready to rebuild processes | It is often cheaper to stay and first clean up the current setup |
| The main pain is not the platform, but weak cost control and an inflated stack | First fix architecture and cost governance instead of rushing into migration |
But that is not enough. Even if the business is genuinely ready to leave, the next question is just as important: where exactly should it look, and for what kind of workload?
“Leaving AWS” is not a strategy by itself.
One project may need roughly the same large ecosystem, just with a different price or different commercial terms. Another may care more about a more direct infrastructure layer: virtual machines, networks, Kubernetes, storage, and fewer layers of platform abstraction on top. A third may be better served by moving only part of the workload, rather than breaking away from the whole stack at once.
This is where it is more useful to look not at the brand name itself, but at the type of platform and its operating logic.
Some options fit teams that need straightforward IaaS and Kubernetes without an overloaded ecosystem. Others fit businesses that care about private cloud, hybrid cloud, or a more controlled infrastructure model. And some are simply strong where the goal is a more direct and lower-cost virtual machine layer.
| If the business cares most about… | Options usually worth looking at |
| A broad ecosystem, global reach, and many built-in services | Staying on AWS or considering a comparable major cloud |
| A simpler infrastructure layer: VMs, Kubernetes, networks, volumes, load balancing | DigitalOcean, OVHcloud, Hetzner Cloud, Servermall Cloud Services |
| A more controlled model with private cloud or hybrid cloud | OVHcloud and Servermall Cloud Services |
| Simple VM infrastructure without a heavy ecosystem around it | Hetzner Cloud or DigitalOcean |
| Kubernetes as the main operational layer | DigitalOcean Kubernetes, OVHcloud Managed Kubernetes, Kubernetes in Servermall Cloud Services |
In other words, the practical point of migration is usually not to “move from one name to another.” It appears when the new platform better matches the workload profile and the way the team actually works.
If the business needs dozens of built-in services, global infrastructure, and a deep platform ecosystem, a sudden move to a simpler provider may look attractive on price but painful in operation. But if the company cares more about a clearer infrastructure layer, better control over virtual machines, networks, and Kubernetes clusters, and less dependence on a large set of platform-specific services, migration may start to look much more rational.
Conclusion
If you look at migration soberly, it is not a story about “leaving at any cost.” For a business, the question is usually simpler: will the project, the team, and the budget actually become easier to live with after the migration — or not?
Sometimes leaving really is justified. For example, when the current model is consistently expensive, requirements around control and data have grown, and the workload profile no longer matches the way the platform is built.
But the opposite also happens. A company tries to use migration to fix poor architecture, weak cost control, and accumulated infrastructure chaos. In that case, migration does not solve the problem — it simply moves it somewhere else.
So the normal rule of thumb is this: you need to calculate not only the price of resources after the move, but also the cost of the new operating life.
If the new platform gives the business clearer economics, better control, and a more suitable operating model, then the move may genuinely be worth it.
If not, it is usually wiser to first put the existing environment in order.
FAQ
Does migration almost always mean leaving completely?
No. In practice, companies often evaluate not a full breakaway, but a partial move of specific workloads: for example, stable VMs, storage, Kubernetes environments, or backup systems where the economics and operating model look better. This also aligns with Flexera’s findings that repatriation usually affects only part of cloud workloads rather than the entire stack.
Does free data transfer make leaving AWS cheap?
No. The AWS program removes one barrier — data transfer out charges during migration, if the request is approved through support. But the main costs still remain: data migration, service reconfiguration, testing, releases, and rebuilding operational processes.
When is it wiser to stay and first clean up the current platform?
When the main pain is not the platform itself, but weak cost control, an inflated set of services, idle resources, and the absence of proper FinOps. That is especially logical given that 84% of organizations name cloud cost management as their top challenge.
When does leaving actually look reasonable?
When the problem is systemic: costs consistently fail to match the project economics, control and data residency requirements have grown, and the workload profile fits better on another infrastructure layer or on an owned platform. In those cases, migration looks less like an emotional reaction and more like an architectural and financial calculation.
Why is dependency on AWS often deeper than it seems?
Because a project is usually tied not only to virtual machines and storage, but also to access rights, observability, automation, managed databases, queues, backups, and release processes. That is why “moving the data” almost never equals a real platform exit. The free data transfer program indirectly confirms this too: it covers DTO, not the entire migration effort around it.
Does it make sense to look beyond major hyperscalers and consider more infrastructure-oriented platforms?
Yes, if the business needs a more direct IaaS model: VMs, networks, storage, and Kubernetes without deep dependency on a large ecosystem of managed services. DigitalOcean, Hetzner Cloud, OVHcloud, and Servermall Cloud Services are generally positioned more in that direction than around a massive platform-service ecosystem.
Sources
1. AWS News Blog — Free data transfer out to internet when moving out of AWS
2. Flexera — 2025 State of the Cloud: 84% struggle to manage cloud spend
3. AWS EC2 FAQs — free data transfer out when moving off AWS
