Version-by-version upgrade pages for Airflow 3 and the breaking changes buyers hit when leaving Airflow 2: removed features, API and plugin changes, database migration and the Helm chart.
Moving from Airflow 3.2 to 3.3: the task and asset state store, pluggable retry policies, Java and Go Task SDKs, histogram timer metrics, the pandas 3 XCom change in 3.3.1 and the bearer token precedence change in 3.3.2.
Moving from Airflow 3.1 to 3.2: SQLAlchemy 2.0, removed TaskInstance and PriorityWeightStrategy methods, the MySQL client dropped from images, Python 3.14, multi-team mode and gunicorn for the API server.
Moving from Airflow 3.0 to 3.1: Python 3.9 removed, one API server worker by default, structlog logging, the independently upgradable Task SDK, and new features such as Deadline Alerts and human-in-the-loop tasks.
Using the last Airflow 2 line as a stepping stone: why the upgrade guide wants 2.7 or later and ideally the latest 2.x, installing the standard provider early, running Ruff AIR checks on 2.x, and how long 2.11 can stay in production.
What Airflow 2 end of life on April 22, 2026 means for teams still on 2.x: no security fixes, provider packages moving on, managed services still offering 2.11, and choosing between a fast Airflow 3 move and a planned one.
Rewriting SubDagOperator usage before Airflow 3: when a TaskGroup is the direct replacement, when assets or data-aware scheduling fit better, keeping task IDs stable for history, and testing the rewritten DAGs.
Finding and replacing execution_date, prev_ds, next_ds and the other removed context keys before an Airflow 3 upgrade: logical_date and data interval equivalents, templated fields, and Ruff checks that catch them.
Moving scripts, CI jobs and integrations from /api/v1 to the Airflow 3 /api/v2: token authentication instead of basic auth, the /auth route prefix, the Python client, and the 3.3.2 credential precedence change.
Rewriting tasks that queried or updated the Airflow metadata database: what breaks in Airflow 3, moving to the REST API or Task SDK, the temporary hook workaround and its risks, and the security reason behind the change.
Using Ruff to find Airflow 3 breaking changes across a DAG repository: AIR301 and AIR302 versus AIR311 and AIR312, safe and unsafe fixes, the airflow.sdk import moves, and wiring the check into CI before the upgrade.
Porting Airflow 2 UI plugins, menu items and blueprints to Airflow 3: FastAPI apps, external views and root middlewares, the FAB provider compatibility layer, and custom webserver_config.py security manager imports.
Upgrading a Kubernetes deployment to Airflow 3 with the official chart: webserver to apiServer values, the standalone DAG processor, migration jobs under GitOps tools, and testing the chart upgrade in a staging release.
Protecting the metadata database through an upgrade: consistent backups, trimming history with airflow db clean, reserializing DAGs, running airflow db migrate, timing the downtime window and the rollback plan.
Keeping provider packages current without breaking Airflow: version pinning, minimum Airflow versions per provider, constraint files, testing operator changes such as durable BigQuery jobs, and upgrading providers on a separate cadence from core.
Planning a Python upgrade for Airflow workers, schedulers and images: supported Python 3.10 to 3.14, versions dropped in 3.1, matching constraint files, rebuilding images and testing dependencies that lag behind.
Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.