Airflow 3 is a re-architecture, not an upgrade

Apache Airflow 3 is the biggest change to the project since it entered the Apache Software Foundation. With open-source Airflow 2 reaching end of life on 22 April 2026 — no further bug fixes or security patches — every team still on 2.x is now running unsupported orchestration for its data and AI pipelines.

Treating the move as a routine version bump is the most common mistake we see. Airflow 3 changes how tasks talk to the platform, how DAGs are versioned and how workflows are triggered. Plan it as a platform migration.

What changed under the hood

• Task Execution API and Task SDK: tasks no longer connect directly to the metadata database. They talk to the API server, which improves security and isolation and makes remote and multi-cloud execution practical.
• DAG versioning: Airflow records which version of a DAG each run used, so the UI and history stay accurate as code changes.
• Assets and event-driven scheduling: datasets became assets, and workflows can be triggered by external events such as messages on a queue, not only by schedules.
• A new React-based UI built on a public REST API.
• Scheduler-managed backfills that can be started, monitored and cancelled from the UI and API.
• Removal of long-deprecated features, including SubDAGs and direct database access from task code.

What tends to break

In the migrations we run, a small number of patterns account for most of the work:

• Task code that queries or writes to the Airflow metadata database directly.
• Custom operators, hooks and plugins built against internal Airflow 2 APIs.
• Deprecated imports, context variables and configuration keys.
• SubDAGs that need to be rebuilt as task groups.
• Provider packages pinned to versions that do not support Airflow 3.

A migration plan that avoids downtime

• Inventory: catalogue every DAG, operator, plugin, connection and provider, and run the official upgrade checks and ruff-based linting to flag incompatibilities.
• Remediate on Airflow 2: fix deprecated patterns while still on the old version, so the cut-over changes as little as possible.
• Stand up Airflow 3 in parallel on your target platform — Amazon MWAA, Google Cloud Composer, Astronomer or Kubernetes.
• Validate with real workloads: run representative DAGs side by side and compare outputs, durations and resource use.
• Cut over in waves by domain, with a tested rollback path for each wave.
• Decommission Airflow 2 only after a full business cycle — month-end included — has run cleanly.

Use the migration to modernise

A migration is the cheapest moment to fix what has been bothering the platform team for years: noisy alerts, slow DAG parsing, oversized workers and secrets stored in variables. It is also the moment to adopt what Airflow 3 makes possible — asset-aware pipelines that run when data actually lands, and event-driven workflows that respond to Kafka or cloud queues in near real time.

Where to start

Start with an Airflow health check: a short, structured review of your DAGs, infrastructure, security and upgrade path that ends in a sized migration plan. TrizenAI runs these for teams on every major Airflow platform, and can carry the work through to migration and 24/7 operations.