Airflow 2 End of Life: Planning the Upgrade to Apache Airflow 3

Apache Airflow 2 reached end of life on 22 April 2026, according to the project’s Supported Versions page. Its last release is 2.11.2. The project’s security model states that security advisories are issued only for release lines that still receive releases, and that users on an end-of-life line should upgrade. For teams still running Airflow 2, the move to Airflow 3 is no longer optional maintenance; it is the only route back to a line the community still fixes.

Airflow 3 is not a routine upgrade. It changes how tasks talk to the platform, removes features that many Airflow 2 Dags still use, and changes several defaults. This article sets out where the release lines stand on 26 October 2026, what changes, how to choose a target version, and a planning sequence that keeps the risk visible.

Where Airflow releases stand on 26 October 2026

The table combines the Supported Versions page with the release history on PyPI, both accessed on 26 October 2026.

Line	State	Releases	Lifecycle dates published by the project
Airflow 3	Maintenance	3.0.0 on 22 April 2025; 3.3.0 on 6 July 2026; latest 3.3.2 on 17 September 2026	Limited maintenance and end of life: to be decided
Airflow 3.4	Pre-release	3.4.0 beta 1 on 13 October 2026 and beta 2 on 20 October 2026	Not yet released as final
Airflow 2	End of life	Last release 2.11.2 on 14 March 2026	Limited maintenance from 22 October 2025; end of life on 22 April 2026
Airflow 1.10	End of life	Last release 1.10.15	End of life on 17 June 2021

The project defines limited maintenance as security and critical bug fixes only, and end of life as no fixes or support. It has not published an end date for Airflow 3, so plans should not assume one.

What end of life means in practice

An end-of-life Airflow 2 deployment keeps running. What stops is the flow of fixes. The security model says that issues reachable only on end-of-life lines are not handled through the security process. The security policy adds that Airflow core and provider packages are released separately, and that fixes in providers do not apply to the core package.

The security model matters for another reason. It treats Dag authors as trusted users who can run arbitrary code on workers, in the Dag processor and in the triggerer. Airflow does not sandbox that code. An unpatched platform that runs code from many teams carries more risk than an unpatched single-purpose service.

Managed services set their own timelines. The Amazon MWAA versions page still listed Airflow v2.11.2 and v2.11.0 alongside Airflow 3 releases on the research date, with AWS publishing its own end-of-support dates for each version. Google’s Cloud Composer versions page also listed images for both Airflow 2 and Airflow 3. Those providers decide what they support. They do not change the community’s end-of-life date for the open-source line.

What changes in Airflow 3

The Airflow 3 release announcement introduced Dag versioning, scheduler-managed backfills, assets with event-driven scheduling, a new React UI on FastAPI, and the Task Execution Interface. The last of these drives most of the upgrade work.

The architecture overview describes the components of an Airflow 3 deployment: a scheduler, a Dag processor that parses Dag files from a Dag bundle, an API server that serves the UI and REST API, and a metadata database, usually PostgreSQL or MySQL. Workers and a triggerer are optional. Tasks use the Task SDK and report state through the API server, without direct access to the metadata database.

The Airflow 3 upgrade guide lists the changes most likely to break existing Dags and deployments:

Area	Change in Airflow 3	What to do
Task code	Direct metadata database access from tasks is removed	Rewrite custom operators to use the Airflow Python client or supported APIs
SubDAGs	Removed	Move to TaskGroups, assets and data-aware scheduling
SLAs	Removed	Replace with Deadline Alerts
Context variables	execution_date, prev_execution_date, next_ds, yesterday_ds and others are removed	Update templates and task code; use logical_date where the requested date matters
Executors	SequentialExecutor, CeleryKubernetesExecutor and LocalKubernetesExecutor are removed	Use LocalExecutor or a multiple-executor configuration
REST API	Version 1 is replaced by /api/v2	Update scripts, CI jobs and integrations that call the API
Defaults	catchup_by_default and create_cron_data_intervals now default to False	Set them explicitly before upgrading if Dags rely on the old behavior
Authentication	Simple Auth Manager is the default; FAB needs the FAB provider; auth routes move under /auth	Plan SSO changes and update external OAuth redirect URLs
Plugins	Flask-AppBuilder views, menus and blueprints need conversion	Port them to FastAPI, or use the FAB provider’s compatibility layer
XCom	xcom_pull() without task_ids pulls only from the current task	Pass task_ids explicitly

