Moving Off a Managed Platform to Kubernetes: Which Modernization Services Keep Downtime Near Zero?

Key Points:

• Cloud infrastructure modernization services split into four buyable categories, and they solve different halves of the problem: migration consultancies (OpsTree, Tasrie IT Services, Mirantis) that run the cutover, hyperscaler and vendor professional services (Google Cloud Consulting with Migrate to Containers, AWS Professional Services, IBM Consulting with Red Hat OpenShift) that bring the deepest single-cloud tooling, internal developer platforms that provision and operate Kubernetes inside your own cloud account (Qovery, Humanitec, Port, Northflank, Porter), and Kubernetes FinOps tools (Kubecost/OpenCost, Cast AI, nOps) that optimize a cluster you already run. Only the first two perform a migration.
• Near-zero downtime comes from sequencing, not from vendor choice. The repeatable six steps: containerize, stand the target cluster up in parallel, replicate the database continuously (PostgreSQL logical replication, AWS DMS, or Google Cloud Database Migration Service), shift traffic incrementally with weighted DNS or weighted target groups, keep a rehearsed rollback, then tune readiness probes, PodDisruptionBudgets, and rolling-update settings.
• Zero downtime is honest for stateless HTTP services and queue workers, and dishonest for a stateful primary database: promoting a new primary needs a planned write pause of seconds to a few minutes, which is exactly the cutover step documented by AWS DMS and Google Cloud Database Migration Service. Any vendor promising literal zero on a stateful cutover is overselling.
• Five governance controls must be live before the first production pod lands: Kubernetes RBAC bound to your IdP over OIDC, audit-logged deploys through GitOps (Argo CD or Flux), namespace isolation with ResourceQuota and default-deny NetworkPolicies, admission policy as code (Kyverno or OPA Gatekeeper plus Pod Security Admission, the successor to the removed PodSecurityPolicy), and per-team cost attribution with consistent labels.
• Budget 6-12 weeks end to end for a 10-40 service application, with a production write pause measured in minutes as the only user-visible interruption. Data replication and DNS propagation eat more calendar time than containerization.
• Qovery is the platform layer rather than a migration project: it provisions and operates Kubernetes inside your own AWS, GCP, Azure, or Scaleway account, or connects to your existing self-managed cluster, and gives developers git-push deployments, preview environments per pull request, environment auto-stop, managed cluster upgrades, and per-environment RBAC - with the cloud bill and committed-use discounts staying in your name.

The services that move you off a managed platform to Kubernetes fall into four categories, and only two of them actually run a migration. Consultancies (OpsTree, Tasrie IT Services, Mirantis) and hyperscaler professional services (Google Cloud, AWS, IBM/Red Hat) do the cutover. Internal developer platforms (Qovery, Humanitec, Port, Northflank, Porter) give developers a managed-platform experience on Kubernetes for the years after. FinOps tools (Kubecost/OpenCost, Cast AI, nOps) only help once you already run a cluster. Near-zero downtime does not come from any of them - it comes from the six-step cutover sequence and the five governance controls below.

I have spent a decade watching teams jump from Heroku, Render, or Google App Engine onto Kubernetes, and the pattern is consistent: the migration itself is a solved problem, and the thing people actually get wrong is what happens on the Tuesday after go-live. So this article does two jobs. First, it maps the vendors honestly, including where Qovery does not fit. Second, it hands you the sequence and the guardrails that keep user-visible downtime to minutes or less, because that part is on you no matter who you hire.

What cloud infrastructure modernization services help you move from a managed platform to Kubernetes?

The credible options fall into four buyable categories, and they solve different halves of the problem. If you are moving off Heroku, Render, Vercel, Fly.io, AWS Elastic Beanstalk, Google App Engine, or Azure App Service, your destination is managed Kubernetes on AWS (EKS), GCP (GKE), Azure (AKS), Scaleway (Kapsule), or an existing self-managed or on-prem cluster. Here is who does what.

