How to Plan a Phased Hybrid Cloud Migration Without Taking Production Down

Key Points:

• A phased hybrid cloud migration runs in six phases: discovery and dependency mapping (weeks 1-6), landing zone plus network interconnect (weeks 4-12), a pilot wave (weeks 10-16), production waves by dependency cluster (months 4-12), data-heavy and legacy waves, then decommissioning. Each phase needs written entry criteria, exit criteria, and one named person authorised to call a rollback.
• Sequence by dependency cluster, not by an application list. Move stateless tiers first and data last. Only split an application from its database across the WAN when round-trip latency stays in the low single-digit milliseconds and the app makes fewer than roughly 10 queries per request. Otherwise move the app and its database in the same wave.
• Near-zero downtime comes from replication plus traffic shifting, never from a maintenance window. Seed a full data copy, run change data capture until lag is near zero, freeze writes for seconds, verify row counts and checksums, then shift traffic 1% to 10% to 50% to 100% with a rollback you have already rehearsed and timed.
• Order the dedicated interconnect first. A site-to-site IPsec VPN comes up in hours, but a Direct Connect, ExpressRoute, or Cloud Interconnect circuit takes weeks of carrier lead time, and that single date sets the earliest possible first production wave.
• Hybrid is a transition state with a written end date, typically 12-24 months for a mid-sized estate. The expensive failure mode is operational duplication (two CI/CD paths, two environment definitions, two on-call rotations), not a failed cutover. Standardising deployment across on-premise Kubernetes and cloud accounts turns each wave into a target change instead of a platform rebuild.

Three quarters of large cloud migration programmes run over budget, according to McKinsey's survey of roughly 450 CIOs and IT leaders, and only 15% hit their migration target inside the timeline they set. The number that makes those overruns dangerous sits one layer down: one hour of downtime costs $300,000 or more for 91% of mid-size and large enterprises, and $1M to over $5M per hour for 41% of them, per the ITIC 2024 Hourly Cost of Downtime survey.

So the real brief for a hybrid migration is not "get to the cloud." It is "move the whole estate while production keeps serving, and do it without a single cutover becoming a line item at a quarter of a million dollars an hour." I have planned and watched enough of these to believe the cutovers are rarely what breaks. What breaks is the plan: the wave ordering, the interconnect date nobody put on the calendar, and the twelve months of running two of everything.

This is the plan I would hand a peer about to sign off on an 18-month migration. It works the same whether your target is AWS, GCP, Azure, Scaleway, or a Kubernetes cluster you already run. I will name one provider inside examples and show the equivalents from the others in the same row.

What does a phased hybrid cloud migration actually look like?

A phased hybrid cloud migration is a wave-by-wave move in six stages - discovery, landing zone, pilot wave, production waves, data and legacy waves, decommission - during which on-premise and public cloud both serve production traffic for a fixed, written period, and every wave can be rolled back independently. Hybrid here means something precise: on-premise, colo, or private cloud plus one or more public clouds serving production at the same time, joined by private connectivity, one DNS view, and one identity source.

That posture is the default, not the exception. 73% of organisations run a hybrid estate, up three points year over year, per the Flexera 2026 State of the Cloud Report, and the Nutanix 2024 Enterprise Cloud Index found 46% already on a hybrid or hybrid-multicloud model with that share projected to roughly double in three years. You are not building something exotic. You are building the steady state most enterprises already live in.

The six phases, each with a one-line definition of done:

• Phase 0 - Discovery (weeks 1-6): inventory complete, dependency map drawn, dead apps retired, hybrid end date agreed in writing.
• Phase 1 - Landing zone (weeks 4-12): interconnect ordered, network and identity live, observability spans both sides, deployment layer standardised.
• Phase 2 - Pilot wave (weeks 10-16): one low-criticality stateless service running in the cloud end to end, with a rollback drill you actually executed and timed.
• Phase 3 - Production waves (months 4-12): dependency clusters migrated 2-6 weeks per wave, each with a go/no-go and a bake period.
• Phase 4 - Data and legacy waves: the slow, expensive tail - large databases and tightly coupled monoliths.
• Phase 5 - Decommission: old capacity reclaimed, duplicated licences cancelled, run-rate measured against the business case.