Operators such as BashOperator and PythonOperator now come from the apache-airflow-providers-standard package, which must be installed. Deployments on Kubernetes also need chart changes: the guide notes that the Helm chart renames webserver settings to apiServer.

Choosing a target version

The release process page explains the cadence. The project aims to follow semantic versioning, with feature releases roughly every two or three months and patch releases as needed. Patch releases carry bug and security fixes only. The page also warns that semantic versioning is not a promise of full compatibility, and that experimental features can change between feature releases.

On the research date, that points to the latest 3.3 patch release as the production target. Airflow 3.4 was still in beta, so it belongs in a test environment until a final release ships. Check the 3.3 release notes as well: the Airflow 3.3.0 announcement notes that OpenTelemetry timer metrics changed from gauges to histograms, and that one Dag processing metric now uses tags. Dashboards and alerts built on Airflow 2 metrics will need review either way.

Plan beyond the first upgrade. With a feature release every few months and fixes landing on current releases, an Airflow 3 platform needs a regular upgrade rhythm, not another multi-year freeze.

A planning sequence for the Airflow 2 to 3 upgrade

The steps below follow the order in the upgrade guide, with the inventory and rehearsal work we add around it.

1. Inventory. List every deployment, its exact version, executor, providers, plugins, custom operators, auth setup and external callers of the REST API.
2. Reach a supported starting point. The guide requires Airflow 2.7 or later and recommends the latest 2.x release first. Remove features that Airflow 3 no longer has while still on Airflow 2.
3. Run the upgrade checks. Use Ruff 0.13.1 or later with the AIR rules: AIR301 flags breaking changes, and AIR311 and AIR312 flag recommended updates. Run airflow config update to review configuration changes.
4. Refactor and test Dags. Fix what the checks report, install the standard provider, remove direct database access from custom operators, and test every Dag in a staging environment on Airflow 3.
5. Prepare the metadata database. Take a consistent backup, shutting Airflow down first if you lack hot backups, then run airflow db clean to reduce migration time and confirm that airflow dags reserialize runs without errors.
6. Rehearse the migration. Run airflow db migrate on a copy of the production database, start the new services, and compare pipeline results with the old platform.
7. Cut over. Update start-up scripts to run airflow api-server and a separate airflow dag-processor, migrate production in an agreed window, and verify authentication and SSO before reopening the platform.

Risks to plan for

The upgrade guide does not describe a downgrade path. It warns that a failed migration can leave the database half-migrated, which is why the backup step comes first. Treat the backup and a tested restore as the rollback plan, and agree a go or no-go point before the production migration.

• Hidden database access. Custom operators and hooks that query Airflow’s own tables often surface only at run time. The guide describes a hook-based workaround but warns that it will break in future versions.
• Date semantics. Manual runs may have a data interval that differs from the requested logical date. Dags that compute partitions from interval boundaries need explicit tests.
• Authentication. Changing the auth manager or the login routes can lock users out or break SSO. Test it with real identity provider settings in staging.
• External callers. Scripts and tools that call the version 1 REST API stop working. Find them through access logs before cutover.
• Executor changes. Teams on CeleryKubernetesExecutor or LocalKubernetesExecutor need a new executor design, which is a capacity and isolation decision as well as a configuration change.

Upgrades on managed services

Managed services do not remove the Dag work. The Amazon MWAA versions page states that MWAA supports minor version upgrades in place, but not upgrades to a new major version. Moving an MWAA environment from Airflow 2 to Airflow 3 is therefore a new environment, and AWS points to its migration guide for that path. Dag and plugin changes are the same on any platform, because they follow from Airflow itself. Teams comparing self-managed Airflow with a managed service should compare them on control, version timing and operating effort, then plan the Dag refactoring either way.

How Bassirah can help

Bassirah plans and runs Airflow 2 to Airflow 3 upgrades for self-managed deployments as independent engineering, from inventory and Dag refactoring to rehearsal and cutover. See our Apache Airflow practice and our migration and modernization work. Bassirah is not a partner of Astronomer, Amazon Web Services or Google Cloud, and upstream fixes follow the community’s timeline, as our open-source support model explains.