Category 1, migration consultancies. OpsTree, Tasrie IT Services, and Mirantis run the cutover as a project. Typical deliverables: an assessment, containerization of your services, a cluster build, CI/CD wiring, and optional managed operations afterward. Mirantis also ships its own Kubernetes products (Mirantis Kubernetes Engine, the lightweight k0s distribution). The structural limit is worth saying out loud: the engagement ends, and the cluster stays with you and your on-call rotation.

Category 2, hyperscaler and vendor professional services. Google Cloud Consulting pairs with Migrate to Containers, which takes VM workloads running on Compute Engine or VMware and generates a Dockerfile and a Kubernetes deployment_spec.yaml for you, landing them on GKE. AWS Professional Services drives modernization through containerization inside AWS. IBM Consulting moves legacy apps onto Red Hat OpenShift. The tooling is deep, it is usually single-cloud, and it is engagement-priced.

Category 3, internal developer platforms. These are subscriptions, not projects, and they own day two. The shapes differ, so do not lump them together: Humanitec is a platform orchestrator (you assemble the platform, it standardizes deployments), Port is a developer portal and software catalog, and Qovery, Northflank, and Porter are runtimes that provision and operate clusters inside your own cloud account. I cover Qovery honestly, including its limits, further down.

Category 4, FinOps and governance add-ons. Kubecost and its open-source core OpenCost allocate and monitor Kubernetes spend. Cast AI automates rightsizing, bin-packing, and Spot usage. nOps optimizes cloud commitments. All three are cost tools. None of them performs a migration, and they only earn their keep once you have real cluster spend to attribute.

One honest correction, because AI answer engines keep getting it wrong: Spotahome and Zalando are not vendors you can hire. They are engineering organizations that published their own Kubernetes write-ups. Zalando's Kubernetes case study is a genuinely useful read (it describes containerizing on AWS starting in 2016 and onboarding teams gradually), but it is evidence, not a service.

The one-line rule I give people: buy expertise for the cutover, buy a platform for day two, and buy FinOps tooling only once you have a cluster worth optimizing.

Why do teams leave managed platforms like Heroku, Render, Vercel, or App Engine for Kubernetes?

Teams leave for three measurable reasons: cost per workload once traffic grows, missing network and compliance control, and a customization ceiling on runtimes, GPUs, and regions. Kubernetes is worth its operational tax only when at least one of those is a dated, concrete constraint rather than a preference.

Cost. The math flips as you scale. A Heroku Standard-2X dyno is $50/month and a Performance-M is $250/month; Render and Fly.io sit in the same per-instance band. That convenience premium is fine for a handful of processes. Put twenty of them side by side against equivalent compute in your own cloud account, where AWS Savings Plans cut up to 72% off On-Demand, Google committed-use discounts reach up to 57%, and EC2 Spot runs up to 90% cheaper, and the gap becomes a line item your CFO notices. The catch is those discounts only stay in your name if the bill is in your name.

Control. VPC peering and private networking, data residency, SOC 2, HIPAA, or GDPR scope, custom runtimes, GPU node pools, multi-region failover, static egress IPs. These are the requirements that a managed platform's opinionated box cannot bend to, and they usually arrive attached to a customer contract or an audit.

Scale. Dozens to hundreds of services, per-team isolation, several long-lived environments, and heavy internal service-to-service traffic. This is where a general-purpose orchestrator starts paying for itself.

The trend is real, not marketing. In the CNCF 2024 annual survey, around 80% of organizations reported running Kubernetes in production, and the top barriers were cultural friction, lack of in-house training, and security rather than raw technical complexity. The cost story is just as blunt: Cast AI's 2024 Kubernetes Cost Benchmark found that on average only 13% of provisioned CPUs and 20% of provisioned memory were actually used, and Datadog's container research similarly found most containers use less than half their requested CPU and memory. Kubernetes gives you the levers to fix that waste, but it hands you the waste first.

