project, not a subscription
Cloud exit
The public cloud is great under variable load. Under steady load it's often many times more expensive than the same resource elsewhere - and the bill climbs so slowly that nobody notices the point where it stopped paying off.
This is a decision from the invoice, not a conviction
The public cloud wins where load spikes: a season, a campaign, a sudden surge. You pay for the peak only when there is one. Under steady load, that same mechanism works against you - you pay every month for flexibility you don’t use.
The bill grows quietly. An added resource, another test environment, a backup in a different region, outbound transfer. Each item looks harmless on its own, which is why nobody notices the threshold where the whole thing stopped paying off.
That’s why we start with the last three invoices and the load profile, not with a migration proposal.
What we do
- cost analysis - breaking the bill down into fixed resources, variable resources and transfer
- a comparative estimate against dedicated servers and a private cloud, with admin cost on both sides
- private cloud configuration on Hetzner
- migration from AWS - planned in stages, with a period of parallel operation
- vendor lock-in exit strategies - what to do about managed databases, orchestration and services with no equivalent outside a single provider
Three line items that usually surprise people
Outbound transfer is often billed separately and can be a significant part of the bill, even though nobody ordered it consciously. Non-production environments run twenty-four hours a day, even though they’re only used during office hours. Backups and snapshots linger from projects that ended a year ago.
These three things alone can bring the bill down with no migration at all. If the cost returns to a sensible level once they’re cleaned up, the project ends at that stage - and that’s exactly how we describe it.
What migration looks like
In stages, with a period where the old and new environments run in parallel. We first move what’s least tied to managed services: virtual machines, files, test environments. Databases and orchestration come later, because that’s where the risk is highest, and rebuilding a managed function requires a conscious decision about how much server administration you’re taking on yourselves.
A way back exists at every stage, until we switch off the old environment. Switching it off is the last step, not the first.
What usually stays in the cloud
An exit is rarely complete, and doesn’t need to be. Mail and office software stay in Microsoft 365, because running your own mail server today is a cost and a risk without a payoff. An off-site backup also stays in the cloud - its whole point is being somewhere else.
What moves is what runs steadily and predictably: virtual machines with an application, databases with stabilized load, development environments. The split follows load variability, not service type - and that’s the only criterion that still holds up on the invoice a year later.
Who this works for
Companies with predictable, steady load and a bill that grew faster than usage. Most often: an in-house application with a stabilized user count, internal systems moved to the cloud “along the way”, or development environments running unsupervised.
The topic is complex and rarely has one right answer. If you’re at this point and looking for solutions - we need to talk, not fill in a form with a headcount.
Frequently asked questions about leaving the cloud
What does "cloud exit" actually mean?
Moving part or all of a workload from the public cloud to a cheaper platform: dedicated servers, a private cloud, or on-premises hardware. It’s not an ideological return to your own server room - it’s a decision made on the invoices, taken when the load is predictable.
How much can you realistically save?
Depends on the load profile and how much of the bill comes from managed services. The biggest differences show up with constant compute load and heavy egress traffic - transfer out of the cloud is often a sizeable line item nobody thought about at rollout. We run the numbers before migrating, not after.
When is it NOT worth leaving the cloud?
With highly variable load, seasonal peaks, a team distributed around the world, and wherever you rely on managed services whose rebuild would eat up the savings in admin time. If the numbers work against it, we say so plainly and stop at the analysis.
What about vendor lock-in?
The more managed services, the harder it is to leave - databases like RDS, orchestration like EKS and serverless functions bind the tightest. An exit strategy is either designed before rollout or added later, at a higher cost. Either way, the goal is being able to rebuild the environment at another provider in a reasonable time.