A wave is the smallest set of services that can be cut over and rolled back together. That is a dependency cluster, not a row from a spreadsheet. If service A cannot function without service B and database C, those three are one wave, because rolling back A alone would strand the other two.

Name the hybrid end date out loud, because parallel running is expensive on every axis at once: double infrastructure, double on-call, double toolchain, duplicated licences, and duplicated compliance evidence. The sequencing logic above is identical across AWS, GCP, Azure, Scaleway, or an existing managed or self-managed Kubernetes cluster. Only the landing-zone details change.

One clarification, since the terms get mixed up. Lift-and-shift is a per-workload strategy (move a VM as-is). Phased hybrid is how you sequence the whole programme. Both can be true at once: you can lift-and-shift a given app inside a phased hybrid plan.

How do I decide what to move first - and what should never move?

Score every workload on business criticality and dependency depth, migrate low-criticality low-dependency stateless services first, group everything else into dependency clusters that move together, and leave data-heavy and tightly coupled systems for the final waves. Before any of that, retire dead applications in wave 0. The cheapest workload to migrate is the one you switch off instead.

Build an inventory with the fields that actually drive decisions:

• App, owner, runtime, data store - the identity of the thing.
• Inbound and outbound dependencies - what calls it and what it calls.
• Compliance class, peak traffic, licence model - the constraints.
• Hardware depreciation date, last deploy date - the signals for retain versus retire.

Do the dependency mapping with more than one source, because no single source is complete. APM service maps, VPC and firewall flow logs, and on-prem netflow get you most of the graph. A manual review with each owning team gets you the rest, because automated discovery reliably misses cron jobs, overnight batch windows, hard-coded IPs, and that one Windows box nobody will admit to owning.

The wave-grouping rule, stated as a number you can apply: count the cross-service and cross-database calls per request, multiply by your measured WAN round-trip time, and that is the latency you add if you split those components across the hybrid line. An app that makes 30 database round trips per request, split from its database over a 10 ms WAN hop, just added 300 ms to every request. Keep the app and its database in the same wave unless round-trip latency sits in the low single-digit milliseconds and the app makes fewer than roughly 10 queries per request.

Some things should never move, and "retain" is an engineering decision, not cowardice. Keep on-premise anything bound by data residency rules, hardware-locked licensing, sub-millisecond latency to factory, trading, or lab equipment, or recently bought hardware with years of depreciation left. Retention is common and rising: the Barclays CIO survey reported that 83% of CIOs planned to move at least some workloads back from public cloud in 2024, though only a single-digit share repatriate everything. The signal is selective, not a retreat.

The 7 Rs, each in one line, with the wave it usually lands in:

• Retire - switch it off. Wave 0.
• Retain - leave it on-premise for now. Any wave, by exception.
• Rehost - move as-is (lift-and-shift). Early waves.
• Replatform - minor changes, like a managed database. Mid waves.
• Repurchase - swap for SaaS. Opportunistic.
• Relocate - move the hypervisor wholesale (VMware-style). Early, when it fits.
• Refactor - rebuild for cloud-native. Late, and only where the payback is real.

Wave 0 checklist, copy it verbatim: freeze new on-prem provisioning, retire dead apps, agree the end date in writing, publish the inventory, and name one rollback owner per planned wave.

How do I keep on-premise and cloud workloads talking during the transition?

Build and load-test the hybrid connectivity layer before the first production wave: private connectivity, non-overlapping IP ranges, split-horizon DNS, one identity plane, and one observability backend covering both sides. Order the dedicated interconnect first, because its carrier lead time, not your engineering, sets the earliest date for wave 1.