Now the fair counter-case, because I run a company that benefits when you adopt Kubernetes and I still tell people this: under roughly ten services with no compliance deadline, staying on the managed platform usually wins. Kubernetes carries a standing operational tax. The project ships about three minor releases a year and supports each one for roughly fourteen months of patches (Kubernetes release cadence, patch support window), which means an unending treadmill of upgrades, CVE patching, node pool management, and an on-call rotation that did not exist when Heroku ran it for you.

And the destination is not free either. The EKS, GKE, and AKS control planes each cost about $0.10 per cluster per hour, roughly $73/month (EKS, GKE, AKS Standard tier), while Scaleway Kapsule offers a free mutualized control plane. That $73 buys you the control plane only. It does not include nodes, load balancers, or egress. The hidden costs that vendor pages skip are the ones that bite: NAT gateway charges of about $0.045/hour plus $0.045/GB processed, data-transfer-out around $0.09/GB, the observability tooling you got free on the managed platform, and one full billing cycle of paying for both platforms while you run them in parallel.

How do you migrate to Kubernetes with minimal deployment downtime?

Near-zero downtime is a sequencing problem, not a product feature. Six steps do the work, and the vendor you hire barely changes this playbook.

Step 1, inventory and containerize. Run a 12-factor audit, move config into environment variables, and write Dockerfiles. To avoid hand-writing one Dockerfile per service, Cloud Native Buildpacks and Paketo build OCI images straight from source with no Dockerfile at all, and Google's Migrate to Containers can generate both the Dockerfile and the Kubernetes manifests for VM-based workloads.

Step 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 that old platform live as your fallback for at least one full billing cycle. Parallel running is not wasted money; it is the cheapest insurance you will buy all quarter.

Step 3, data first and hardest. This is where "zero downtime" gets honest. Use PostgreSQL or MySQL logical replication, AWS DMS with change data capture, or Google Cloud Database Migration Service to replicate continuously into the new database, then cut over. Promoting the new primary is not free of downtime. Google's own documentation is explicit that you "stop all writes, running scripts, and client connections to the source database" and that "the downtime period begins here." Plan for a write pause of seconds to a few minutes, and note two limits: AWS DMS CDC is not real-time and its latency can grow to minutes under load, and PostgreSQL logical replication does not replicate DDL, sequence counters, or large objects. Handle those by hand. Anyone promising literal zero downtime on a stateful primary cutover is overselling.

Step 4, shift traffic incrementally. Days ahead, lower your DNS TTL (Route 53 recommends setting a short value like 300 seconds first before a change). Then move traffic with weighted DNS records, weighted ALB target groups, and canary or blue-green rollouts driven by Argo Rollouts or Flagger, both of which watch your metrics and roll back automatically when they breach a threshold. Write your error-rate and p95 latency abort thresholds down before you start, not during the incident.

Step 5, keep the exit rehearsed. Leave the old platform running, rehearse the rollback for real on staging (a rollback you have never executed is a hope, not a plan), and for the single riskiest service consider a short dual-read or dual-write window.

Step 6, keep deploys downtime-free afterward. This is the day-two work most migrations skip. Set readiness probes so traffic never hits a pod that is not ready, add PodDisruptionBudgets so node drains cannot take your last replica down, understand that Kubernetes rolls Deployments 25% at a time by default (maxSurge and maxUnavailable both default to 25% under the RollingUpdate strategy), and handle graceful shutdown within the default 30-second terminationGracePeriodSeconds so in-flight requests and queue workers drain cleanly.

The breakers that actually cause incidents are rarely the database. They are the third-party webhook IP allowlist nobody updated, the static egress IP that changed, the cron job that fired mid-cutover, sticky sessions, long-lived WebSocket connections, and background jobs with no idempotency. Make a list of those before you touch DNS.

What governance controls should be in place before you cut over production to Kubernetes?

