What upgrades and support cover for Airflow
Apache Airflow is Apache-2.0 software, and the project offers no paid edition. Every upgrade, security patch and hour of troubleshooting is therefore a cost you carry directly, whether it is paid as staff time or as a partner invoice. Unlike the initial build, this work recurs for as long as the platform runs, so the budget question is about the whole life of the deployment, not only go-live.
Several triggers force that work. Airflow 2 entered limited maintenance on October 22, 2025 and reached end of life on April 22, 2026, so it receives no fixes at all. Limited-maintenance releases receive only security and critical bug fixes, which leaves little room to wait on a feature. Provider packages, Python, PostgreSQL and Kubernetes also move on their own schedules. Airflow 3.3.2 lists Python 3.10 to 3.14, PostgreSQL 14 to 18 and Kubernetes 1.30 to 1.35. Check the current prerequisites and the version support table before each change, because a provider release or a database version can break a working deployment even when Airflow itself is unchanged.
Keeping this in-house works when the platform is stable, one named owner has time for each release, and that person tracks provider and dependency changes as they arrive. A partner is usually the better fit when the estate is running old versions with a backlog of upgrades, when the team has no spare capacity, or when the organization wants a fixed-scope upgrade followed by a standing support arrangement. Ask any partner to state in writing which Airflow versions, providers and dependencies the support covers, how security fixes are handled, and what happens to custom code during each upgrade.
What the work includes
Each component produces a named deliverable that your team keeps after the engagement. Most of the effort sits in the database migration, the DAG review and the staging rehearsal, so scope those in the quote.
Life cycle review and roadmap
Map your running Airflow version against the support table, which lists Airflow 2 as end of life from April 22, 2026, and choose the release line you will target. The Airflow 3 path requires Airflow 2.7 or later first. The deliverable is an upgrade plan with dated milestones and the Python, PostgreSQL and Kubernetes versions your target release requires.
Minor, patch and provider updates
Apply Airflow minor and patch releases and update provider packages against a pinned, tested set of versions so each change can be reproduced. Check provider release notes for removed operators before each change, because provider updates can break existing DAGs. Deliverables are a change record, updated images or Helm values, and a provider version matrix.
Metadata database migration with rollback
Run schema migrations only after a verified backup of the metadata database, using PostgreSQL 14 to 18 or MySQL 8.0 or 8.4 as the target release supports. MariaDB and SQLite are not supported as production metadata databases. The deliverable is a tested runbook with restore steps, rollback criteria and step timings measured during rehearsal.
DAG code checks with Ruff
Scan every DAG and plugin with the Ruff AIR301 and AIR302 rules from the Airflow 3 upgrade guide, which flag code likely to fail or change behavior in Airflow 3. Review each finding by hand, since removed imports and SubDAG usage often need a design decision. The deliverable is a check report with an owner and fix status for each DAG.
Staging rehearsal and cutover
Rehearse the full upgrade in a staging environment built from a recent copy of production, then repeat the same steps in the production window. Record each step's result and duration, and keep the rollback path open until scheduled DAGs have run successfully on the new release. Deliverables are the tested runbook and a cutover note naming the approver for each step.
Support agreement for ongoing fixes
A support agreement covers triage, security and critical fixes, and planned upgrades after go-live. Limited-maintenance releases receive security and critical bug fixes only, and end-of-life releases receive none, so the agreement should name the release line it covers. Deliverables are a handover note and a service schedule. Confirm response times in writing before signing.
What drives cost and duration
This table lists the factors that most change the effort and calendar time of an Airflow upgrade or support engagement, why each one matters and how to keep it under control.
| Driver | Why it matters | How to keep it under control |
|---|---|---|
| Starting version | Airflow 2.11.2 reached end of life on April 22, 2026, so installations on that line get no fixes. Airflow 3 requires being on 2.7 or later before upgrading, which adds a step for older installations. | Confirm the exact installed version first. Move to the latest 2.x patch release, then plan the Airflow 3 step as a separate change. |
| Number of DAGs and custom code | Each DAG, custom operator, hook, sensor or plugin needs review for removed features, such as direct database access and SubDAGs, before it runs on Airflow 3. | Run Ruff AIR301 and AIR302 checks across the codebase to size the work. Group DAGs by owner and by how much custom code they use. |
| Provider packages | Provider updates change operator signatures and imports. Pinned provider versions that differ across environments multiply the test effort. | Pin provider versions in one lock file. Record which provider releases each DAG depends on and upgrade them in the same change set. |
| Metadata database size and engine | The upgrade runs schema migrations against the metadata database. Large histories and unsupported engines lengthen the window and raise the risk of failed migrations. MariaDB is not supported, and SQLite should not be used in production. | Confirm PostgreSQL 14 to 18 or MySQL 8.0, 8.4 or an Innovation release. Prune old run history under a retention policy and take a tested backup before the migration. |
| Executor and Kubernetes footprint | The number of workers, schedulers and API servers and the Kubernetes versions in use determine how many components must be rolled and retested. Hybrid CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported in Airflow 3. | Document the executor in use and its cluster footprint. Check the Kubernetes version against the supported range (1.30 to 1.35 for Airflow 3.3.2) before scheduling the upgrade. |
| Environments upgraded in step | Each environment (development, test, staging, production) needs its own upgrade, validation and rollback. Differences between environments add rework. | Keep environments built from the same images and configuration. Upgrade in order from non-production to production and agree a single change calendar. |
| Custom auth manager or secrets backend | Airflow 3 allows only one auth manager at a time, set by the auth_manager option, and custom integrations must be re-validated against the new API server. | Inventory every custom auth manager, secrets backend and connection type. Test login, role mapping and secret retrieval in staging before cutover. |
| Compliance evidence requirements | Assessors often ask for change records, test results, approvals and proof of patching for each upgrade. Collecting this evidence after the fact takes time. | Agree the evidence list before work starts, such as change tickets, test logs, backup verification and version inventories. Store it as each step completes. |
| Release cadence | Frequent minor and patch releases mean more upgrade cycles over the life of the platform. Skipped releases make later upgrades larger. | Agree a patch and minor upgrade cadence in the support agreement. Track the Airflow version support table so limited maintenance and end-of-life dates are planned ahead. |
How an upgrade or support engagement runs
The sequence moves a live Airflow installation to a supported release through checks, a rehearsal and a verified cutover, then hands it to ongoing support.
Assess the installed baseline and versions
We record the Airflow, provider, Python, database and Kubernetes versions currently in use, then check each against the Airflow 3.3.2 prerequisites: Python 3.10 to 3.14, PostgreSQL 14 to 18, MySQL 8.0 or 8.4, and Kubernetes 1.30 to 1.35. The output is a written version assessment that lists every gap and the component that must change first.
Inventory DAGs, providers and lint results
We catalogue every DAG, custom operator, hook and installed provider package, and run Ruff with the AIR301 and AIR302 rules over the DAG code. The output is an inventory with lint findings grouped by severity, so you can see which DAGs need code changes and which providers need a version update.
Write the upgrade plan and rollback design
We sequence the change, including any move through the latest 2.x release where the starting version requires it, and define the rollback path for the metadata database, images and Helm values. The output is a written plan with entry and exit checks for each step, agreed with your team before any environment is touched.
Rehearse the upgrade in staging
We restore a copy of the production metadata database into staging and run the full upgrade against it, including database migrations, DAG parsing and a sample of task runs. The output is a rehearsal log with migration timings, errors and fixes, and a go or no-go recommendation for the production window.
Execute the production change window and cutover
We carry out the approved plan in the agreed change window, take a verified backup before migrations begin, and follow the rollback design if a gate fails. The output is a change record showing each step, its time and its result, with the environment confirmed as serving DAG runs again.
Verify the upgraded environment
We confirm scheduler and API server health, DAG import errors, provider versions, connections, secrets access, scheduled runs and alert routing against the baseline recorded at the start. The output is a verification report that lists any open items with owners, so nothing is left to assumption.
Hand over to the support agreement
We transfer runbooks, the version record, patch notes and the open-items list to your team and, where a support agreement is in place, to the support schedule for security fixes and future upgrades. Its scope, response arrangements and recurring fees are set out in the written scope. The handover is complete when your named owners accept the runbooks.
What teams keep in-house and what they outsource
Each row names one part of an Airflow upgrade, who usually owns it, and the skills it needs, so you can see where your team's capacity fits and where a partner would take on work.
| Work item | Usually owned by | Skills the work needs |
|---|---|---|
| DAG ownership and business logic | In-house: pipeline owners keep DAG logic, schedules and data contracts | Python, knowledge of the source and target data, Airflow 3 Task SDK patterns |
| Release approvals | In-house: change owners approve each upgrade window and rollback decision | Change management, service ownership, understanding of downstream data consumers |
| Incident response for their pipelines | In-house: pipeline owners triage failed DAGs and missing data | Airflow UI and task logs, task-level debugging, data quality checks |
| Reviewing upgrade notes | In-house: platform owners decide which breaking changes affect their DAGs and operators | Reading the Airflow 3 upgrade guide, Python, knowledge of custom operators and hooks |
| Version assessment and provider updates | Outsourced: assess the current release against the support table, plan the target and pin provider packages | Python packaging, dependency resolution, Airflow support life cycle knowledge |
| DAG code review with Ruff | Outsourced: run the Ruff AIR301 and AIR302 checks across the DAG repository and fix or log findings | Ruff configuration, Python, Airflow 3 import paths and removed APIs |
| Metadata migration rehearsals | Outsourced: restore a copy of the metadata database, run the migration, and verify the result | PostgreSQL administration, backup and restore, Airflow CLI |
| Cutover support | Outsourced: run the rollout of the API server and DAG processor, scheduler changes and the rollback path | Kubernetes operations, Helm values management, release engineering |
| Patch cadence and on-call backup | Outsourced: apply patch releases on an agreed cadence and cover platform alerts outside working hours | Image rebuilds, Kubernetes operations, PostgreSQL monitoring, incident response |
What usually goes wrong and how to prevent it
Most Airflow upgrade problems come from decisions made long before the upgrade window. Each card names a failure pattern, the step that prevents it, and the record that shows the step was done.
SQLite or an unsupported metadata database
The production deployment guide warns that the default SQLite backend is for testing only and can lose data in production. MariaDB is not supported as a metadata database. Prevent this by choosing PostgreSQL or MySQL from the Airflow 3.3.2 prerequisites before go-live. Proof: a signed database decision record and a deployed configuration that shows the chosen backend.
Skipping the 2.7 and latest 2.x steps
Airflow 3 requires Airflow 2.7 or later, and the upgrade guide recommends moving to the latest 2.x release first. Teams that jump from an older 2.x release often find migration failures only in production. Prevent this by staging each hop in a non-production environment. Proof: a dated upgrade runbook listing every intermediate version and its migration output.
DAG code that bypasses the Task SDK
In Airflow 3, task code can no longer use database sessions or models directly and must use the REST API or Task SDK. SubDAGs are removed in favor of TaskGroups. Run Ruff with the AIR301 and AIR302 rules across every DAG repository and rewrite flagged code. Proof: a clean Ruff report in CI and a list of rewritten DAGs with passing test results.
Provider packages pinned to incompatible versions
Provider packages are installed separately from the Airflow core, so a core upgrade can leave an existing provider pin incompatible. Prevent this by generating a constraints set for the target Airflow version and pinning every provider in the image or requirements. Run the DAG test suite against that exact set. Proof: a committed constraints file and a recorded passing test run against it.
An Airflow 2 line kept past end of life
Airflow 2 entered limited maintenance on October 22, 2025, and reached end of life on April 22, 2026, after which it gets no fixes. Limited maintenance covers only security and critical bug fixes. Prevent this by setting a dated retirement plan for every Airflow 2 environment and confirming the upgrade window before that date. Proof: an approved upgrade schedule and a current version inventory for all environments.
Untested metadata database restores
The metadata database holds DAG run history, connections and variables, so a failed migration without a rollback point is hard to recover from. Take a backup before each upgrade migration and restore it into a separate environment to confirm it works. Proof: a restore test log that records the Airflow version used for the migration and the result of the restore.
How the work changes by starting point
Airflow 2 has two starting points with different first steps. According to the Airflow version support table, Airflow 2 entered limited maintenance on October 22, 2025 and reached end of life on April 22, 2026, so a 2.x installation that is already past end of life gets no fixes and should move first. A current 2.x installation still needs preparation, because the Airflow 3 upgrade guide requires Airflow 2.7 or later and recommends moving to the latest 2.x release first.
- Scope: an initial move to the latest 2.x patch, followed by a separately planned Airflow 3 upgrade with a decision point between the two.
- Checks that grow: DAG code scanned with the Ruff AIR301 and AIR302 rules, provider package compatibility, and database migration rehearsals on a copy of production data.
- Client supplies: the current version, the provider package list, the DAG inventory and the metadata database type and version.
- Confirm: whether task code uses SubDAGs or direct database sessions, since both must change for Airflow 3.
Kubernetes deployments usually run the official community Helm chart with the official Docker image. The Airflow 3.3.2 prerequisites list Kubernetes 1.30 to 1.35, so the cluster version is the first check, and the production deployment guide recommends container images for Kubernetes.
- Scope: chart version pinning, values files for the API server, DAG processor, schedulers and workers, an external PostgreSQL or MySQL database, and the image build pipeline.
- Checks that grow: chart and image upgrades tested against the cluster version, scheduler failover tests when more than one scheduler runs, and DAG delivery through git-sync or baked images.
- Client supplies: the cluster version and distribution, container registry access, a deployment pipeline or GitOps tooling, and access to the secrets store.
- Confirm: which executor the chart is configured to use, because the hybrid executors are no longer supported as of Airflow 3.0.0.
Virtual machine installations run Airflow as systemd services, so an upgrade touches the operating system, the Python environment and the service units together. The Airflow 3.3.2 prerequisites list Python 3.10 to 3.14, and the Python version must be confirmed against the host operating system before any package change.
- Scope: the Python runtime and virtual environment layout, service units for each Airflow component, log paths, and a rollback plan that restores the previous package set.
- Checks that grow: constraint files that pin provider and dependency versions, service start order and restart behavior after an upgrade, and database migrations run once from a controlled host.
- Client supplies: a host inventory with operating system versions, existing unit files, the configuration management tooling and the change window process.
- Confirm: how the API server, DAG processor and schedulers are placed on hosts, since Airflow 3 runs the DAG processor as a separate component.
In an air-gapped network, every dependency arrives through an approved transfer process, and nothing is fetched from the internet during installation or upgrade. The same version checks apply, but each package, provider and image must also be present in the mirror before the change window opens.
- Scope: mirrors for Python and provider packages, container images and the Helm chart if Kubernetes is used, operating system packages, and a documented transfer and verification procedure.
- Checks that grow: dependency resolution run only against the internal mirror, image digest verification after each transfer, and review of release notes and security advisories on the transfer cycle.
- Client supplies: a mirror host or artifact repository inside the network, the transfer approval workflow and the security sign-off process.
- Confirm: that every provider package and base image you need is in the mirror before the upgrade window is scheduled.
An installation built by a previous partner with no current runbook needs discovery before any upgrade is planned. The first task is to establish what is running, where it is configured and how it recovers, because the upgrade plan depends on those facts.
- Scope: an inventory of versions, executors, metadata database, DAG delivery method, connections and secret locations, plus a written runbook of the current state before any change.
- Checks that grow: comparison of the running configuration with the handover documents, review of custom operators and plugins, and a restore test of the metadata database backup.
- Client supplies: administrative access to the hosts or clusters, any existing documentation or change history, backup records and the credential inventory.
- Confirm: whether the previous partner left custom code or provider packages that are not kept in your source control.
What you need to provide
Before DeployOpen starts any upgrade or support work, we need a written inventory of what runs today: the Airflow version, every installed provider package version, and the Python version used by schedulers, workers, the API server and the DAG processor. Airflow 3 supports Python 3.10 to 3.14, and the upgrade guide requires Airflow 2.7 or later before moving to 3, so this inventory determines the first step. Ask your platform team for a pip freeze or the image manifest from the running containers, not from the build notes, because those often differ.
We also need a current export of the DAG repository at the commit that production runs, along with the deployment values: the Helm values file or equivalent environment variables, airflow.cfg overrides, and the names of connections and variables. Secret values stay in your secrets backend. Read access to the metadata database and a recent backup are required, and the backup should be confirmed as restorable before any change. Ruff AIR301 and AIR302 checks run against the DAG export, so clean code is easier to scope.
Staging capacity must be close enough to production to rehearse the upgrade, including the same metadata database engine and a major version within the supported range, such as PostgreSQL 14 to 18 or MySQL 8.0 or 8.4. Each critical DAG needs a named business owner who can confirm expected outputs, data freshness and downstream dependencies. Data consumers must agree on a maintenance window in writing, since database migrations and scheduler restarts interrupt pipelines.
Several decisions must be made before the agreement is signed: the support hours, the escalation path from on-call engineers to your own managers, and who approves each production change. Name the person who signs off the post-upgrade verification, usually the business owner or data platform lead, and agree the acceptance criteria in advance. Airflow 2 reached end of life on April 22, 2026, so these decisions should be made early enough to keep the upgrade on a supported release.
Frequently asked questions
What drives the cost of an Airflow upgrade and how do I ask for a quote?
The cost depends on how much work the upgrade touches, not on the Airflow release number alone. The main drivers are the number of DAGs that need code changes, the number of environments (development, staging, production), any custom operators, hooks, plugins or provider packages, the metadata database and deployment method, and the testing and cutover approach. Upgrades are usually fixed-scope, so ask for a written scope listing the Airflow versions in and out of scope, the environments covered, the number of DAGs reviewed, custom code included, and the verification and rollback steps. DeployOpen does not publish prices. A quote follows from that written scope.
How long does an Airflow upgrade take, and what sets the schedule?
The schedule follows the written scope, the number of environments and the number of DAGs. A single environment with a small, well-tested DAG set moves faster than several environments with heavy custom code and many DAGs that depend on removed features. Each environment needs its own staging run and validation, and the team needs time for Ruff AIR301 and AIR302 checks and provider package review. Ask for a schedule that lists phases, client sign-off points and the work each environment needs, rather than a single overall duration. Confirm the target date against your change calendar before work starts.
Can our own team upgrade Airflow without a partner?
Yes, a capable internal team can do it, provided the work is planned with clear ownership. Assign one named owner who makes decisions on scope and cutover, keep a staging copy of production with a recent metadata database backup, and allow time for the Ruff AIR checks, provider package compatibility review and fixes to DAGs. Teams new to Airflow 3 often underestimate the removal of direct database access from task code and the separate DAG processor. A partner is most useful when the team lacks time or has many DAGs with custom code.
What does the upgrade need from our team?
The work needs access and decisions more than labor. Expect to provide access to staging and production environments and the metadata database backup process, a copy of the DAG repository and custom code, a list of installed provider packages and plugins, the current Airflow version, and a named decision-maker for scope and cutover windows. Your team should also confirm which pipelines are business critical, who signs off on test results, and which maintenance windows are allowed. Missing answers on these points are the most common cause of delays.
What happens if we keep running Airflow 2 after its end of life date?
Airflow 2 reached end of life on April 22, 2026, and after that date the project provides no fixes, including security fixes. Your deployment keeps running, but unpatched vulnerabilities and bugs will not be addressed upstream, which matters for regulated environments that must show current patching. Plan the move to Airflow 3 and, as a first step, move to the latest 2.x release, since the upgrade guide requires Airflow 2.7 or later before upgrading. Ask your compliance team how an unsupported version is recorded and whether a documented exception is needed while migration is in progress.
What does a support agreement cover compared with a one-time upgrade?
A one-time upgrade is a fixed-scope project that moves a defined deployment to a target version and ends with handover. A support agreement is a retainer for ongoing work after go-live, such as applying patch releases, planning minor upgrades, updating provider packages, running database migrations, reviewing DAG changes and responding to incidents. Support is recurring and priced by the agreed service scope, while an upgrade is one-time. Ask for the written list of included services, response expectations, change windows and what is excluded, such as new DAG development or custom operator work.
How DeployOpen delivers Airflow upgrades and support
DeployOpen plans, implements and supports self-hosted Airflow inside your own infrastructure, from a written scope through to a documented handover. Upgrades follow a tested sequence, and ongoing support is available as a retainer.
How we scope
- The written scope names the Airflow version, the target minor release, and the providers and DAGs in play.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
- Ongoing upgrades and support can be contracted as a retainer, with the covered work listed in writing.
How we build
- Upgrades start on a staging copy of the metadata database and the full DAG set.
- DAG code is checked with Ruff AIR301 and AIR302 rules before a move to Airflow 3 is applied.
- Provider package updates and database migrations are tested together, with a rollback path agreed before cutover.
How we hand over
- Runbooks cover upgrade steps, database backup points, scheduler and API server restarts, and rollback.
- Documentation records the pinned versions, provider list, custom code locations and the supported release path.
- The upgrade plan notes the Airflow 2 end of life date, April 22, 2026, and your remaining window.
How we support
- The support agreement defines which Airflow releases, providers and environments are covered, in writing.
- Monitor the Airflow release calendar so limited-maintenance and end-of-life dates trigger planned upgrades.
- Ask whether the retainer includes patch releases, provider updates and upgrades to the next minor version.