You have three connectivity shapes:

• Site-to-site IPsec VPN - up in hours, cheap, but latency rides the public internet and varies.
• Dedicated interconnect (AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect) - predictable latency, a published SLA, and weeks of lead time.
• Partner / hosted connections - for sub-1 Gbps needs or when you cannot reach a colocation facility yourself.

The SLA numbers let you justify redundancy to a CFO with a figure rather than a feeling. AWS Direct Connect publishes 99.99% for a maximally resilient multi-site design, 99.9% for high resiliency, and only 92.5% for a single connection, which is more than two days of allowed downtime a month. Azure ExpressRoute carries a 99.95% SLA, and Google Cloud Interconnect offers 99.9% with two connections or 99.99% with four across separate metros. A single circuit is never a production-grade answer; buy the redundant pair.

Put the interconnect date on the plan on day one. A VPN tunnel is a same-day task, but a cross-connect is a physical thing a carrier provisions, and Google's own provisioning guide notes the physical step commonly takes two to four weeks, sometimes longer once the cross-connect, circuit, and testing are included. That date is your real wave-1 start, so bring up a VPN immediately for early work and let the dedicated circuit catch up.

The rest of the connectivity layer, in priority order:

• IP address planning first. Overlapping RFC1918 ranges between the datacenter and the new VPC is the single most common hard blocker. Resolve it before anything else: renumber, NAT, or carve a dedicated non-overlapping supernet for cloud.
• Split-horizon DNS so one hostname resolves correctly from both sides, with TTLs lowered days ahead of any cutover.
• One identity plane (SSO / OIDC) and one secrets store, not one per environment. Two identity planes means two offboarding processes and an audit finding waiting to happen.
• One metrics, logs, and traces backend spanning both sides before wave 1. Without a shared baseline you cannot prove a wave was non-disruptive, which means you cannot pass a go/no-go honestly.
• Measure the latency tax before you move anything. Record baseline round-trip time and cross-WAN calls per request, then set a per-wave latency budget that triggers rollback when breached.

What is the safest way to migrate a production database without downtime?

Near-zero-downtime data migration is a replication-then-cutover pattern: bulk load a full copy, run continuous change data capture until replication lag is near zero, freeze writes for seconds, verify row counts and checksums, then flip the connection string with reverse replication still armed for failback. Expect seconds of write freeze, not zero, and say so to whoever signs the plan. Anyone promising literal zero for a relational cutover is selling something.

The canonical sequence, in order:

1. Bulk load a full snapshot into the target.
2. CDC or log shipping streams every change since the snapshot.
3. Lag monitoring until replication lag is near zero.
4. Short write freeze - seconds, while the last changes drain.
5. Checksum verification - row counts and checksums match.
6. Connection string flip - the app points at the new database.
7. Reverse replication kept running through the bake period, so failback is a config change.

The managed services do most of this for you, and they are near-identical across clouds. AWS Database Migration Service runs a "full load plus CDC" task that loads existing data and then applies ongoing changes for minimal-downtime cutovers. Google Cloud Database Migration Service and Azure Database Migration Service offer the same continuous-replication model. For do-it-yourself pipelines there is Debezium, and the engine-native options: logical replication and pg_logical for PostgreSQL, GTID-based replication for MySQL.

Read the preconditions before you trust the "minimal downtime" label. CDC generally requires primary keys on replicated tables, the right source logging (supplemental logging on Oracle, row-based binlog on MySQL, logical replication slots on PostgreSQL), and careful handling of large objects. Native logical replication has real gaps worth knowing: PostgreSQL logical replication does not replicate schema/DDL changes, sequences, or large objects, and MySQL replication has its own constraints around DDL and non-deterministic statements. Those gaps are exactly where a "near-zero" cutover turns into a silent data drift if you do not plan for them.