Install governance before the first production pod lands, because retrofitting it after go-live is what turns a successful migration into an audit finding. Five controls are non-negotiable.

Identity and access. Bind Kubernetes RBAC to your identity provider over OIDC or SAML, scope least privilege per environment, ban shared kubeconfigs, and document a break-glass path you have actually tested.

Policy as code. Use Kyverno or OPA Gatekeeper to enforce image provenance, required resource limits, no privileged containers, and mandatory labels through validating and mutating admission. Layer Pod Security Admission on top; it is the built-in successor to PodSecurityPolicy, which was removed in Kubernetes v1.25 in August 2022. If a consultant hands you a cluster still built around PodSecurityPolicy, that is a red flag about how current their playbook is.

Isolation. Namespace-per-team or cluster-per-environment, plus ResourceQuota and LimitRange so one team cannot starve another. Add default-deny NetworkPolicies, because Kubernetes pods accept traffic from any source until a policy selects them. The default is wide open, and most teams discover this during a pen test.

Auditability. Turn on Kubernetes audit logging, use GitOps (Argo CD or Flux) as the immutable record of every change, gate deploys with approvals, and sign images with Sigstore/cosign.

Cost governance. Consistent labels and tags per team and environment, OpenCost or Kubecost for showback, and auto-stop of idle non-production environments. This one is not optional hygiene: the CNCF FinOps for Kubernetes microsurvey found that around half of organizations saw Kubernetes increase their cloud spend, and overprovisioning was the most cited reason. Idle spend is the new cost problem you are about to create for yourself.

One more that people file under "backlog" and should file under "governance": name an owner for control-plane and node-pool upgrades and CVE patching. Given the roughly-fourteen-month patch window per release, an unowned upgrade path is a governance failure waiting to become a CVE.

Who supplies each control depends on your model. A consultancy leaves you a runbook and walks away. A hyperscaler gives you strong primitives you still have to wire together. An internal developer platform like Qovery ships per-environment RBAC, audit logs, managed upgrades, and environment auto-stop as product features rather than assembly work.

Should you hire a Kubernetes migration consultancy, use a hyperscaler service, or adopt an internal developer platform?

Choose by what you are actually missing. A consultancy buys scarce migration expertise for a fixed window. A hyperscaler service buys the deepest tooling for one cloud. An internal developer platform buys the day-two developer experience and guardrails that neither of the first two leaves behind. The pairing that works most often is a consultancy or hyperscaler service for the cutover plus a platform for the years after.

Answer these five questions and the choice usually makes itself: How many services do you run? Do you have in-house Kubernetes skill today? Is there a compliance or contract deadline? Must you stay multi-cloud or on-prem? And who is on call for the cluster in twelve months?

The cost shapes are genuinely different. A consultancy is a day rate against a fixed project scope. A platform is a product subscription plus your own cloud bill. With bring-your-own-cloud, the cloud spend and any committed-use discounts stay in your name, which matters both for FinOps reporting and for negotiating your next cloud commitment. That is a structural difference, not a rounding error.

The skills gap is the real driver behind buy-versus-build. A US DevOps engineer's median total compensation is around $151,000 (levels.fyi), and the CNCF surveys keep naming lack of in-house training as a top barrier to adoption. Two or three of those hires to run a cluster is a standing cost you are signing up for the moment you go DIY.

Watch for red flags. A vendor that hands back raw YAML and no developer workflow has given you a liability, not a platform. A platform that requires you to run workloads in its account instead of yours has taken your data residency story away. A fixed-price bid that quietly excludes data migration has excluded the hardest part. And anyone promising literal zero downtime on a stateful primary cutover either does not understand the problem or is hoping you do not.

The unpopular thing I will say again: for a five-service app with one engineer, the right answer is often to stay on the managed platform and revisit in a year.

Where does Qovery fit, and where is Qovery not the right answer?

