Upgrade Airflow with Otto

Otto upgrades Airflow projects against a proprietary compatibility knowledge base maintained by Astronomer. The knowledge base captures which upgrade paths are safe, which changes break Dags in practice, and which provider versions are compatible with which Airflow releases. Every finding traces back to a real Apache Airflow GitHub issue, provider changelog, or production incident, so Otto’s evaluations are grounded in evidence rather than generic LLM inference.

Airflow 2 to 3 alone introduced over 121 breaking changes, and the 80+ provider packages each ship on independent release cadences. The compatibility knowledge base is what makes evaluating a specific upgrade path tractable.

Upgrade compatibility coverage

Airflow core versions

Otto evaluates:

• 2.x minor upgrades within the 2.5+ range, including 2.5 to 2.10.
• The 2.x to 3.0 migration, which introduces the largest set of breaking changes in Airflow’s history.
• 3.x point releases, individually tracked from 3.0.1 through 3.1.7.

For each transition, Otto identifies removed and renamed APIs (operators, hooks, context variables), silent behavior changes that compile but produce different results, configuration default changes, and plugin, timetable, and executor interface breaks.

Provider packages

The knowledge base covers 16 providers, prioritized by support volume and usage: Google, Amazon, Kubernetes, Snowflake, FAB, Slack, Databricks, Standard, Azure, Common SQL, SMTP, HTTP, SSH, Celery, Postgres, and MySQL.

For each provider, Otto tracks breaking changes at the parameter level: deprecated parameters, removed operators, base-class swaps, behavior changes within a version range, and the minimum Airflow version required.

Astro Runtime

Otto coordinates Runtime upgrades with the corresponding Airflow core and bundled provider versions, and detects Runtime-specific issues such as namespace package precedence on Astro Runtime images and registry changes that pure Airflow analysis would miss.

Cross-package compatibility

Beyond per-version analysis, Otto flags known incompatible package combinations: dependency diamond conflicts, version locks between core and providers, and pinning requirements that surface only at install time.

What Otto catches

The knowledge base goes beyond what static linters and Airflow’s own migration tooling detect:

• Cross-package dependency conflicts: combinations that fail to resolve or crash at runtime.
• Silent behavior changes: code that compiles but executes differently after the upgrade.
• Custom plugin, timetable, and callback breaks: interface changes in plugin and serialization APIs.
• Provider-level breaking changes: deprecated parameters, removed classes, and signature changes across the 16 covered providers.
• Astro Runtime-specific issues: Runtime image changes that Airflow core analysis alone misses.

How findings are scored

Every finding carries a severity (critical, high, medium, or low) and a confidence label:

• Verified: backed by production incident data, a referenced GitHub issue, or a provider changelog. The fix is known to work.
• AI-suggested: inferred from documented patterns when the knowledge base lacks an exact match. Review before applying.

Each finding includes the file and line, the specific change, and a source reference such as a GitHub issue, provider changelog entry, or migration guide section.

Where the knowledge base comes from

Astronomer curates the compatibility knowledge base from sources tied to real production behavior: public Apache Airflow development history, provider release artifacts, internal migration experience, and the patterns surfaced through Astronomer’s years of support and engineering work. Every entry traces back to a concrete source rather than generic LLM inference.

Run an upgrade with Otto

Ask Otto to evaluate your project in natural language. Examples:

“Which of my Dags would break if I upgrade to Airflow 3?”

“Assess my project for an Airflow 2.7 to 2.10 upgrade.”

“The Snowflake provider has a new release I want. Is my project ready for it?”

“Walk me from Runtime 11 to Runtime 13.”

Otto detects your current Airflow core version, Runtime version, and installed providers, then analyzes the project against the subset of the knowledge base relevant to your transition. The output is a prioritized findings list with file locations, severity, confidence, and proposed fixes.

Otto can apply mechanical fixes directly, including import rewrites, parameter renames, and version bumps. For semantic rewrites such as moving direct ORM access to Task SDK methods, Otto walks through the change with you. Before any patched dependencies are written, Otto verifies that the new dependency set resolves cleanly.

Related

• Skills: The full skill catalog, including the upgrade skill.