Cloud first, then bring back what stands still

An executive team wants to be rid of the server room. The reflex is to first draw the ideal end state: which load belongs on the cloud, which on your own hardware, and only once that is settled does anything move. A plan like that takes months. By the time it is ready, half the assumptions no longer hold, because the load you were trying to estimate you have never actually measured.

The perfect end plan is the wrong first step

Placement, the question of which workload runs on which infrastructure, is a cost question and an architecture question at the same time. Anyone who wants to lock that down to the decimal in advance spends months estimating on figures that do not exist yet. Your current on-prem hides the real load: the peak hours, the growth curve, what a nightly batch actually consumes. You guess, you cast the guess into a document, and then you build an entire migration around it.

Plans that nail everything down up front have a mediocre track record. In 2012, McKinsey and the University of Oxford studied IT projects above 15 million dollars. They run 45% over budget on average and deliver 56% less value than promised, and in 17% of cases things go so badly wrong that the survival of the organisation is at stake. The heavier you make the first decision weigh, the harder those figures land.

First, off the old hardware

Reverse the order. Do not pick an end placement yet. First break free from the outdated on-prem: lift the load to an EU cloud, or rebuild it there where that is faster. Cloud requires no capex, you turn capacity on and off again, and you are running within weeks rather than after a hardware purchase with a lead time. That buys you two things: room to scale without new server space, and time to see how the load actually behaves.

Cloud-first is not the same as carrying the mess along. Lift a cumbersome process onto expensive, elastic infrastructure and you pay for that cumbersomeness by the hour from then on. So first clean up what can go. A process audit records where the load really sits before anything moves, so you migrate the clean workloads and not the habits around them.

Measure first, place after

Once the load runs in the cloud, you can measure instead of guess. Per workload you now see what it costs and how heavily it weighs, hour after hour, week after week. With those figures on the table, placement becomes a substantiated choice.

Cloud earns its premium on load that moves. Peaks around a campaign, a month-end close or a season. Processing that one day weighs ten times as much as the next. There, paying per use is cheaper than a server park stacked at peak capacity all year round. As soon as the load stops moving, the calculation tips.

A service that runs seven days a week at roughly the same load is a predictable base load. For that, the flexible cloud price is a premium for scaling headroom you never use. Such workloads belong on hardware you own or lease yourself, where the cost per unit is lower over a few years. Measure the base load, and bring it back.

Bringing workloads back is finally cheap

For a long time the brake on bringing workloads back was the exit cost. Anyone leaving the cloud paid egress per gigabyte to take their own data along. In 2024 that barrier fell away. Google Cloud scrapped egress fees for those who leave in January, AWS followed on 5 March 2024, in part under pressure from European regulation.

That regulation is the Data Act, Regulation (EU) 2023/2854, in force since 12 September 2025. It obliges providers to enable switching and functional equivalence, and phases out switching and egress costs. The Data Act thus gives you a right to switch, with a cap on what a provider may charge you for it. Bringing a workload back to your own hardware therefore no longer carries a penalty on top of the ordinary work.

We see that reflected in the figures. The 2024 Barclays CIO Survey found that 83% of CIOs wanted to bring at least one workload back from the public cloud that year, up from 43% at the end of 2020, with cost as the main driver. Note the nuance: full exits remain rare and most organisations stay hybrid. This is about selectively placing back the workloads where it pays off, not about renouncing the cloud.

The stack that makes moving without a rebuild possible

This only works if a workload can move without being rebuilt each time. That is where the stack is the key. If everything runs in containers on Kubernetes, with PostgreSQL and ClickHouse underneath, then the infrastructure it runs on is interchangeable. The same container runs on an EU cloud and on your own hardware, without rewriting and without a closed format that binds you to a single provider. This way the platform stands apart from the place where it happens to run, and a move turns into work your team plans itself.

Placement stays in motion

Placement changes along with your business. Load shifts, a product grows, a peak drops back to a base load or the other way around. Measure, place, and re-place as soon as the figures tip. That rhythm fits how we work: an IT FinOps audit exposes the cost and the load before anything moves, and the build runs in waves with a go or no-go per step, so every move stays measurable.

The advantage of this order grows over time. The cloud absorbs the load that moves, your own hardware carries the load that stands still, and because both run the same container you shift a workload from one to the other as soon as the figures call for it. Your next peak or base load then becomes not a migration project, but a measurement and a switch.