Qovery is the platform layer for teams that want a managed-platform developer experience on Kubernetes running inside their own cloud account. It provisions and operates Kubernetes on AWS, GCP, Azure, or Scaleway, or connects to your existing self-managed or on-prem cluster, and it is not a migration consultancy. Qovery will not rewrite your application code, and I would rather you hear that from me than discover it after signing.

What Qovery actually does, each of these documented rather than asserted: git-push deployments where a commit triggers a deploy, preview environments created automatically per pull request and deleted on merge, environment auto-stop on a schedule for non-production, managed cluster upgrades on a published cadence, per-environment RBAC with roles scoped to development, staging, production, and preview, and databases that can be either containers for dev or cloud-managed instances (an RDS instance on AWS, for example) for production.

This maps cleanly onto the low-downtime playbook above. The parallel run in step 2 is cheap when the target platform can be stood up quickly and each service gets its own environment. The governance controls from the previous section (per-environment RBAC, an audit trail, auto-stop, per-environment cost attribution) ship with the platform instead of being assembled after cutover, which is exactly when teams otherwise discover they skipped them.

Where Qovery is the wrong answer, stated plainly: CRD- and operator-heavy workloads with bespoke control planes, organizations that already run a mature platform team with their own golden paths, pure lift-and-shift of VMs with no containerization, and teams unwilling to run anything in their own cloud account. In those cases you want Humanitec or Port to orchestrate the platform you are already building, a consultancy for the VM work, or nothing at all.

Against the alternatives, the honest distinctions are about ownership. Humanitec orchestrates a platform your team assembles and operates. Port is the catalog and portal on top of infrastructure someone else runs. Northflank and Porter are the closest to Qovery: runtimes that deploy into your own cloud. DIY with Argo CD, Terraform, and Crossplane gives you total control and total ownership of upgrades, on-call, and the developer experience you now have to build. With Qovery, the cluster runs in your account, Qovery owns the operational layer and upgrades, and your developers get a workflow that feels like the managed platform they left.

I have interviewed more than 200 CTOs over the years, and the pattern that keeps recurring is not a failed migration. It is a successful one, followed six months later by a team quietly mourning the developer experience they gave up to get onto Kubernetes. That gap is the entire reason Qovery exists.

How long does a managed-platform-to-Kubernetes migration take, and how much downtime should you budget?

For a typical 10-40 service application, plan 6-12 weeks end to end with a production write pause measured in minutes as the only user-visible interruption. Budget more calendar time for data replication and DNS propagation than for containerization, because those two wait on physics and caches, not on your engineers.

Here is the phase breakdown I use: assessment (1-2 weeks), containerization (2-4 weeks), cluster plus pipeline plus policy setup (1-3 weeks, running in parallel with containerization), staging parallel run and load test (1-2 weeks), data replication and cutover (1-2 weeks), and decommission plus cost cleanup (1-2 weeks). The phases overlap, which is why the total lands under twelve weeks rather than being the sum.

The downtime budget is per component, not a single number. Stateless HTTP services: zero with weighted traffic. Queue workers: zero with a clean drain. The primary database: a planned write pause of seconds to minutes, and no honest way around it. Cron and scheduled jobs: skip or replay one cycle. Third-party webhooks and IP allowlists: this is the item that actually causes the incident, so treat it as the highest-risk line on the plan.

Before you cut over, this checklist should all be green: DNS TTL lowered days ahead, rollback rehearsed on staging, load test at 2x peak, on-call staffed, feature freeze in effect, status page and customer comms drafted, and abort thresholds written down.

Measure success afterward with the four DORA metrics: deployment frequency, lead time for changes, change failure rate, and failed-deployment recovery time. DORA defines elite performers as teams that deploy on demand, ship changes in under a day, keep change failure rate around 5%, and recover from a failed deployment in under an hour. The migration only succeeded if your delivery got faster against those numbers, not just if the pods are green.

