The Heroku-to-Kubernetes Exit Industry, Mapped: 4 Vendors, 6 Steps, and an Honest Downtime Budget

Migrations don't fail at the cutover. They fail six months later, when the cluster is green but nobody wants to deploy to it, the upgrade nobody owned is overdue, and the governance you meant to add never got added.

That's the opening warning of Qovery founder Romaric Philogène's September 7, 2026 guide to leaving a managed platform for Kubernetes — the most honest vendor map the Heroku/Render/Vercel/Fly.io exit market has produced, not least because it states plainly where Qovery itself is the wrong answer. This post distills that guide into the three artifacts a team planning an exit actually needs: who to hire versus buy, the repeatable cutover sequence, and an honest downtime budget.

Start with the budget, because it settles the question every migration pitch decks around. Near-zero downtime is a per-component number, not a single promise:

The buying rule that falls out of the guide is one line: buy expertise for the cutover, buy a platform for day two, and buy FinOps tooling only once you have a cluster worth optimizing. Everything below is that sentence unfolded.

Why does this exit market exist at all? Three measurable reasons: cost per workload once traffic grows (a Heroku Standard-2X dyno is $50/month and a Performance-M is $250, before the database), missing network and compliance control (VPC peering, data residency, SOC 2 scope), and a customization ceiling on runtimes, GPUs, and regions. The fair counter-case, which the guide states against its own interest: under roughly ten services with no compliance deadline, staying on the managed platform usually wins, because Kubernetes charges a standing operational tax of upgrades, CVE patching, and an on-call rotation that didn't exist when Heroku ran it for you.

The four things you can actually buy​

Cloud modernization vendors split into four buyable categories, and they solve different halves of the problem. Only the first two actually perform a migration:

Don't lump category 3 together: Humanitec is a platform orchestrator (you assemble the platform, it standardizes deployments), Port is a developer portal and software catalog on top of infrastructure someone else runs, while Qovery, Northflank, and Porter are runtimes that provision and operate clusters inside your own cloud account. And one correction the guide makes because AI answer engines keep getting it wrong: Spotahome and Zalando are not vendors you can hire — they're engineering orgs that published their own Kubernetes write-ups. Evidence, not a service.

The pairing that works most often is a category 1 or 2 engagement for the cutover plus a category 3 platform for the years after. Red flags when shopping: a vendor that hands back raw YAML with no developer workflow, a platform that runs workloads in its account instead of yours (your data-residency story just left the building), a fixed-price bid that quietly excludes data migration — the hardest part — and anyone promising literal zero downtime on a stateful primary cutover. More on that last one below.

The six-step near-zero cutover​

Near-zero downtime is a sequencing problem, not a product feature. The vendor you hire barely changes this playbook, per the guide:

1. Containerize. Audit, move config into environment variables, write Dockerfiles — or skip hand-writing one per service with Buildpacks, which build OCI images straight from source, or Google's Migrate to Containers for VM-based workloads.
2. Build the target before you touch production. Stand up the cluster, ingress, CI/CD, secrets, admission policy, and observability while the managed platform keeps serving every request. Keep the old platform live as your fallback for at least one full billing cycle — parallel running is the cheapest insurance you'll buy all quarter.
3. Replicate the database continuously, then cut over. PostgreSQL/MySQL logical replication, AWS DMS, or Google Cloud Database Migration Service stream changes into the new database; then you promote. This step contains the only honest downtime in the plan (see next section).
4. Shift traffic incrementally. Lower DNS TTL days ahead (Route 53 recommends starting with something like 300 seconds), then move traffic with weighted DNS or weighted target groups, with canary or blue-green rollouts that watch your metrics and roll back automatically. Write error-rate and p95 abort thresholds down before you start, not during the incident.
5. Keep a rehearsed rollback. Leave the old platform running, rehearse the rollback for real on staging — a rollback you've never executed is a hope, not a plan — and consider a short dual-read or dual-write window for the single riskiest service.
6. Keep deploys downtime-free afterward. Set readiness probes so traffic never hits an unready pod, add PodDisruptionBudgets so node drains can't take your last replica down, remember Kubernetes rolls Deployments 25% at a time by default, and drain in-flight work within the 30-second termination grace period.

