.webp?width=1921&height=622&name=usecase-banner%20(1).webp)
Key takeaway
- Apache Airflow 2 reached end of life on 22 April 2026. What breaks in Airflow 3, how to size the work and a six-step upgrade plan under change control.
Is Apache Airflow 2 still supported? No. Open-source Airflow 2 reached end of life on 22 April 2026, and 2.11.2 is its last patch. The project states that end-of-life versions receive no fixes or support. If Airflow 2 schedules your regulatory reports, reconciliation jobs or risk pipelines, the orchestrator at the centre of your data platform is now unsupported software.
The 60-second brief
- The fact: Airflow 2 entered limited maintenance in October 2025 and reached end of life in April 2026.
- The catch: Airflow 3 is an architecture change. Task code can no longer reach the metadata database directly.
- The sizing rule: the amount of custom operator code that touches the metadata database decides whether this is weeks or months.
- The approach: audit, clear deprecations, rewrite, prepare, run in parallel, cut over.
- The governance point: the orchestrator decides when trusted data arrives. Its upgrade belongs under the same change control as any production-critical system.
Part of a series. Start with the overview: Open-Source Data Platforms on Private Cloud: Why Managed Services and Governance Must Evolve Together.
Why the Orchestrator Is a Special Case
Airflow rarely holds business data itself. It holds something just as important: the schedule, the dependencies and the credentials for almost everything else. A failure in Spark affects one job. A failure in Airflow can stop every job that depends on it.
That makes an unsupported orchestrator a concentration risk. It connects to storage, processing engines, databases and file-transfer paths, usually with privileged service accounts.
When the scheduler is out of support, every pipeline it runs inherits the exposure.
What Changes in Airflow 3
| Area | What changed | Why it matters |
|---|---|---|
| Metadata database access | Task code goes through a Task Execution API instead of the database | Custom operators and helpers that read or write run state can break. This is usually the largest piece of work |
| User interface plugins | The interface was rebuilt on a new stack | Plugins built on the old plugin API need rewriting |
| Datasets | Evolved into Data Assets | Data-aware scheduling definitions need review |
| Backfills | Run inside the scheduler | Operational procedures and runbooks change |
| Provider packages | Released on their own version clock | Pin providers separately from core; mismatches can surface as parse errors |
Published estimates give a sense of scale. One independent guide puts a deployment using stock operators at roughly 40 to 80 hours including a parallel run, and a deployment with custom base classes that access the database at 200 hours or more. Treat these as planning figures, not quotes. Your own audit decides.
A Six-Step Upgrade Plan
- Audit first. Count the custom operators, hooks, sensors and plugins. Flag every one that touches the metadata database or the old plugin API. This single count sizes the programme.
- Move to the last 2.x release and clear deprecation warnings. The warnings in your scheduler logs are the work list. Clearing them on the platform you already run reduces cut-over risk.
- Rewrite what the audit found. Move custom code to the supported interfaces. Stock-operator pipelines can often skip this step.
- Prepare providers and DAG packaging. Pin provider versions. Decide how DAG code will be versioned and deployed.
- Run in parallel. Run Airflow 3 against real schedules in nonproduction for long enough to cover weekly and month-end jobs. Most failures appear on schedule, not in manual test runs.
- Cut over in waves, then stay current. Move DAG groups by business criticality inside approved windows, with a tested rollback. After cut-over, take patch releases promptly.
Change Control for a Regulated Environment
On a private cloud in a regulated enterprise, the technical plan is half of the work. The other half is evidence.
| Control | What to produce |
|---|---|
| Risk record | The end-of-life exposure logged with an owner, compensating controls and a target date |
| Impact map | Each DAG mapped to the business process and reporting cut-off it serves |
| Test evidence | Parallel-run comparisons, access tests and performance results |
| Change approvals | Approved windows, rollback plans and sign-off per wave |
| Credential review | Connections and service accounts re-validated against least privilege during the move |
The upgrade is also a natural moment to fix what the old platform tolerated: shared service accounts, credentials stored in variables and missing audit logs.
Upgrade, or Move to Something Else?
End of life prompts a fair question: is Airflow 3 the right orchestrator for the next five years? Vendors of competing tools are making that case loudly. For most private cloud estates with hundreds of working DAGs, staying on Airflow and upgrading is the lower-risk path, because pipeline logic, operator skills and runbooks carry over. A change of orchestrator is a redesign, and deserves its own business case rather than a deadline-driven decision.
Related Lifecycle Risks
Airflow is one of several components with dated support windows. See Apache NiFi 1 End of Support for the ingestion layer and the Open-Source Data Platform Lifecycle Risk Register for a way to track the whole stack.
The Bottom Line
Teams still on Airflow 2 are past the deadline. The remaining decision is sequencing. Audit this month, remediate on 2.x, prove it in parallel and cut over in waves. A controlled upgrade with evidence is far easier to explain than an unsupported scheduler.
Plan Your Airflow 3 Upgrade with XenonStack
XenonStack provides co-managed L2/L3 support for open-source data platforms on private cloud. An upgrade assessment delivers the operator audit, the effort estimate and a wave plan aligned with your change windows. Explore Data Managed Services and the Open-Source Data Platform solution.
Frequently Asked Questions
When did Airflow 2 reach end of life?
Open-source Apache Airflow 2 reached end of life on 22 April 2026, six months after it entered limited maintenance on 22 October 2025.
What is the last Airflow 2 release?
Airflow 2.11.2 is the final patch in the 2.x line.
What is the biggest breaking change in Airflow 3?
Task code can no longer access the metadata database directly. Custom operators and helpers that did so must move to the supported API.
How long does an Airflow 2 to 3 upgrade take?
It depends mainly on custom code. Simple estates may need a few weeks including a parallel run. Estates with heavy custom operators should plan for months and start with an audit.
Can we keep running Airflow 2 for now?
It keeps working, but it receives no security patches. Record it as a risk, add compensating controls such as network restriction and tighter access, and set a dated upgrade plan.
Dates and version details reflect public Apache Airflow project information at the time of writing. Confirm current status on the Apache Airflow site before planning.
Explore the XenonStack Platform and Agent Network
Platforms: ElixirData · ElixirClaw · ElixirHub · NexaStack · MetaSecure · Neural AI · AutonomousOps · CohortIQ · AI Aviator · SAIF Aviator
AI agents: AgentAnalyst · AgentEvaluation · AgentForce · AgentGRC · AgentHR · AgentInstruct · AgentLabel · AgentPixel · AgentQA · AgentRAI · AgentScrum · AgentSearch · AgentSketch · AgentSRE
XenonStack: xenonstack.com · xenonstack.ai · xenonstack.ae · xenonstack.jobs
Not sure which decision to hand to governed agents first? Book a Context Workshop to map one AI decision in half a day and leave with a go/no-go.
Explore the XenonStack platform family: ElixirData · ElixirClaw · ElixirHub · NexaStack · MetaSecure · Neural AI · AgentGRC · AgentSRE · AgentAnalyst · AgentInstruct · AgentRAI · AgentScrum · AgentSearch · AgentForce · AI Aviator · SAIF Aviator · CohortIQ · XenonStack AI · XenonStack UAE
