Cloud Migration Costs: Why an 11% Higher Bill Was Worth It

Every cloud migration pitch you’ve ever seen has a slide that says “reduce infrastructure costs by 30–40%.”

Here are our real numbers. Last year we migrated a live-streaming and social platform — 26 microservices, live video ingest, payments, the works — from a self-hosted colocation facility to Kubernetes on a managed cloud. Their infrastructure bill before: $6,080 per month. After: $6,762 per month. That’s an 11% increase. And if you asked their engineering leadership whether they’d do it again, the answer would be an immediate yes.

If that sounds contradictory, this post is for you — because the monthly invoice is the least interesting number in a migration, and judging one by it is how companies end up making the wrong call in both directions.

The “before” picture will feel familiar to anyone running a platform built in the 2010s: two racks in a Toronto colo on yearly contracts. Ten physical nodes running roughly 70 virtual machines across two clusters. Six separate networks — production, dev, enterprise, management and more — stitched together with three different firewall technologies, all hand-configured, all understood end-to-end by a very small number of people. Self-hosted PostgreSQL with replicas behind HAProxy. Self-hosted caching, object storage, message queues. A streaming media tier handling live RTMP video.

None of it was broken. That’s worth saying clearly: this platform ran with zero infrastructure-related on-call incidents per month, and releases already shipped with zero downtime. The team was competent, and the system was stable.

It was also rigid, opaque to everyone but its builders, and sitting on hardware that was aging toward a refresh bill nobody wanted to sign.

The colo bill and the cloud bill are not measuring the same thing. Three things the $6,080 never included:

The next hardware refresh: Blade chassis and storage arrays don’t depreciate politely — they work until the week they don’t, and then you’re writing a five-figure-to-six-figure capex cheque under time pressure. The cloud bill has no refresh cliff hiding behind it. That risk is now the provider’s problem, priced into the monthly rate.

Commitment: The racks came with yearly contracts. The cloud footprint is elastic month to month — the platform can grow, shrink, or restructure without a procurement negotiation.

Engineer attention: This is the big one. The before-state had ~70 VMs and 6 networks worth of patching, firmware, backups, and firewall rules competing for senior engineers’ time. The after-state is 12 nodes in 2 clusters on a single cluster network. That’s an ~83% reduction in the number of machines anyone has to think about — and the engineers who used to think about them now work on the product.

Cost parity would already have been a win given the above. But the after-state isn’t the same platform at a similar price — it’s a categorically different platform:

• Provisioning a new service used to take 8–10 days. It now takes 20–30 minutes. A full new environment: 1–2 days. That’s not an optimization; it’s a change in what the engineering organization can attempt.
• Autoscaling went from zero to 11 services. Before, capacity was whatever the fixed VMs provided. Now the API, media, and web tiers scale themselves.
• TLS certificates went from semi-manual to fully automated. An entire category of embarrassing outage — the expired cert — is structurally gone.
• Database schema changes became a gated, automated CI step across 8 services, instead of a human ritual.
• And the things that were already good stayed good: releases still ship with zero downtime, rollbacks still take 2–5 minutes, and infrastructure on-call is still quiet.

The entire migration, incidentally, required touching only about 5% of the application code — but that’s next week’s post.

If you’re evaluating a migration, put away the invoice comparison and ask three questions instead:

• What’s the real all-in cost of staying? Colo bill + amortized refresh capex + contract lock-in + the fully loaded hours your best engineers spend being a hosting company.
• What does the target platform let you attempt that the current one doesn’t? For our client, the honest answer included an AI-powered feature set that simply could not have been built on the old stack (part 5 of this series).
• What’s your key-person risk? If the number of people who fully understand your network can fit in a sedan, you have a problem no invoice line captures.

And to be fair — sometimes the answer is stay put. If your load is flat, your hardware is freshly refreshed, and your platform knowledge is well distributed, a migration may genuinely not pay. A vendor who won’t tell you that is selling something other than engineering.

An 11% higher bill bought: an 83% smaller infrastructure footprint, provisioning measured in minutes instead of weeks, self-scaling services, structural elimination of whole outage categories, zero capex exposure — and an engineering team pointed at the product instead of the plumbing.

That’s the trade. We think it’s a good one. More importantly, our client’s CTO thinks so — with a year of production behind the opinion.

Next week: how 26 services moved to Kubernetes with only 5% of the code changed — the anatomy of a no-rewrite migration.

Mobifilia helps companies move business-critical platforms from self-hosted infrastructure to cloud-native Kubernetes — without rewrites and without fairy tales.