Coming back from the cloud: what teams get wrong on the way

Moving workloads off a public cloud and back onto hardware you control has stopped being contrarian. The reasoning is usually sound: a steady, predictable workload on owned or rented hardware costs a fraction of the same workload billed by the hour, and the gap widens as you grow.

The migrations that go badly rarely go badly for the reason people prepare for.

The spreadsheet is usually right

Teams model this carefully, and the compute maths generally holds. Predictable load on owned hardware is cheaper. Egress you do not pay a premium on is cheaper. The saving is real.

What the model tends to omit is that a meaningful share of the cloud bill was never compute. It was the managed database that failed over without anyone being paged, the load balancer that appeared when a config value changed, the certificate that renewed itself for six years, the deploy that happened because someone pushed. None of those line items say "developer experience", and all of them were.

What actually goes wrong

Deploys become a project again. The pipeline that pushed to a managed service now has to build an image, push it somewhere, and apply manifests to a cluster. It works. It is also three new things to maintain, and it degrades quietly.

Certificates become somebody's job. Until the day they are nobody's job, which you discover from a customer.

Databases become a specialism. Backups are the obvious part. Restores are the part that is never tested, and failover is the part discovered during the incident it was meant to prevent.

The knowledge concentrates. Within a few months, one or two engineers understand the setup. That is a bus factor and a promotion risk at once, and it is the least visible cost of the whole exercise.

The pattern is consistent: the infrastructure cost falls and part of it reappears as engineering time. Sometimes that is still a clear win. It is not a win if nobody counted it.

The version that works

The teams that come out ahead treat the developer experience as a requirement of the migration rather than something to reconstruct afterwards. Before moving a workload, they can answer: how does a deploy happen, how does a rollback happen, where do certificates come from, who runs the database, and where do logs live.

If those have answers, repatriation is a hardware decision. If they do not, it is a hardware decision plus an unplanned platform project.

Where Kaja comes in

This is the case we built for. You bring a Kubernetes cluster on whatever hardware the maths favoured, and the parts that used to come from the cloud provider come from Kaja instead: push-to-deploy from a connected repository, numbered revisions with one-click rollback, domains with certificates issued and renewed for you, Postgres and MySQL managed by established operators with scheduled backups to an object store you own, and logs and metrics collected per project.

Your compute is never metered, because it is not ours to meter. That is the whole point of having moved it. See what that costs, or the list of what Kaja still cannot do before you plan anything around it.