Where writes genuinely cannot pause, use dual-write or the strangler-fig pattern - but go in clear-eyed: ordering, idempotency, and reconciliation all become your problem, and a reconciliation job is not optional. For file and object data, run a multi-pass incremental sync (rsync, AWS DataSync, Google Storage Transfer Service) and a final delta on cutover day. If the dataset is too large for your WAN window, seed it with an appliance (AWS Snowball, Azure Data Box, Google Transfer Appliance) and sync only the delta over the wire.

Define the data rollback explicitly: keep the on-premise database as a reverse-replication target for a stated number of days so failback is a connection string change, not a restore from backup. And write the acceptance criteria before the window: row counts match, checksums match, p99 query latency within a stated percentage of the on-premise baseline, and no error-rate increase after 24 hours. The ITIC downtime figures above are what buys you the budget to do replication properly instead of gambling on a maintenance window.

How do I cut over traffic with zero disruption and roll back if it goes wrong?

Cut over by shifting a percentage of real traffic with an instant reverse path - 1%, then 10%, 50%, 100% - using numeric rollback triggers agreed before the window and a rollback you have already rehearsed and timed. Never use a big-bang maintenance switch for anything that matters. The whole point of the phased approach is that a bad wave affects 1% of traffic for the minute it takes to shift it back.

The traffic-shifting mechanisms, with their catch:

• Weighted DNS - simple and provider-agnostic, but some resolvers ignore your TTL, so it is coarse and slow to fully propagate.
• Global or regional load balancer weighting - precise percentage control, fast to change, the workhorse for stateless tiers.
• Ingress or service mesh canary - percentage or header-based routing inside Kubernetes, ideal when both sides run on clusters.
• Application-level feature flags - the finest control, routes by user or tenant, but you own the code path.

Operational detail that saves you on the day: drop DNS TTLs to 60 seconds several days before the window and verify that your real resolvers honour them (test, do not assume). AWS Route 53 and equivalent DNS services document TTL behaviour, and a low TTL set ahead of time is what lets a DNS-based rollback take effect in a minute instead of a day.

Write the rollback triggers as numbers before the window, not as judgement calls during it:

• Error rate above baseline plus X%.
• p95 latency above Y ms.
• Queue depth above Z.
• Failed health checks beyond a set count.

Then name the single person authorised to call the rollback without a meeting. A rollback that needs a committee is a rollback that happens 20 minutes too late.

Two practices make the difference between hoping and knowing:

• Game day. Run the cutover and the rollback against a non-production copy of the wave, record how long the rollback took, and publish that number as the wave's recovery time. An unrehearsed rollback is a theory.
• Shadow or parallel run for critical systems. Mirror real traffic to the cloud side and diff responses before it serves a single user.

Keep the old environment warm for a defined bake period, commonly one to four weeks, before you decommission anything, and decide up front who pays for that overlap. Say plainly what you are promising per tier: zero downtime for stateless services, seconds of write freeze for stateful ones.

How do I avoid running two completely different platforms during the hybrid phase?

Standardise the deployment and environment layer across on-premise Kubernetes and cloud accounts before wave 1, because the dominant cost of a phased migration is operational duplication - two CI/CD paths, two environment definitions, two access models, two runbooks - not the cutovers themselves. You will spend 12-24 months in the hybrid state. That is a long time to maintain two of everything.

The duplication shows up as concrete symptoms: pipelines rewritten per wave, environment configs that drift apart, product teams blocked waiting on a platform squad, different RBAC on each side of the line, two sets of runbooks, and two on-call rotations for what is logically one service.

The fix is to standardise on contracts, not tools: one way to describe an application (image, env vars, dependencies, resource needs), one way to promote it between environments, and one way to grant access, implemented identically on both sides of the hybrid line. Kubernetes is why this is achievable now. The same workload definition runs on an on-premise cluster and a managed cloud cluster, which removes most per-wave engineering. Production Kubernetes use reached 80% in the CNCF 2024 Annual Survey and 82% in the 2025 edition, which is why hybrid programmes keep converging on it as the common substrate.

