01 Solution · Cloud exit and migration

Cloud migration services in both directions: numbers first, move second

Whether a workload belongs in the public cloud or back in your own data centre is not a matter of conviction but a calculation, and we put it on the table. We then migrate in whichever direction the numbers point and operate the result. The entry point is a cloud exit and TCO assessment, not a move.

Book a call

Entry point: Cloud assessment: cost model by originator, TCO scenarios, measured exit readiness.
Track record: Over 100 migrations in three years. A CTO runs between one and five in an entire career.
Method: Five phases, a go/no-go at every transition, a fallback path per service. No cut-over date.
Afterwards: 24/7 operations from the same team: on-call cover, patch and escalation management.

02 Starting point

The decision is almost always taken without numbers

Cloud in or cloud out gets debated as a matter of principle. It is decided per workload, and that is exactly where the calculation is missing.

“The bill grows faster than the load.”

Egress fees, cross-zone traffic and premium support tiers appear in no plan and on every invoice. Flexera put wasted cloud spend at 29 per cent in its State of the Cloud 2026.

“Nobody knows whether we could even leave.”

BEREC and Beltug found usable exit clauses in fewer than 5 per cent of cloud contracts. What a switch would cost technically has rarely been calculated.

“We are doing this for the first time.”

A CTO runs between one and five migrations in an entire career. Every trap is new to your team, and the estate keeps running alongside it.

None of these sentences is a failure. They are the normal result of a decision that has to be taken next to the day job.

03 The solution

We do not sell a direction, we cost out both

One provider for the whole route: assess, migrate, operate. Each part is available on its own, and where a workload sits correctly in the public cloud we say so.

Cloud exit and TCO assessment

The lowest-risk entry point: a cost model by originator, TCO scenarios for public cloud, private cloud and your own data centre, and a prioritised list of measures. Egress and support tiers are separate line items.

A verdict per workload, not a policy

Cost, compliance and performance are weighed workload by workload. The outcome is often a hybrid architecture that stays hybrid, not a single move in one direction.

Exit readiness expressed in numbers

What leaving costs is known before the decision: data volumes, egress fees, proprietary dependencies, remaining terms and exit clauses.

Cloud cost optimisation before any move

Right-sizing, shutdown schedules, storage classes and commitment models often release enough on their own. A move should never fix what a setting can.

Migration without a cut-over date

Your estate keeps running, we migrate service by service, and every step has a fallback path. Out of AWS, out of Azure or into a hybrid setup: the sequence follows the assessment.

A target platform without a new lock-in

Proxmox, KVM or Kubernetes on Debian, in German data centres or in your own. All open source, with your configurations as Git repositories at your end.

04 How it works

Five phases. You can stop at every transition.

Every phase begins with a go/no-go decision. Until the migration phase, nothing in production is changed.

Phase 01

Analysis

We look at what actually runs, not at what the documentation claims. The cost model and the TCO scenarios come from here.

Phase 02

Target picture

A proposal with costs, risks and a recommendation per workload. The first go/no-go decision falls here.

Phase 03

Test environment

Built and put under load while your estate carries on untouched.

Phase 04

Migration

Service by service, each with a fallback path. No cut-over date on which everything tips.

Phase 05

Operations

24/7 with monitoring, patch and escalation management and continuing advice.

In the documented projects, two to six months passed from breaking ground to the old environment being switched off, depending on the landscape.

05 Proof

Three ways out, documented with the stack

Chosen because they start from different places: costs running away at a hyperscaler, a performance problem in Azure, a complete legacy estate.

Textbroker A self-built AWS environment with more than 50 services, and then the key people left. After the exit, platform and service costs were 75 per cent lower at unchanged availability. That is the highest figure we have documented, a single case and not a promise. Debian · Apache2 · Percona · MariaDB · GitLab

Innotech The application ran in Azure, with severe performance problems and a cost curve that only pointed upwards. Two months from breaking ground to the new production environment on private cloud, then 24/7 with patch and escalation management. Proxmox · Debian · HAProxy · PostgreSQL · Redis

Social Wave After the acquisition of MeinHotspot, two jobs at once: secure the legacy platform and build a container platform alongside it. Within six months the entire legacy infrastructure had been migrated and shut down. Kubernetes · Traefik · Velero · CephFS · MySQL

06 To be honest

Four objections you are having right now

“Would an exit even pay off for us?”

That is precisely the question the assessment answers. Some workloads sit correctly in the public cloud: fluctuating load, short project life, services with no equivalent outside. With a stable baseline load the calculation usually looks different. Which of yours belong where is the output of the analysis.

“We want lower costs, not a migration project.”

Then we start there. Right-sizing, idle resources, storage classes, data paths and commitment models often deliver enough cloud cost optimisation without a machine changing provider. What that looks like day to day is in our articles on cost management in the cloud and on controlling your cloud costs.

“Does operations stand still during the migration?”

No, that is exactly what the approach avoids. There is no cut-over date on which everything tips. Your estate keeps running and every step has a fallback path. The test environment carries load before the first production service moves.

“Afterwards we will simply depend on you.”

Only if we moved you onto a platform of our own. We do not. The stack is open source and close to CNCF standards, any competent provider can take it over, and your configurations sit with you as Git repositories.

07 Fasttrack analysis

Nils HornkeCEO, onehundred

A conversation with someone who has held your job

There are people on the team who have been CTOs themselves. Bring the workloads that drive your bill and you get an assessment of whether an exit is worth it. We regularly tell people to change nothing.

Book an initial call

15 minutes · not a sales call · book directly in the calendar

08 Frequently asked questions

What else you may want to know

Should we move into the public cloud or back out of it?

Both happen, often inside the same organisation. The answer falls per workload and depends on load profile, data volume, compliance and operating effort. The cloud assessment answers it with numbers instead of a strategy argued on principle.

What does a cloud exit cost, and what egress fees apply?

The largest item is rarely the migration but the data leaving the platform. Hyperscalers list egress fees in the order of 0.09 US dollars per gigabyte in the first pricing tier, which reaches five figures quickly on large estates. Your own figure follows from data volume, destination and schedule.

Does the EU Data Act change switching charges?

Yes. The EU Data Act has applied since 12 September 2025, and from 12 January 2027 charges for switching provider may no longer be levied anywhere in the EU. Ordinary data traffic in day-to-day operations is unaffected.

How long does a cloud migration take?

Between two and six months in the documented projects: Innotech in two, Frederix in three, Social Wave in six, each alongside the old estate. Your duration depends on the landscape.

What is cloud migration as a service?

Assessment, move and operation come from one provider rather than from a consultancy, an integrator and a hosting company in sequence. The same people who plan the target picture run it afterwards, which changes how they plan it.

Which target platform do you migrate to?

Proxmox, KVM or Kubernetes on Debian, all open source, in German data centres or in your own. Kubernetes is a tool and not a destination: several of our largest projects run without it.

Do you offer Azure migration services, or migrations from AWS to Azure?

We assess any direction and migrate out of Azure and AWS onto an open-source stack. Moving from one hyperscaler to another is not our route. If you want out of Azure or AWS, that is exactly our direction.

Is the environment operated after the migration?

Yes, that is the core of the model. We do not only migrate, we operate afterwards: 24/7 with on-call cover, patch and escalation management. Whoever operates at the end plans differently.

09 Insights · Cloud exit and cost analysis