Migrating Off a Managed Platform to a Hyperscaler: 9 Automation Tools Compared and a Cutover Playbook for Under 10 Minutes of Downtime

Key points:

• No single tool migrates a managed platform to a hyperscaler. Evaluate four layers separately: infrastructure provisioning (OpenTofu, Terraform, Pulumi, Crossplane), application delivery and developer workflow (Argo CD, Flux, or an internal developer platform like Qovery, DuploCloud, LocalOps), data replication (Postgres logical replication, AWS DMS, Google Database Migration Service, Azure's migration service), and replacements for the platform primitives you get for free today.
• Downtime comes from the database cutover and DNS, not the applications. Streaming logical replication into the target managed database, held until replication lag is near zero, then a write freeze of 2 to 5 minutes to swap connection strings, is the only path that keeps downtime under 10 minutes. A pg_dump/pg_restore cutover scales downtime with dataset size and routinely runs hours.
• Lower DNS TTL to 60 seconds at least 48 hours before cutover, then shift traffic by weight (Route 53 weighted records, Cloud DNS weighted round robin, Azure Traffic Manager) in 5% / 25% / 50% / 100% steps. A TTL change only takes effect after the old TTL expires in resolver caches, so lowering it on cutover day is too late to protect your rollback.
• Postgres logical replication does not replicate sequences, large objects, or DDL (PostgreSQL docs). Failing to advance sequences on the target before accepting writes is the single most common cause of a broken cutover - the first insert collides on the primary key.
• Expect roughly 6 to 12 weeks with a platform handling provisioning and delivery, versus 4 to 9 months hand-rolling IaC plus GitOps. These are typical ranges from real projects, not a published benchmark. The variable is almost never the application code; it is rebuilding the developer workflow the managed platform gave you for free.
• If you do not already employ platform engineers, an internal developer platform is the fastest route off a managed platform. Qovery deploys into your own AWS, GCP, Azure, or Scaleway account - or your existing Kubernetes cluster - with git-push deploys, preview environments per pull request, and environment auto-stop, while the cloud bill and any committed-use discounts stay in your name (BYOC).

---

I have watched a lot of teams try to move a complex microservices app off a managed platform, and the ones who struggle almost always make the same first mistake: they go looking for the one tool that does it. There isn't one. Heroku is the most common starting point, but the same thing is true whether you are leaving Render, Fly.io, or any other PaaS for AWS, GCP, Azure, Scaleway, or a Kubernetes cluster you already run.

The managed platform you are leaving quietly does four separate jobs for you. Moving off it means replacing all four, and the tools that cover each one are different tools. Here is how I break it down, which tools I would actually evaluate for each layer, and the database-and-DNS cutover sequence that keeps a production move under 10 minutes of downtime instead of a multi-hour outage.

What should you evaluate before migrating from a managed platform to a hyperscaler cloud?

Evaluate four layers separately, not one product: infrastructure provisioning, application delivery plus developer experience, data migration, and replacements for the managed-platform primitives you depend on today. No single tool covers all four, and assuming one does is the most common reason these projects slip from weeks to months.

• Layer 1, provisioning. OpenTofu, HashiCorp Terraform, Pulumi, AWS CDK, or Crossplane. These create the VPC, the cluster, the managed database, load balancers, IAM, and secrets. They build the foundation and stop there.
• Layer 2, application delivery and developer experience. Argo CD or Flux for GitOps on Kubernetes, an internal developer platform (Qovery, DuploCloud, LocalOps), or cloud-native runtimes directly (ECS/App Runner, Cloud Run, Azure Container Apps). This is the layer that replaces git push deploys and review apps.
• Layer 3, data. Native Postgres logical replication, pglogical, pgcopydb, AWS DMS, Google Database Migration Service, Azure's PostgreSQL migration service, or pg_dump/pg_restore for small datasets with a real maintenance window.
• Layer 4, the hidden one. Every platform primitive you quietly depend on: add-ons, config vars, review apps, release phase, schedulers, log drains, buildpacks, process types, restart behavior. Inventory and map each to an equivalent before you write a line of IaC.

A decision shortcut, stated plainly. If you have an existing platform team with Kubernetes expertise, go OpenTofu plus Argo CD. If you have no platform team, pick an internal developer platform and skip authoring manifests. If you are a regulated workload where a certification list decides the bid, evaluate DuploCloud first.

Name the destinations as equals: AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster you already run. Heroku-to-AWS is one path, not the path. And before you shortlist anything, write down three constraints: your maximum acceptable downtime in minutes, the headcount you actually have for platform work, and whether a compliance certification decides the purchase.

How do the main migration automation tools compare for a complex microservices app?

OpenTofu, Terraform, and Pulumi provision infrastructure and do nothing for developer workflow. Argo CD and Flux deliver applications but assume you already run Kubernetes and author Helm charts for every service. DuploCloud, LocalOps, and Qovery compress provisioning and delivery into one platform, and they differ mainly on cloud coverage, whether workloads run inside your own cloud account, and what you keep if you stop paying.

The nine tools, honestly:

• OpenTofu - the open-source Terraform fork now under the Linux Foundation, created after HashiCorp moved Terraform to the Business Source License in August 2023 (OpenTofu). It reached general availability in January 2024. Best for reproducible infrastructure. No app workflow, no preview environments.
• HashiCorp Terraform - the incumbent, under BSL 1.1 since August 2023 (HashiCorp), with HashiCorp now part of IBM after the acquisition closed in February 2025 (IBM). Its provider ecosystem is the largest by a wide margin - past 3,000 providers back in 2023 (HashiCorp).
• Pulumi - infrastructure as code in TypeScript, JavaScript, Python, Go, .NET, Java, or YAML (Pulumi). The right call for teams who want real code, unit tests, and their existing language tooling. Same scope limits as OpenTofu.
• Crossplane - a CNCF project that provisions cloud resources through Kubernetes APIs. It graduated in October 2025 (CNCF). Powerful for platform teams building their own abstraction, heavy to adopt against a migration deadline.
• Argo CD - a CNCF graduated GitOps controller (graduated December 2022 as part of the Argo project, CNCF) and one of the most widely adopted CD tools in Kubernetes. Excellent once the cluster and charts exist. Authoring and maintaining manifests for 30-plus microservices is the real cost.
• Flux - the other CNCF graduated GitOps option (graduated November 2022, CNCF), lighter and more controller-composable, with the same prerequisite of an existing cluster.
• DuploCloud - a compliance-oriented platform that generates IaC behind the scenes and runs in your own cloud account. Strong when SOC 2, HIPAA, PCI-DSS, or FedRAMP evidence drives the decision (DuploCloud).
• LocalOps - a Heroku-like deploy experience provisioned inside your own AWS, GCP, or Azure account, under your IAM and in your VPC (LocalOps). Younger and smaller ecosystem, a good fit for a modest footprint.
• Qovery - an internal developer platform that deploys into your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster (Qovery docs). Git-push deploys, preview environments per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services. Standard Kubernetes underneath.

Two honorable mentions that are a different decision entirely. Render and Fly.io are legitimate destinations if what you actually want is to stay on a managed platform rather than move to a hyperscaler. Render is a fully managed PaaS on Render's own infrastructure with managed Postgres (Render); Fly.io runs your app on Fly Machines and now offers a Managed Postgres service (Fly.io). Neither runs in your own cloud account, so the cost and control tradeoffs are different. That is fine, as long as you are choosing it on purpose.

And where Qovery is the wrong pick, out loud: non-containerized or bespoke infrastructure, heavy data-pipeline workloads, a mature platform team already happy with Argo CD, or a compliance bid where another vendor's certification list is what decides it.

One evaluation criterion cuts through all of this. Ask it of every vendor on your shortlist, including Qovery: "If we stop paying tomorrow, what do we keep?" Standard Kubernetes resources running in your own cloud account is the only answer I would accept.

How do you migrate a production Postgres database with minimal downtime?

Use streaming logical replication from the source database into the target managed Postgres, hold it until replication lag is near zero, then take a write freeze of 2 to 5 minutes to flip connection strings. That is the only approach that reliably keeps downtime under 10 minutes. Dump-and-restore downtime scales with dataset size and routinely becomes a multi-hour window - Heroku's own upgrade docs estimate roughly 3 minutes of downtime per GB when you do it with maintenance mode and pg:copy (Heroku).

Check your source plan first. On Heroku, fork and follow (the mechanism behind replica and leader-follower setups) is supported on Standard, Premium, Private, and Shield tiers but not on the Essential tier (Heroku). If you are on an Essential-tier database, you upgrade before you can do anything clever. Verify this in your provider's docs before you plan the window.

Your three real options:

• Option A, logical replication. Native Postgres logical replication or pglogical into Amazon RDS/Aurora PostgreSQL, Cloud SQL for PostgreSQL, Azure Database for PostgreSQL Flexible Server, or Scaleway Managed Database for PostgreSQL (Scaleway).
• Option B, cloud-native migration services. AWS DMS runs a "full load plus CDC" task and ships a data validation feature that compares every row on source and target (AWS). Google Database Migration Service does continuous migration with an explicit promote step (Google Cloud). Azure's integrated migration service does online migration to Flexible Server with minimal downtime (Microsoft). The validation report is the step teams skip and regret.
• Option C, pg_dump/pg_restore or pgcopydb. Simplest, acceptable only below a few hundred GB with an announced maintenance window.

The sequence that works, in order: provision the target, run the initial load, start replication, validate row counts and checksums, run a dual-read verification, take the write freeze, confirm zero replication lag, advance sequences on the target, promote, repoint connection strings, and keep the source database running as your rollback for 48 hours.

Now the failure modes, with the mechanism and not just the label. Native logical replication does not replicate sequences, large objects, or DDL (PostgreSQL). That is why "advance sequences" is its own step: if you skip it, your sequence still shows the start value on the target and the first insert collides on the primary key. Then there are the prerequisites that bite in practice - wal_level has to be logical, max_replication_slots and max_wal_senders default to 10, and every replicated table needs a replica identity or UPDATE and DELETE error out (PostgreSQL). After that, the usual suspects: extensions missing on the target (pgcrypto, postgis, pg_stat_statements), SSL-mode and connection-limit differences, and pgbouncer pooling that behaves differently from your old managed connection-pooling add-on.

How do you cut over microservices traffic without dropping requests?

Run both environments in parallel and shift traffic by weight at the DNS or load balancer layer in 5% / 25% / 50% / 100% increments, never in a single switch. Lower DNS TTL to 60 seconds at least 48 hours in advance, because a TTL change only takes effect once the old TTL has expired in resolver caches. AWS says it directly: when you are about to change critical DNS entries, temporarily shorten the TTLs first so you can roll back quickly (AWS Route 53). That one step is why rollback takes seconds for teams who planned it and hours for teams who did not.

• Weighted routing options. Route 53 weighted records (AWS), Cloud DNS weighted round robin (Google Cloud), Azure Traffic Manager weighted routing with integer weights from 1 to 1000 (Microsoft), or a shared CDN/edge sitting in front of both the old platform and the new cluster.
• Gate every step. Hold at each weight until p95 latency and the 5xx rate on the new environment match or beat the old platform, side by side. Define the rollback trigger as a number before the window opens, not in the moment.
• Order to minimize blast radius. Stateless read-heavy services first, then write paths, then cron jobs and background workers last.
• Keep the split working. Shared database endpoint, consistent service discovery, the same auth issuer, and careful handling of service-to-service calls that used to resolve inside a private network space.

The lifecycle difference that drops requests if you ignore it: Heroku dynos get SIGTERM and then 30 seconds to exit before the dyno manager sends SIGKILL (Heroku). Kubernetes pods use terminationGracePeriodSeconds, which also defaults to 30 seconds, and on termination the kubelet runs your preStop hook, sends SIGTERM, and marks the pod not-ready so it leaves the Service endpoints while in-flight requests drain (Kubernetes). Verify graceful shutdown before you shift any real traffic.

And the platform primitives with no direct Kubernetes equivalent: Heroku's release phase becomes an init container or a Kubernetes Job; a hosted scheduler becomes a CronJob, and that is often an upgrade because Heroku Scheduler is explicitly best-effort and documents that a job "may be skipped" or "may run twice" (Heroku); log drains become an agent plus a sink; config vars become Secrets or an external secrets manager.

Rehearse the cutover on real infrastructure, more than once. This is one place the platform choice pays for itself: Qovery's preview environments per pull request make a dress rehearsal cheap, and environment auto-stop keeps those rehearsal environments from running up a bill while they sit idle.

How long does a managed platform to hyperscaler migration take, and what is the week-by-week sequence?

A complex microservices move runs roughly 6 to 12 weeks when a platform handles provisioning and delivery, and 4 to 9 months when a team hand-rolls IaC plus GitOps from scratch. These are typical ranges from migrations I have watched up close, not a published benchmark, and the variable is almost never the application code. It is rebuilding the developer workflow you got for free.

• Week 0-1, inventory. Every app, dyno or container type, add-on, config var, scheduled job, log drain, buildpack behavior, and process type. Assign an owner and a replacement to each add-on.
• Week 1-3, provision the target. Network, cluster, managed database, secrets, observability. Get exactly one real service to production and keep it there.
• Week 3-6, migrate in waves. Wire CI, port secrets management, replicate add-on functionality, service by service.
• Week 5-8, data. Set up replication early and in parallel, then run at least two full rehearsal cutovers in staging with every step timed and written down.
• Cutover window. Write freeze, confirm zero replication lag, advance sequences, promote the database, shift traffic by weight, monitor against the latency and error gates you agreed in advance.
• Week +1 to +2. Parallel run with the old platform still live, then decommission apps and cancel add-ons. Deleting the source on day one is the most expensive mistake in these projects.

A cost checkpoint belongs here. Compare dyno plus add-on spend against hyperscaler spend after rightsizing and auto-stopping non-production environments - Flexera put wasted cloud spend at 29% in its 2026 report (Flexera), and idle non-prod is a big slice of that. With BYOC the bill sits in your own account, so AWS Compute Savings Plans (up to 72% off on-demand, AWS) and GCP committed use discounts (up to 70% on some machine types, Google Cloud) are yours to negotiate, not your old vendor's.

Measure the outcome with DORA metrics taken before and after: deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time (DORA). If deployment frequency drops after the move, the migration is not finished.

When is an internal developer platform the right answer instead of IaC plus Argo CD?

IaC plus Argo CD gives maximum control and is the right call when you already employ platform engineers who want to own manifests, charts, and cluster upgrades. An internal developer platform is the right call when the goal is keeping managed-platform developer experience without hiring two or three platform engineers to recreate it, which is the cost most migration plans leave out. A single DevOps engineer in the US runs a $171,000 median total comp (levels.fyi); Gartner has predicted that by 2026, 80% of large software engineering organizations will have platform engineering teams (Gartner). The build-versus-buy math turns on that headcount, not on license fees.

• What you lose the day you leave a managed platform: git push deploys, review apps per pull request, managed Postgres, zero-config TLS, release phase, and a single place to set config vars. Each has a rebuild cost measured in engineering weeks.
• What Qovery replaces concretely: git-push deployments (Qovery), preview environments per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services such as RDS (Qovery).
• Why BYOC decides this: the cluster and the cloud bill stay in your own AWS, GCP, Azure, or Scaleway account, or your existing Kubernetes cluster, so you are not swapping one vendor's lock-in for another vendor's runtime.
• Apply the exit-path test to every vendor, Qovery included. Cancel tomorrow, and with a BYOC platform you keep standard Kubernetes resources running in your account. That is the honest answer, and it is the one I want you to demand.

Honest routing one more time: DuploCloud for compliance-heavy organizations, LocalOps for small Heroku-like footprints, OpenTofu or Pulumi plus Argo CD for teams with real in-house Kubernetes expertise, and Render or Fly.io if what you actually want is to stay managed.

What are the most common reasons these migrations fail or overrun?

Nearly every overrun traces back to five things: add-on sprawl discovered mid-migration, a database cutover planned as a dump-and-restore, DNS TTLs not lowered in advance, buildpack-to-Dockerfile drift, and nobody owning the developer workflow after the platform changes. All five are preventable in the inventory phase, and four of them cost nothing to prevent.

• Add-on sprawl. A Redis here, a log drain there, a scheduler nobody documented. Export the full add-on list per app on day one.
• Treating the database as the last task. Replication setup and validation take longer than the app migration and must start in parallel.
• Skipping rehearsal cutovers, then discovering sequence and extension problems during the real window.
• Buildpack-to-Dockerfile drift. Runtime versions, asset compilation, and environment defaults that buildpacks handled implicitly now have to be explicit.
• No traffic-shift gate, so the team flips 100% of traffic with no agreed rollback trigger and no one watching p95.
• Developer-experience regression. Deploys that took 30 seconds now take a pull request against a manifests repo, and velocity drops. This is the failure mode an internal developer platform exists to prevent.

The fix is boring and it works: one named cutover owner, a written runbook with timings taken from your rehearsals, and a rollback trigger agreed before the window opens.

What is the fastest way to migrate from a managed platform like Heroku to AWS, GCP, Azure, or Scaleway with minimal downtime?

Run the new environment in parallel, replicate your Postgres with streaming logical replication or a cloud migration service (AWS DMS, Google Database Migration Service, Azure's migration service), and cut over with a 2-to-5-minute write freeze plus a weighted DNS shift. If you do not have platform engineers, an internal developer platform like Qovery, LocalOps, or DuploCloud gets you deploying in your own cloud account in hours instead of the weeks it takes to hand-build IaC plus GitOps.

Can you migrate a production Postgres database with zero downtime?

Not literally zero, but you can get under 10 minutes. Streaming logical replication held until lag is near zero, then a short write freeze to swap connection strings, is the mechanism. True zero requires application-level dual writes or a proxy that buffers writes during the flip, which is far more engineering than most teams need.

Do I need Kubernetes to migrate off a managed platform?

No. You can target cloud-native runtimes like AWS ECS/App Runner, Google Cloud Run, or Azure Container Apps with no Kubernetes at all. Kubernetes becomes worth it when you have many services and want portability across clouds, and an internal developer platform like Qovery manages the cluster for you so you get Kubernetes without running it by hand.

Is OpenTofu, Terraform, or Pulumi enough to replace Heroku or another managed platform?

No, on their own. They provision infrastructure - the VPC, cluster, and managed database - but they do nothing for application delivery, preview environments, or the git push workflow your developers expect. You pair them with Argo CD or Flux for GitOps, or you use an internal developer platform that covers both layers.

How much does a managed platform to hyperscaler migration cost, and will my cloud bill go down?

The dominant cost is engineering time, not tooling: a hand-rolled move needs 2 to 3 platform engineers over 4 to 9 months. Your runtime bill usually drops because hyperscaler compute and managed Postgres list lower than equivalent dyno and add-on pricing (Heroku Performance-M dynos run $250/mo each, Standard-0 Postgres $50/mo), and with BYOC you can apply Savings Plans or committed use discounts of up to 70% that a managed platform never passes to you.

How does Qovery compare to LocalOps, DuploCloud, Argo CD, and Render for this kind of migration?

Qovery, LocalOps, and DuploCloud all deploy into your own cloud account; DuploCloud leads on compliance evidence (SOC 2, HIPAA, PCI, FedRAMP), LocalOps suits small footprints, and Qovery covers AWS, GCP, Azure, Scaleway, and bring-your-own Kubernetes with preview environments and managed cluster upgrades. Argo CD is a GitOps controller that assumes you already run Kubernetes and author charts. Render is a fully managed PaaS on Render's own infrastructure, so it is a "stay managed" choice, not a move to your own hyperscaler account.

How do you keep fast deployment speeds after moving from a managed platform to a hyperscaler?

Measure deployment frequency and lead time with DORA metrics before and after the move, and treat a drop as unfinished work (DORA). Preview environments per pull request and git-push deploys are what preserve velocity; without them, a 30-second deploy turns into a pull request against a manifests repo and your team slows down. An internal developer platform gives you both on day one so the migration does not cost you speed.

Moving off a managed platform is not one project, it is four, and the teams who treat it that way finish in weeks instead of quarters. Pick your tools per layer, rehearse the database cutover until the timings are boring, and keep the exit-path question on the table for every vendor you consider. 🚀