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.
Otto evaluates:
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.
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.
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.
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.
The knowledge base goes beyond what static linters and Airflow’s own migration tooling detect:
Every finding carries a severity (critical, high, medium, or low) and a confidence label:
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.
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.
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.