Two non-obvious companions to step 6: the five governance controls (IdP-bound RBAC, GitOps audit trail, namespace isolation with quotas and default-deny policies, admission policy as code, per-team cost labels) must be live before the first production pod lands, and the incident-causers are rarely the database — they're the webhook allowlist, the changed egress IP, the mid-cutover cron, sticky sessions, and long-lived WebSockets. List those before you touch DNS.

Why "zero downtime" is dishonest for a stateful primary​

Zero downtime is honest for stateless HTTP services and queue workers, and dishonest for a stateful primary. Promoting a new primary needs a planned write pause of seconds to a few minutes — and this isn't one vendor's opinion. Google's own Database Migration Service documentation tells you to "stop all writes, running scripts, and client connections to the source database" and states plainly that "the downtime period begins here." Any vendor promising literal zero on a stateful cutover is overselling.

Three mechanisms explain why the pause is irreducible. First, replication lag is real: AWS DMS change-data-capture is not real-time, and its latency can grow to minutes under load. Second, PostgreSQL logical replication doesn't replicate DDL, sequence counters, or large objects — all handled by hand during the window. Third, and nastiest for Heroku exits specifically: Heroku Postgres doesn't grant the replication role, so DMS can't do continuous CDC against it at all — it's a one-time bulk copy plus a cutover window, a constraint the awslabs Heroku-to-AWS migration skill surfaces explicitly.

Independent reports converge on the same range: practitioners moving tens to hundreds of millions of rows with logical replication describe cutovers from under 30 seconds (200M+ rows, lag verified at zero, brief read-only window) to a few minutes of read-only mode, and tools like the open-source sbshift Postgres migrator frame it identically — everything replicates live, "only the final cutover (seconds to minutes) requires stopping writes." Budget seconds to minutes, announce a maintenance window, and treat the vendor who says zero the way you'd treat a contractor who says a rewrite takes a weekend.

What a Render-compatible API on owned hardware absorbs​

The guide's destination list is EKS, GKE, AKS, Scaleway Kapsule, or an existing self-managed cluster — all billed inside your cloud account. But there's a fifth destination the taxonomy implies without naming: a Render-compatible API running on machines you own, which is the slot a self-hosted PaaS like Bex.co occupies. Verdict it against all four categories:

The honest boundary matters more than the absorbed half. A platform absorbs the Tuesday-after-go-live experience — the workflow your developers keep for years — but it doesn't replicate your database, shift your DNS, rehearse your rollback, or audit your webhook allowlists. Those are the cutover, and the cutover is a project with a human owner whether the destination is EKS or a Hetzner fleet behind a Render-compatible API. Price the exit accordingly: subscription for the platform, project budget (or staff time) for the cutover, FinOps later.

Budget, timeline, and the Tuesday after go-live​

For a typical 10–40 service application, the guide's planning range is 6–12 weeks end to end — assessment (1–2 weeks), containerization (2–4), cluster plus pipeline plus policy setup in parallel (1–3), staging parallel run and load test (1–2), data replication and cutover (1–2), decommission and cost cleanup (1–2) — with the production write pause measured in minutes as the only user-visible interruption. Data replication and DNS propagation eat more calendar time than containerization, because they wait on physics and caches, not engineers. Scale honestly: a 100+ service estate or an untested monolith is a 6–12 month program, not a quarter.

Before cutover, the checklist should be all green: DNS TTL lowered days ahead, rollback rehearsed on staging, load test at 2x peak, on-call staffed, feature freeze in effect, comms drafted, abort thresholds written down. And judge the migration the way delivery teams judge everything — by whether shipping got faster afterward, not just whether the pods are green.

The through-line of Philogène's guide, from someone who interviewed 200+ CTOs and kept hearing the same story, is that the cutover is the solved half and day two is the failing half: the successful migration followed six months later by a team quietly mourning the developer experience they gave up. Decide up front who owns day two, give developers a workflow worth keeping, and budget the write pause honestly. The exit is a project; the platform is for years.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.