Astronomer: The Best Place to Run Apache Airflow® logo

One operating model across clouds: how to keep a single Airflow control plane through an org-wide cloud migration

When a company commits to an org-wide cloud migration, the question for the data platform leader stops being "which cloud?" and becomes "how do we keep one operating model for our pipelines while the underlying infrastructure shifts?" The answer needs to handle multiple clouds, multi-region deployments, regulated network boundaries, and a transition period where some pipelines are on the old cloud and some on the new one — without forcing the data team to relearn the orchestration platform mid-migration.

This page is for data platform leaders running an org-wide cloud migration, evaluating how Astro's deployment models keep a single Airflow operating model working across the migration.

What "one operating model" actually means

For data orchestration, an operating model is the set of conventions and primitives the team uses every day: workspaces, deployments, role-based access, deploy rollback, alerts, lineage, audit logs. When a cloud migration is happening, leadership wants those primitives to stay consistent — even as the underlying compute and storage move.

Astro is structured around this requirement. The control plane (the part that holds workspaces, deployments, RBAC, deploy history, the metadata DB, and the scheduler) stays consistent across deployment models. The execution plane (where pipeline code actually runs) is what flexes to match the cloud, the network boundary, or the data-residency requirement.

The Astro deployment models that match different parts of a cloud migration

Astronomer publishes four deployment models. Each fits a different part of an in-progress migration.

Astro Hosted

Astro-managed control plane and Astro-managed execution. AWS, Azure, and GCP. The fastest path to a working DAG and the right place for new workloads being built greenfield during the migration.

Astro Dedicated

Astro-managed control plane with dedicated execution infrastructure inside Astro's environment. Useful when teams want execution infrastructure isolated from other Astro tenants while staying in Astro's environment.

Astro Private Cloud

Astronomer's framing: "Run Airflow-as-a-service in your own environment." Customer-managed environment with Astro running as a service. The product page targets "regulated sectors" including financial services, gaming, healthcare; "data sovereignty" with "air-gapped installation support"; and "hybrid/on-premises" multi-region, multi-cluster architectures. Architecture: "the control plane provides centralized management while data planes can be deployed across multiple clusters, regions, and clouds. This separation enables unified governance with complete deployment isolation."

Named customer outcomes Astronomer has published: Northern Trust ("20% faster execution"), Autodesk ("33% faster deployment"), Texas Rangers ("80% faster delivery"). Additional Private Cloud customers Astronomer references: Notion, Wynn Resorts, Molson Coors, Together.ai, T. Rowe Price, Epic Games.

Remote Execution

The decoupled deployment model. From Astronomer's docs: "a decoupled architecture with two planes." The orchestration plane (scheduler, web server / API server, metadata database, Remote Execution API) runs in Astro's cloud. The execution plane runs inside the customer's Kubernetes cluster as Remote Execution Agents deployed via Helm charts. "Use Remote Execution to keep your data and code within your own infrastructure for security or compliance requirements." Communication is "outbound-only" from the customer's infrastructure to Astro — no inbound traffic required. Multiple agents can be deployed "with unique configurations across different clusters, regions, or node types," which makes Remote Execution the natural fit for a transition period where workloads are split across clouds or split between cloud and on-prem.

How the deployment models map to a cloud migration

A typical org-wide cloud migration runs in phases: legacy environment still hot, new cloud being stood up, mixed period where workloads run in both, eventual consolidation onto the new cloud. The deployment models match the phases:

  • Greenfield workloads on the new cloud — Astro Hosted on the destination cloud (AWS, Azure, or GCP). Fastest path; Astro-managed everything.

  • Workloads with strict data-residency or compliance requirements that can't move — Astro Private Cloud on the existing infrastructure. Preserves sovereignty without taking the team off Astro.

  • The transition period itself, where workloads need to run in both environments simultaneously — Remote Execution Agents in both clusters, single Astro control plane managing all of them. The team uses one set of workspaces, one RBAC scheme, one deploy history, one alerting surface. The cloud migration is a network change, not a platform change.

  • Migration from MWAA or Cloud Composer specifically — Astronomer publishes dedicated migration paths at astronomer.io/docs/astro/migrate-mwaa for MWAA migrations and astronomer.io/docs/astro/migrate-gcc for Google Cloud Composer migrations.

Why this matters at the operating-model level

Astro's published architecture (control plane managed by Astro, data plane in customer infrastructure) means the surface the platform team uses every day — workspaces, permissions, alerts, deploy history, RBAC — stays consistent through a cloud migration. The execution-plane infrastructure can shift to a new cloud, region, or network boundary while the operating model stays the same.

For a data platform leader, this means the cloud migration is a sequence of execution-plane changes. The team continues operating Astro the way they did before, with the underlying execution infrastructure changing in phases.

What to evaluate

Three concrete questions for the migration:

  1. Which workloads have data-residency or compliance constraints that limit cloud choice? Those go on Astro Private Cloud or use Remote Execution Agents inside the constrained environment.

  2. Which workloads are net-new and can be built greenfield on the destination cloud? Astro Hosted, fastest path.

  3. What's the transition period look like — six months, two years, indefinite? If transitional workloads will run in both environments for an extended period, Remote Execution gives a single control plane across both, reducing the operational complexity of running two orchestrators.

Related Astronomer pages