Why teams still on Airflow 2 need a decision now
If your self-hosted Airflow 2.x estate is still running pipelines, the clock has already run out: Airflow 2 reached end of life on April 22, 2026, and it gets no fixes from that date onward. The supported path runs through the latest 2.x line to Airflow 3, so the decision you face is how and when to make that move, not whether the current version will keep receiving patches. Airflow 2 entered limited maintenance on October 22, 2025, when it began receiving only security and critical bug fixes. The last 2.x patch release listed in the version life cycle table is 2.11.2, and the current Airflow 3 patch release is 3.3.2. Airflow 3 was first released on April 22, 2025, so it has been available for a year and has had several minor releases since.
For a team running its own scheduler, metadata database and workers, end of life means that any vulnerability found in Airflow 2 after that date stays open in your environment until you change version. Your own patching does not close the gap, because the fixes will land only in the supported lines. Start by inventorying every Airflow 2 environment, including development and staging clusters, the Helm release or container image each one uses, and the Python and database versions beneath it. Then confirm with each provider package owner which Airflow versions their releases require, because most current provider packages still declare a minimum of 2.11.0, and newer releases may drop 2.x support first. Also check whether any managed service you use is still offering 2.11, since that choice is set by the vendor and not by you.
The planning question is whether to move quickly or on a planned schedule. A fast move suits small estates with few custom plugins, simple DAGs and no direct metadata database access in tasks. A planned move suits larger estates where the work is in the DAG code, the Kubernetes chart and the identity setup. In both cases the first steps are the same: move to the latest 2.x, scan DAG code with the Ruff AIR301 and AIR302 rules, and record the findings in a backlog. Ask your team or partner for a written scope that lists each environment, the breaking changes found, the owners who sign off, and a rollback plan, so the decision is recorded before the work starts.
What changes when Airflow 2 reaches end of life
This table compares how each Airflow 2 change behaves on a 2.x estate today and what it requires before an Airflow 3 move. Read the impact column to see what stops or breaks, and the action column for the work to schedule. The main takeaway is that end of life removes security fixes at once, while most of the code and architecture changes only bite when you upgrade.
| Change | Impact on a 2.x estate | Action needed |
|---|---|---|
| End of life on April 22, 2026 | No security or bug fixes for any 2.x release after this date, including 2.11.2 | Decide the target line now and document a compensating control plan for the gap before any upgrade |
| Limited maintenance from October 22, 2025 | Only security and critical bug fixes were issued, so the window for routine fixes has already closed | Check whether your current 2.x patch level has received recent fixes and confirm your patch cadence |
| Minimum 2.7 before upgrading to 3 | Estates on 2.6 or earlier cannot move to Airflow 3 directly | Upgrade to 2.11 first, which the upgrade guide recommends as the latest 2.x line |
| Provider packages moving on | Most provider packages, including Amazon, Snowflake, Databricks and Slack, list 2.11.0 as the minimum Airflow version | Confirm each provider's minimum version before pinning or upgrading providers independently |
| Webserver replaced by API server | The webserver process no longer exists in Airflow 3, so existing service units, probes and proxy rules break | Map webserver deployments to the api-server command and update health checks and ingress |
| DAG processor runs separately | In Airflow 3 it must run as its own component, so single-process 2.x deployments need a new service | Plan an extra deployment or container and size it for DAG parsing load |
| Direct metadata database access removed from tasks | Tasks that query or update Airflow tables stop working and need a different access path | Search DAG and plugin code for direct session or model use and move it to the REST API or Task SDK |
| SubDAG removal | SubDagOperator usage no longer runs in Airflow 3 | Rewrite SubDAGs as TaskGroups, keeping task IDs stable where history matters |
| Simple auth manager default | The default changes to Simple auth manager, so FAB-based login and role setups do not carry over automatically | Choose the auth manager explicitly and plan role mapping to your identity provider |
| Hybrid executors removed in 3.0.0 | CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported | Move to a supported executor or combination offered in your target version and retest workloads |
Which risks grow the longer 2.x stays in production
Airflow 2 reached end of life on April 22, 2026, so every month on 2.x adds exposure without adding fixes. The risks below compound: a gap in security patching makes provider upgrades harder, and a stale Python and dependency set makes the eventual move to Airflow 3 larger. Each one is worth checking against your own environment and your provider's roadmap now.
No security or critical fixes
Limited maintenance on 2.11.2 ended with the release of end of life on April 22, 2026. From that date the project publishes no fixes for 2.x, including security issues found in the scheduler, webserver or core dependencies. Your own patch window no longer has an upstream fix to pick up. Ask your team which 2.x vulnerabilities would need a local workaround, and who owns that decision when a new advisory appears.
Provider packages dropping 2.x
Provider packages such as Amazon, Snowflake, Databricks and Slack list 2.11.0 as their minimum Airflow version today. Each new provider release may raise that floor, and a provider pinned to an older line stops receiving operator changes and bug fixes. Check which providers your DAGs import, their minimum Airflow version, and whether a provider you need will still install on your current 2.x release.
Managed service timelines
Managed services can keep offering 2.11 after upstream end of life, but availability is set by the vendor, not by the Airflow project. Amazon MWAA lists 2.11.2 and 2.11.0 among supported versions and offers only minor-version in-place upgrades, with major moves handled through its migration guide. Ask your provider for its published end-of-support date for each version, how long it will run 2.x, and what migration tooling it offers when that date arrives.
Python and dependency drift
A 2.x environment that was built years ago often pins an older Python, database client and library set. Airflow 3.3.2 supports Python 3.10 to 3.14, PostgreSQL 14 to 18 and Kubernetes 1.30 to 1.35, so an old base image or database may already sit outside the range the next version needs. Inventory the Python, PostgreSQL or MySQL, Kubernetes and Helm versions you run now, and note which ones your target release will not accept.
Knowledge and hiring risk
Engineers who know the 2.x configuration, plugin set and custom operators are harder to replace as the line ages, and fewer public answers apply to unsupported releases. Fixing an incident on an end-of-life version can depend on one person's memory of local patches. Document which custom code, plugins and deployment scripts exist, who maintains each, and whether a second engineer can rebuild the environment from the repository without them.
Choosing a fast Airflow 3 move or a planned one
This path fits a small estate where DAG code is already clean against the Airflow 3 changes and the metadata database and deployment are simple. The team moves straight from Airflow 2 to Airflow 3.3.2 in one planned change window, after confirming the source version is at least 2.7 as the upgrade guide requires.
- Source version check: Confirm the running release is 2.7 or later, since the upgrade guide sets that as the minimum before moving to Airflow 3.
- Clean DAG scan: Run Ruff AIR301 and AIR302 across the DAG repository and confirm no SubDAGs, removed context keys or direct metadata database access remain.
- Component split: Plan the standalone DAG processor and the API server that replaces the webserver, since both are required in Airflow 3.
- Auth and executor review: Confirm that the Simple auth manager default, or a chosen replacement, fits your access model, and that hybrid executors are not in use, since they are not supported from Airflow 3.0.0.
- Tested backup and rollback: Take a consistent metadata database backup and rehearse the rollback before the change.
The main trade-off is that a fast move leaves little room for surprises, so any failed scan or unfamiliar plugin turns it into a longer project. Check these items with your own DAG inventory before choosing this path.
This path fits larger estates, many provider dependencies or DAG code that has not been reviewed for Airflow 3. The team first moves to the latest 2.x line, ideally 2.11, which is the last Airflow 2 release line, then uses it as a stepping stone while providers, DAG code and plugins are prepared.
- Stepping stone upgrade: Move to 2.11 first, which keeps the production environment on a line that still receives limited maintenance while the rest of the work proceeds.
- Provider alignment: Install the standard provider packages early. Most providers in the documentation list a minimum Airflow version of 2.11.0, so the provider versions need to be planned together.
- Ruff checks on 2.x: Run the AIR rules against the DAG repository in CI while still on Airflow 2, so breaking patterns are fixed in the code that is already running.
- Plugin and SubDAG work: Schedule the conversion of Flask AppBuilder plugins and SubDagOperator usage as separate work items with their own tests.
- Staging rehearsal: Rehearse the Airflow 3 move, including the Helm chart or deployment changes, in a staging environment before production.
The main trade-off is that this path needs more coordination and two production changes instead of one. Ask your implementation partner or internal team to confirm the work breakdown against your own provider list and DAG inventory.
This path is for teams that run a managed Airflow service and need time to scope the migration. Amazon MWAA lists Airflow v2.11.2 as supported, so a managed environment can stay on 2.11 temporarily while the migration is planned. This is a bridge, not a destination, because the Airflow 2 line reaches end of life on April 22, 2026, and after that date it receives no fixes.
- Confirm the service version: Check the supported version list of your managed provider and confirm whether 2.11 remains offered, since providers set their own timelines.
- Limit the bridge period: Set a documented date by which the migration must be complete, and track it as an operational risk.
- Upgrade method: Note that Amazon MWAA supports only minor-version in-place upgrades and points to its migration guide for major moves, so a move to Airflow 3 is a separate project.
- Scope the DAG estate: Use the bridge period to inventory DAGs, providers and plugins, and run Ruff checks in a non-production repository.
- Compensating controls: Document how you will handle any vulnerability disclosure against an unpatched 2.x line until the move is done.
The main trade-off is that staying on 2.11 buys time but accepts a version that will no longer receive fixes, so the bridge needs an end date. Confirm the provider's support commitments for 2.11 directly with the service before relying on this path.
The supported upgrade path from Airflow 2 to Airflow 3
This sequence moves a Airflow 2 installation to Airflow 3 in an order that keeps a working system and a restore point at every stage, so each change can be tested and reversed before the next one begins.
Inventory DAGs, providers and plugins
Your platform team lists every DAG repository, installed provider package and version, custom operator, plugin, webserver_config.py change, Helm value set and external script that calls the Airflow REST API. Record which executor, metadata database and secrets backend each environment uses. Done means each item has an owner, a current version and a note on whether it must change for Airflow 3. Keep this inventory as the baseline for every later check.
Move to the latest 2.x and install the standard provider
Upgrade the existing Airflow 2 installation to the latest 2.x patch release first, because the upgrade guide requires at least Airflow 2.7 and recommends the newest 2.x line. Install the standard provider on 2.x so that operators moving to Airflow 3 are already available. Run the DAG test suite and a staging scheduler cycle on this version. Done means production runs cleanly on 2.x, and the previous 2.x image and metadata database backup are retained as the rollback point.
Run Ruff AIR301 and AIR302 checks across DAG code
Your DAG authors or an engineer run Ruff with the AIR301 and AIR302 rules against every DAG repository and plugin, and triage each finding as a removed import, a removed context key or a changed API. Apply only the fixes that the tool marks as safe, and review unsafe ones by hand. Wire the check into CI so new code cannot reintroduce the same issues. Done means the rule set reports no open findings on the branch intended for Airflow 3.
Fix SubDAGs, removed context and direct metadata access
Replace SubDagOperator usage with TaskGroups, keeping task IDs stable where run history matters. Rename removed context variables such as execution_date and prev_ds to their logical_date and data interval equivalents, including templated fields. Move any task code that opens Airflow database sessions or imports models to the REST API or Task SDK. Done means the rewritten DAGs pass unit tests and a staging run on 2.x that compares task outputs and run history with the baseline.
Back up the metadata database and confirm restore
Take a consistent backup of the Airflow metadata database while schedulers and workers are paused or drained, using the procedure your database team already uses for PostgreSQL or MySQL. Trim old history only with the documented cleanup command and after a backup exists. Restore the backup into a separate test database and start a 2.x instance against it. Done means a restore test succeeds, and the team has written down who may approve a rollback and how long the window is.
Split scheduler, DAG processor and API server
Deploy the Airflow 3 components as separate processes: the scheduler, the DAG processor, which must run separately in Airflow 3, and the API server, which replaces the webserver. Configure the auth manager and the executor for each component, and in Kubernetes update Helm values from webserver to apiServer settings. Run this in a staging environment with a copy of the production database. Done means all components start, DAGs parse, and a sample run completes on the staging stack.
Migrate the metadata database to Airflow 3
Run the database migration command for Airflow 3 against the staging copy first, then record its duration and any errors. Reserialize DAGs as the upgrade guide directs, and check that the scheduler and API server work against the migrated schema. Confirm that the database engine and driver versions fall within the Airflow 3 prerequisites. Done means the staging migration completes, the dry-run results match, and the production migration plan is signed off with the restore point identified.
Cut over and keep a rollback point
During an agreed window, stop the Airflow 2 schedulers, take a final backup, run the production migration, start the Airflow 3 components and watch the first scheduled runs and API calls. Keep the Airflow 2 images, Helm release and final backup available until your team accepts the new platform. If a critical failure appears, restore the backup and redeploy the 2.x images. Done means production DAG runs succeed across at least one full scheduling cycle and the rollback artifacts are archived.
What to prepare before touching the 2.x estate
Before any upgrade decision, the 2.x estate needs a recoverable metadata database, a complete inventory, a staging copy that mirrors production and named owners. These four preparation areas connect because each one answers a question the upgrade plan depends on: what can be restored, what must change, what can be tested and who approves the work.
Consistent metadata database backup
Take a backup of the metadata database that you have restored at least once in a test environment. Use PostgreSQL or MySQL, because the production guide warns that the default SQLite backend is for testing only and can lead to data loss. Confirm that the backup captures the database at one point in time, and record who can restore it and how long a restore took. Airflow 2 receives no fixes after April 22, 2026, so this backup is also your rollback point if a later migration fails.
Inventory of DAGs and extensions
List every DAG repository, custom plugin, operator, provider package and executor in use, with its version and owner. Note which providers pin an Airflow minimum, since most documented provider packages list 2.11.0 as the minimum. Identify any custom code that imports the webserver, uses Flask AppBuilder views or reads the metadata database directly, because these items change in Airflow 3 and need a separate conversion plan. Note the executor in use, since the hybrid CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported as of Airflow 3.0.0.
Staging copy with matching engine
Build a staging environment with the same metadata database engine and major version as production, along with the same Python version and container image approach. Test the upgrade path there first, because a SQLite or differently configured staging system can hide migration failures. Confirm that the target Python version falls within the range supported by your planned Airflow release, which for Airflow 3.3.2 is Python 3.10 to 3.14. Staging also gives you a place to rehearse restores and observe scheduler behavior with real DAG volume.
Platform and database version check
Confirm the database and cluster versions you will run after the move before you commit to a target. Airflow 3.3.2 lists PostgreSQL 14 to 18, MySQL 8.0, 8.4 and Innovation releases, and Kubernetes 1.30 to 1.35. MariaDB is not supported as a metadata database, so a MariaDB estate needs a migration to a supported engine before or alongside the Airflow move. Ask your platform team which of these versions your current infrastructure can reach without an unplanned upgrade of its own.
Ownership and access records
Record who owns each DAG team, who can deploy to the scheduler and who holds administrator rights on the web interface and database. Map each owner to a named approver for the upgrade window. Access records also show who must test each pipeline after cutover, which reduces the time spent finding a responsible person during an incident. Keep the record in your change system so auditors and your own security team can trace who approved each step.
What makes an Airflow 2 to 3 move take longer
This table lists the factors that most often stretch an Airflow 2 to 3 move, how each one changes the work, and what to request in a written scope. Read each row as a question to answer about your own environment before comparing partner quotes. The main takeaway is that effort depends less on the Airflow version number than on how much of your code, plugins and infrastructure depends on Airflow 2 internals.
| Driver | Why it changes effort | What to ask for in a written scope |
|---|---|---|
| Number of DAGs and SubDAG usage | Every DAG must pass the Ruff AIR checks and be tested. SubDAGs have no direct Airflow 3 equivalent and must be rewritten as TaskGroups, which increases work per DAG. | A DAG inventory with a count of SubDAG operators, a rewrite plan, and a test approach for each rewritten group. |
| Custom Flask AppBuilder plugins | Airflow 3 moves UI plugins to FastAPI apps, so each menu item, view or blueprint needs porting and retesting. Custom webserver_config.py security manager code adds more. | A list of every plugin and webserver_config.py change, with the target design for each and the owner who signs off on UI behavior. |
| Direct metadata database access in tasks | Task code can no longer use Airflow database sessions or models. Each query or update must move to the REST API or Task SDK, which can change how the logic works. | A search of task code for database session use, a replacement design per case, and a statement on any temporary workaround and its removal date. |
| Hybrid executors removed in 3.0.0 | CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported. Clusters using them need a different executor layout and worker deployment plan. | The executor configuration in use today, the target executor set, and a worker rollout and rollback plan. |
| Helm chart and GitOps setup | The webserver becomes an API server, the DAG processor runs separately, and migration jobs must run in the right order under tools such as Argo CD or Flux. Chart values and pipelines both change. | Current chart version and values files, the target chart values, the GitOps sync order, and a staging release test before production. |
| Provider count and version pinning | Most providers listed here require Airflow 2.11.0 or later, so each provider pin, constraint file and operator change needs review against the target Airflow release. | A pinned provider list with current and target versions, the constraint file source, and a test run of each critical operator. |
| Metadata database size and history | A large database slows migration and backup, and history trimming decisions must be made before the upgrade window. Recovery plans depend on the database state. | Database size and retention settings, a backup and restore test, a cleanup plan, and the expected downtime window agreed in writing. |
| Number of teams and auth integrations | Each team, role and identity integration may need separate mapping under the auth manager model, where only one auth manager is active at a time. Permissions tested per team add effort. | A list of teams, roles, identity provider connections and the auth manager choice, with role mapping tests and sign-off by each team lead. |
Common questions about Airflow 2 end of life and upgrade effort
Can we keep running Airflow 2.11 after April 22, 2026?
You can keep it running, but the project will not fix it. Airflow 2 reached end of life on April 22, 2026, and end-of-life versions get no fixes or support under the Airflow support policy. Airflow 2.11.2 is the last patch line, so any vulnerability or critical bug found after that date stays open unless you patch it yourself or change the platform. Before deciding, confirm your exposure: the internet-facing components, the authentication setup, the Python and database versions underneath, and whether your provider packages still receive updates. Treat the decision as a risk acceptance that someone signs, with a dated plan to move.
What does the Airflow 3 upgrade cost and how is it quoted?
No price is fixed for this work, and DeployOpen quotes from a written scope. The main cost drivers are the number of DAGs and the share that uses features Airflow 3 removed, such as direct metadata database access in tasks, SubDAGs, and Flask AppBuilder plugins. Other drivers are the executor and deployment model (Kubernetes with the Helm chart, virtual machines, or a managed service), the size of your provider package footprint, and how many environments must be upgraded. Ask any partner to itemize the assessment, code changes, database migration and backup, testing, cutover, and handover, and to state which items are one-time and which recur, such as an upgrade retainer.
How long does an Airflow 3 upgrade take?
Duration depends on the inventory and the gaps, not on the version number alone. A team with a small, well-tested DAG repository on a recent 2.x line has a much shorter path than a team with many legacy operators, custom plugins and direct database access. The upgrade guide asks you to be on Airflow 2.7 or later before upgrading and recommends moving to the latest 2.x first, so an earlier starting point adds steps. Ask a partner for a timeline only after the inventory is complete, and confirm the staging and cutover windows you can accept, including the downtime needed for database migration.
Can our own team do the Airflow 3 upgrade?
Yes, many teams do, provided they have engineers who know the DAG code, the deployment and the database. The work is mostly repetitive once it is scoped: run the Ruff AIR301 and AIR302 checks, fix the flagged code, move the scheduler, DAG processor and API server into their own components, and test in staging. The hard parts are usually the custom plugins, the code that reads the metadata database, and the Helm or GitOps configuration. Assess honestly whether those skills exist on your team and how many people can be pulled away from delivery work for the window. A partner is useful when those skills are missing or the calendar is tight.
What do we need to provide before an upgrade starts?
The assessment depends on access and records, so have these ready before scoping:
Is a managed Airflow service a safe place to wait?
A managed service can reduce the operational load, but it does not remove the end-of-life question. Amazon MWAA lists Airflow 2.11.2 and 2.11.0 among supported versions and points to its own migration guide for major moves, so check the provider's support and end-of-life dates for the version you run, not only the open-source dates. Also confirm which provider packages and plugins the service supports, what the vendor patches and when, and whether you can keep your own configuration. Waiting on a managed service is a decision that should carry its own written exit date.
Do we need to move to Airflow 3.3.2 directly?
No, you do not have to jump straight to the newest patch. The current patch release is 3.3.2, and the Airflow 3.3.2 prerequisites list Python 3.10 to 3.14, PostgreSQL 14 to 18, MySQL 8.0, 8.4 and Innovation releases, and Kubernetes 1.30 to 1.35. Choose a target that matches your Python, database and Kubernetes versions, then decide whether to go to the first 3.x release or a later minor version. Later 3.x minor releases have added changes of their own, so each jump needs its own review of the upgrade notes. Confirm your target with the version life cycle page before you plan.
How DeployOpen scopes an Airflow 2 exit
An engagement to leave Airflow 2 starts with an inventory and a code review, not with an install. We list every DAG repository, provider package, plugin, custom operator, Helm or container configuration and external connection, then run Ruff with the AIR301 and AIR302 rules across the DAG code to find breaking changes. The upgrade guide also asks that you already be on Airflow 2.7 or later and ideally the latest 2.x line before you move, so the inventory records your current 2.x version and the provider versions it depends on. Anything that touches the metadata database directly, uses SubDAGs or relies on the webserver UI plugins is flagged early, because those changes take the most rework.
The written scope then names the target Airflow version, the components that will change and the criteria for accepting the move. Components usually include the scheduler, DAG processor, API server, workers and executor configuration, the metadata database migration, the Helm chart or container images, and the authentication setup. The scope also defines the test criteria (which DAGs must run, which outputs must match, and which external connections must succeed) and the rollback criteria, including the database backup taken before the change. Ask any partner to state in writing which of these items are included, which depend on your own teams, and which are excluded.
Work then moves through a staging environment that mirrors production before cutover. DeployOpen deploys and runs self-hosted Airflow inside your own cloud accounts, data centers or air-gapped networks, so the staging and production environments stay under your control. Cutover follows the agreed test and rollback criteria. Ongoing support, upgrades and continuous testing after cutover can be covered by a retainer, which you should price separately from the fixed-scope migration.
How DeployOpen works on this
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For teams still running Airflow 2 after end of life, we scope the move to Airflow 3 or a planned stop on 2.11 against your own DAGs, integrations and infrastructure, then build, test, document and hand it over in writing.
How we scope
- Inventory your Airflow 2 installation, DAG repository, providers, executors and metadata database before quoting.
- Agree a fixed-scope written plan that states the target version, what changes and what is excluded.
- Confirm the window, rollback approach and who approves cutover before any build work begins.
How we build
- Run Ruff AIR301 and AIR302 checks across the DAG repository and fix findings in agreed scope.
- Stage the upgrade in a non-production environment with a copy of the metadata database and provider versions.
- Rebuild the deployment with the chosen executor, a separate DAG processor and the official Helm chart or your packaging.
How we hand over
- Document the upgrade steps, configuration changes, known breaking-change fixes and the rollback procedure.
- Deliver test results for DAG runs, provider operators and the API server against the agreed acceptance criteria.
- Walk your platform, data and security teams through the runbook and the record of decisions made.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover later Airflow 3 patch and minor releases, provider upgrades and security test cycles.
- Ask any partner to confirm response expectations, change control and evidence formats in the written scope.