The reason to decide this before wave 1 is a scheduling reason, not a taste one. Gartner predicted 80% of software engineering organisations would run platform teams by 2026, up from 45% in 2022, and Flexera's survey work consistently lists shortage of resources and expertise among the top cloud challenges. A skills gap turns duplication from a cost line into a schedule risk: the same scarce engineers get asked to run two platforms at once, and the waves queue up behind them.

Be fair about the tools, because a reader should trust this comparison even if they never touch Qovery:

• Terraform and Crossplane provision infrastructure well. They do not give developers self-service app delivery; someone still wires up the pipeline on top.
• Argo CD and Flux reconcile manifests reliably. You still write and maintain every one of those manifests.
• Backstage is a strong developer portal, but it is a framework you build, staff, and keep running.
• Humanitec orchestrates platforms for teams that already have a platform squad to drive it.
• Red Hat OpenShift standardises the cluster layer across on-prem and cloud, at enterprise licence cost.
• AWS MAP, Azure Migrate, and Google's Rapid Migration Program fund and tool the move itself, then stop at the migration boundary and leave day-2 delivery to you.

Where Qovery fits: Qovery deploys and operates applications inside your own cloud account on AWS, GCP, Azure, or Scaleway, so the cloud bill and any Savings Plans or committed-use discounts stay in your name, and it also deploys onto an existing Kubernetes cluster, including self-managed and on-premise. That last part is what makes it relevant mid-migration: the same git-push deployments, preview environments per pull request, and per-environment RBAC work on your on-premise cluster and your new cloud account alike, so a wave becomes a target change rather than a platform rebuild. Other capabilities that earn their keep during parallel running: managed cluster upgrades, environment auto-stop for non-production (directly useful when you are paying for two estates), and databases backed by managed cloud services. It is a platform for production teams, not a hobby tier.

What does the phase-by-phase plan and timeline look like in practice?

A realistic phased hybrid migration for a mid-sized estate runs 12-24 months across six phases, each with entry criteria, exit criteria, a named rollback owner, and a monthly scorecard tracking waves completed, workloads retired, parallel-run cost, and migration-caused incidents. The scorecard is what keeps the end date real instead of drifting another quarter every quarter.

The phases, as a running plan:

• Phase 0 (weeks 1-6): inventory, dependency map, retire dead apps, agree the hybrid end date in writing, name rollback owners.
• Phase 1 (weeks 4-12, overlapping phase 0): landing zone, interconnect ordered first because of carrier lead time, identity, observability, platform standardisation.
• Phase 2 (weeks 10-16): pilot wave - one internal, low-criticality, stateless service end to end, including a rollback drill you execute and time.
• Phase 3 (months 4-12): production waves by dependency cluster, 2-6 weeks per wave, with a bake period between waves and a go/no-go per wave.
• Phase 4: data-heavy and legacy waves, the slowest and most expensive, where most schedule overrun hides. Budget more here than feels reasonable.
• Phase 5: decommission, reclaim datacenter capacity, cancel duplicated licences, measure the actual run-rate change against the original business case.

On the money: cloud spend rises before it falls. You are paying for both estates during the overlap, and the Flexera 2026 report puts self-reported wasted cloud spend at 29%, the first uptick after years of decline. Track unit cost per workload, avoid long commitments until steady state is visible, and show parallel-run cost as its own line on the monthly scorecard so nobody pretends the overlap is free.

How do I run migration waves with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills once, then describe the wave in plain language to your coding agent and approve each action. Add the MCP Server when you want the agent to inspect or operate what already runs. Every action is scoped and asks for approval, which matters when the blast radius is production traffic mid-migration.

• Install the skills globally for any compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI). It writes the skills to your agent config and asks you to confirm before it does:

curl -fsSL https://skill.qovery.com/install.sh | bash

• Scope the install to a single repository instead of your whole machine, when you only want the skills in one project:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