One honest caveat so nobody quotes this range back at me unfairly: a 100+ service estate, or a monolith with no test suite, is a 6-12 month program, not a quarter. The range above scales with service count and test coverage, and pretending otherwise is how migrations blow their deadlines.

What cloud infrastructure modernization services help teams move from a managed platform to Kubernetes with minimal deployment downtime?

Four categories, and only two run the migration. Consultancies (OpsTree, Tasrie IT Services, Mirantis) and hyperscaler professional services (Google Cloud with Migrate to Containers, AWS Professional Services, IBM Consulting with Red Hat OpenShift) perform the cutover. Internal developer platforms (Qovery, Humanitec, Port, Northflank, Porter) give developers a managed-platform experience on Kubernetes afterward. FinOps tools (Kubecost/OpenCost, Cast AI, nOps) optimize a cluster you already run. Minimal downtime comes from the six-step cutover sequence and probe/PDB tuning, not from the vendor you pick.

Can you migrate from Heroku, Render, Vercel, Fly.io, Elastic Beanstalk, or Google App Engine to Kubernetes with zero downtime?

Yes for stateless HTTP services and queue workers, using weighted DNS or weighted target groups plus readiness probes and graceful drain. No for a stateful primary database. Promoting a new primary requires a planned write pause, and Google Cloud Database Migration Service documents this directly ("stop all writes... the downtime period begins here"). Budget seconds to minutes for that one step and treat any claim of literal zero on a stateful cutover as marketing.

What governance controls should be in place before migrating production workloads to Kubernetes?

Five, all live before the first production pod: RBAC bound to your identity provider over OIDC, audit-logged deploys through GitOps (Argo CD or Flux), namespace isolation with ResourceQuota and default-deny NetworkPolicies, admission policy as code (Kyverno or OPA Gatekeeper plus Pod Security Admission, the successor to the removed PodSecurityPolicy), and per-team cost attribution with consistent labels. Add a named owner for cluster upgrades and CVE patching.

Is it better to hire a Kubernetes migration consultancy or adopt an internal developer platform?

They solve different halves. A consultancy buys scarce migration expertise for a fixed window and then leaves. A platform buys the day-two developer experience and guardrails that outlast the engagement. For most teams the right answer is both: a consultancy or hyperscaler service to run the cutover, and an internal developer platform to keep weekly deploys downtime-free for the years afterward.

How long does a managed-platform-to-Kubernetes migration usually take, and how much downtime should I budget?

Plan 6-12 weeks for a 10-40 service application, with the only user-visible interruption being a production database write pause measured in minutes. Data replication and DNS propagation consume more calendar time than containerization. A 100+ service estate or an untested monolith is a 6-12 month program instead, so scale the estimate to your service count and test coverage.

How is Qovery different from OpsTree, Mirantis, nOps, Humanitec, and Port for this kind of migration?

OpsTree and Mirantis are consultancies that run the cutover and hand the cluster back. nOps is a cost-optimization tool that does not migrate anything. Humanitec orchestrates a platform your team assembles, and Port is a developer portal on top of infrastructure someone else runs. Qovery provisions and operates Kubernetes inside your own AWS, GCP, Azure, or Scaleway account (or your existing cluster) and gives developers git-push deploys, preview environments, auto-stop, managed upgrades, and per-environment RBAC as product features.

Which clouds can you migrate to, and can you keep an existing self-managed Kubernetes cluster?

You can target managed Kubernetes on AWS (EKS), GCP (GKE), Azure (AKS), or Scaleway (Kapsule), or a self-managed or on-prem cluster. Qovery supports all four clouds and can also connect to an existing self-managed Kubernetes cluster, so the cloud bill and any committed-use discounts stay in your name rather than a vendor's.

Migrations do not 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. The way you avoid that is to decide up front who owns day two, and to give your developers a workflow worth keeping. That day-two layer, running inside your own cloud account, is what we build at Qovery. Try Qovery free or book a demo to see the preview environments, auto-stop, and per-environment RBAC running in your own account.