Airflow Estate Assessment

An assessment is the first thing we do on almost every estate, because the honest answer to "how long will the upgrade take" depends on things nobody has written down.

What we read

• DAG inventory and dependency map. Every DAG, its owner if there is one, its schedule, its upstream and downstream data dependencies, and which DAGs actually still matter to someone.
• Scheduler and executor topology. How the scheduler, DAG processor, workers and triggerer are deployed, how they are sized, and where the bottlenecks show up in practice.
• Provider and operator drift. Which provider packages are pinned where, which custom operators wrap what, and which imports are deprecated or gone in Airflow 3.
• Deprecated API usage. Context variables that were removed, SubDAGs, direct imports from internal modules, and task code that queries the metadata database.
• Airflow 2 end-of-life exposure. What you are running on unmaintained code, and how much of it is reachable from outside.
• Secrets and connections. Where credentials live, how they rotate, and whether DAG code reads them in ways that will break.
• SLA and failure history. What fails, how often, what is retried into success, and what the on-call channel has learned to ignore.

What you get

A written findings document and a prioritised, sequenced plan. Each DAG gets a recommendation: migrate as is, rewrite, consolidate, or retire. The plan is written for your engineers, so it stands on its own if you would rather do the work in-house.

What it is not

It is not a sales document for a migration. Some estates should be frozen and shrunk rather than moved, and a few teams genuinely belong on a different orchestrator. If that is the finding, the document says so.

Billed hourly, like everything we do. Start with a conversation.