• Add the Qovery MCP Server to Claude Code, read-only by default, to inspect what already runs before changing anything. It opens a browser for you to approve the OAuth grant:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

• Enable write access only when you want the agent to change things (this also requires enabling write access in the Qovery Console):

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

What is covered: the skills qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, and qovery-terraform handle deployment; the MCP Server operates what already exists. Example prompts for a wave: "deploy this service to my GCP account with Qovery and keep the database connection pointing at the on-prem host", "create a preview environment for this pull request", or "show me which non-production environments are idle and can auto-stop".

The reference pages are the AI agent quickstart and the Claude Code integration page.

Frequently asked questions

In what order should I migrate workloads in a hybrid cloud migration?

Migrate low-criticality, low-dependency stateless services first, then production dependency clusters, then data-heavy and legacy systems last, and retire dead applications in wave 0 before migrating anything. Sequence by dependency cluster (the smallest set of services that can be cut over and rolled back together), not by an application list. This gives you an early, low-risk wave to rehearse your rollback against before you touch anything critical.

Should I migrate my database before or after the application that uses it?

In the same wave, unless the app can tolerate the WAN hop. Only split an application from its database across the hybrid line when round-trip latency stays in the low single-digit milliseconds and the app makes fewer than roughly 10 queries per request. The threshold depends on cross-WAN calls per request: an app making 30 database round trips over a 10 ms link adds about 300 ms to every request, so measure your calls-per-request and your WAN latency before deciding, and when in doubt move the app and database together.

How long should a phased hybrid cloud migration take?

For a mid-sized estate, plan on 12-24 months across six phases. Discovery runs weeks 1-6, the landing zone weeks 4-12, a pilot wave weeks 10-16, production waves across months 4-12, then data-heavy and legacy waves and decommissioning. The data and legacy tail is where most schedule overrun hides, so budget more time there than feels comfortable.

Can I really migrate production with zero downtime, or only near-zero?

Zero downtime for stateless tiers, near-zero (seconds of write freeze) for stateful ones. Stateless services shift with weighted load balancing and roll back in seconds. A relational database cutover uses replication plus change data capture, and the final write freeze while the last changes drain is measured in seconds, not zero. Anyone promising literal zero downtime for a relational cutover is overselling.

What is the difference between a phased hybrid migration and a lift-and-shift?

Lift-and-shift is a per-workload strategy: move an application as-is, without redesigning it. A phased hybrid migration is how you sequence the whole programme: wave by wave, with on-premise and cloud both serving production for a fixed period. They are not alternatives. You can lift-and-shift an individual application inside a phased hybrid plan, and most programmes mix lift-and-shift with replatforming and retirement across waves.

How do I estimate and control the cost of running on-premise and cloud in parallel?

Expect cloud spend to rise before it falls, because you pay for both estates during the overlap. Track unit cost per workload, show parallel-run cost as its own line item on a monthly scorecard, and avoid long-term commitments until your steady state is visible. The Flexera 2026 State of the Cloud Report puts self-reported wasted cloud spend at 29%, so the overlap period is exactly when waste creeps in if nobody is watching the line.

What should I do first when planning a hybrid cloud migration?

Order the dedicated interconnect and build the inventory, in that order. The interconnect (Direct Connect, ExpressRoute, or Cloud Interconnect) carries weeks of carrier lead time, commonly two to four or more, and that date sets the earliest possible first production wave, so it goes on the plan on day one. In parallel, build the workload inventory and dependency map, retire dead applications, and agree the hybrid end date in writing before any workload moves.

Three quarters of these programmes run over budget, and the ones that do not are the ones that treated hybrid as a transition with a written end date, not a permanent arrangement nobody dares to close out. If you want the deployment layer to look the same on your on-premise cluster and your new cloud account from wave 1, Qovery runs in your own AWS, GCP, Azure, or Scaleway account or on your existing Kubernetes cluster, and you can have the first service deploying in under 10 minutes.