No-Rewrite Cloud Migration: 26 Services, 5% Code Changes

Ask an engineering leader why they haven’t migrated off their self-hosted platform, and you’ll usually hear some version of the same fear: “We’d have to rewrite everything. It’s an 18-month project. We can’t stop shipping for that.”

That fear is worth taking seriously — because when a migration is run as a rewrite, those numbers are real, and the project frequently dies halfway.

But it’s the wrong model. Last year we moved a live-streaming and social platform — 26 distinct services, live RTMP video, payments, background workers, cron jobs — from a self-hosted colocation facility onto Kubernetes. Total application code touched: about 5%. Production cutover: one 10-hour window. The product roadmap didn’t stop.

Here’s how a no-rewrite migration actually works.

Most “legacy” platforms are perfectly good software running in a place that makes everything hard: hand-built networks, aging hypervisors, fixed VMs, artisanal deployment scripts.

The no-rewrite bet is that you can change the home without changing the tenant. Applications that already run on Linux VMs — whatever the language, whatever the vintage — can almost always run in containers unmodified. What has to change is everything around them: packaging, configuration, routing, deployment, observability.

That’s why the code delta was 5%, not 50%. And that 5% wasn’t features — it was wiring: externalizing configuration, health endpoints, log output, the mechanical adaptations containers expect.

Step 1: Inventory everything, especially the unglamorous parts
The platform wasn’t one application; it was 26 services plus their supporting cast — background workers, cron jobs, mail processors, media pipelines. By the end, the cluster ran 84 deployment manifests including all the worker and cron variants.

The services nobody thinks about are the migration’s real risk surface. The API gets all the attention; the batch job that settles payments at 2 a.m. is what breaks silently. Half the value of the inventory phase is discovering what your platform actually runs — before it discovers you.

Step 2: Containerize as-is — resist every “while we’re at it”
Each service was containerized with its behavior unchanged. No framework upgrades, no dependency spring-cleaning, no “quick refactors.” Every one of those is scope creep with a pull request attached, and each one couples the migration’s success to a code change that didn’t need to happen.

The discipline pays off at debugging time: when a containerized service misbehaves, you know the code didn’t change — so the problem is in the environment, and the search space is small.

Step 3: Make deployment declarative, with one source of truth
The old world deployed via scripts and know-how. The new platform is driven by a single versioned file that declares which image version of every service is running. Change the file, and CI/CD rolls out the change; revert the file, and you’ve rolled back — the 2–5 minute rollback we quoted in part 1 is that revert. This is where “infrastructure knowledge in someone’s head” becomes “infrastructure knowledge in a repository” — the single most underrated deliverable of the whole exercise.

Step 4: Automate the scariest ritual — database changes
Schema migrations used to be a human ritual: careful hands, a maintenance window, hope. Now they run as an automated, gated CI step across 8 services — validated before any application rollout, versioned, repeatable. Automating this converted the highest-anxiety part of every release into a pipeline stage.

Step 5: Be selective about “managed” — not everything should move
A no-rewrite migration doesn’t mean outsourcing everything to cloud products. The honest split here: the relational database and object storage moved to managed services — commodity infrastructure where a provider’s ops team beats yours on economics. The message broker, cache, event streaming, and vector database run in-cluster, where control and cost favored self-hosting.

“Migrate to managed everything” is a slogan. The engineering question is per-component: does operating this ourselves create any value? Sometimes the answer is yes.

Step 6: Rehearse the cutover until it’s boring
Everything above happened while the old platform served production. The staging cluster ran the full topology — all 26 services, streaming included — long before cutover. By the time the production switch happened, it was a rehearsed procedure, not an event: one planned 10-hour window, data synchronized, traffic moved, done. No rolling weeks of half-migrated limbo, no dual-running bill for months.

Sizing up your own platform, the questions to ask aren’t “how much code do we have” but:

• Can each service run in a container without behavior changes? (Almost always yes — the exceptions define your real project risk.)
• Do you know your full inventory — including every worker and cron job?
• What’s genuinely commodity (managed candidates) versus what’s differentiating or cost-sensitive (keep in-cluster)?
• Can you rehearse cutover on a full replica rather than improvising in production?

If the answers are yes, yes, a defensible list, and yes — your migration is a logistics project, not a rewrite. Logistics projects finish.

26 services. 84 manifests. 5% of the code touched. One 10-hour cutover. Zero rewrites of working software — and the release process came out the other side with automated schema migrations and one-file rollbacks it never had before.

The platform didn’t get rebuilt. It got rehoused. That’s the whole trick.

Next week: the number that changed the engineering organization — new service provisioning from 8–10 days to 30 minutes.

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