Apache Airflow vs Prefect: which to choose

Apache Airflow vs Prefect: when each one fits

Choose Apache Airflow 3 when your pipelines are scheduled DAGs, your team already knows Airflow, and you want the scheduler, metadata database and executors running on infrastructure you control. Airflow 2 reached end of life on April 22, 2026, so any estate still on it is already receiving no fixes, and staying put is not a real option. Choose Prefect when your team writes Python-native flows, needs event-driven automations, and wants a lighter self-hosted server. Either way, the decision turns on four questions: the skills your team has today, whether your pipelines are triggered by events or run on a clock, whether RBAC, SSO and audit logs must run on your own servers, and what the Airflow 2 upgrade will cost you whichever tool you pick.

Team skills usually decide first. If your engineers already maintain DAGs, operate a scheduler and tune a metadata database, the Airflow 3 path keeps that knowledge valuable. Check the Airflow 3.3.2 prerequisites against your current platform, including the PostgreSQL 14 to 18 or MySQL 8.0, 8.4 and Innovation release requirements, and confirm which executor you will run. If your team is mostly Python developers who want flows as ordinary functions, Prefect's model will feel shorter to adopt. Verify that your Python version meets Prefect's requirement of Python 3.11 or later.

The access-control question is the one most likely to change the answer. Prefect's server documentation says RBAC, audit logs and SSO are provided by Prefect Cloud and are not part of the self-hosted server, so if those controls must run in your environment, you need to price Prefect Cloud or accept a different platform. Airflow's auth manager is configured within your own deployment, so confirm with your security team how it meets your identity requirements. Whichever you choose, ask for the Airflow 2 migration effort in writing before comparing licenses, because the upgrade cost applies to both paths.

Which platform fits which team scenario

This table maps common team situations to the platform that fits better and the supplied fact behind that answer. Rows marked with a confirmation note depend on details of your own environment, so check them before deciding. The main takeaway is that the Airflow 2 estate and the identity and audit requirements usually settle the choice, while the rest depends on team skills and hosting.

Team scenario	Better fit	Reason and what to confirm
Existing Airflow 2 estate past end of life	Airflow 3, unless you are rewriting anyway	Airflow 2 reached end of life on April 22, 2026, so it gets no fixes. Moving DAGs to Airflow 3 is the lighter path if your DAGs and operators are mostly standard. Confirm how many DAGs use features changed in the Airflow 3 upgrade guide.
Python-only team with no Airflow skills	Prefect	Prefect flows are plain Python functions with scheduling, retries and caching built in. Airflow requires learning DAG structure, the scheduler and executors. Confirm whether your team already runs Airflow operators elsewhere.
Event-driven triggers from other systems	Prefect (confirm the trigger types you need)	Prefect lists event-based automations as a core capability, and its server records events and automations in its database. Airflow is built around scheduled DAG runs. Confirm the exact trigger sources and latency you need in each platform's current documentation.
Strict identity and audit requirements	Airflow, or Prefect only with Prefect Cloud (confirm your hosting rule)	Prefect's server documentation says RBAC, audit logs and SSO sit in Prefect Cloud, not the self-hosted server. Airflow ships an auth manager interface that you configure in your own deployment. Confirm whether your auditors accept a managed control plane and which identity provider you must integrate with.
Air-gapped or strictly self-hosted hosting	Airflow or self-hosted Prefect server, with no managed dependency	Both run in your infrastructure under Apache-2.0. Prefect's self-hosted server needs PostgreSQL for production, and multi-server setups add Redis and a load balancer. Confirm that the Prefect features you need are available without Prefect Cloud before choosing Prefect.
Large number of scheduled, interdependent batch jobs	Airflow	Airflow's DAG model, scheduler and metadata database are built for many dependent scheduled runs, and it supports multiple schedulers with row-level locks. Confirm your expected DAG count and scheduler load against the Airflow scheduler documentation.
Mixed workloads that need several execution backends	Airflow	Since Airflow 2.10.0, several executors can run in one deployment. Hybrid CeleryKubernetes and LocalKubernetes executors were removed in Airflow 3.0.0, so plan the executor set you will use. Confirm which executors match your compute platform.
Teams that want a dedicated Python workflow with lighter infrastructure	Prefect	Prefect server runs an API, a UI and a database, and uses SQLite by default for trials. PostgreSQL is needed for production. Confirm the infrastructure footprint in your environment, because Airflow production also requires PostgreSQL or MySQL and at least 4 GB of RAM recommended.

How Airflow 3 and self-hosted Prefect are built

Both tools run as self-hosted services with a database at the center, but they split responsibilities differently. Airflow 3 separates scheduling, parsing, serving and metadata across several components, while self-hosted Prefect bundles its API, UI and run-state database into one server. The cards below cover what you operate in each design and where upgrades can bite.

Airflow 3 component split

Airflow 3 runs a scheduler, a DAG processor, an API server, a metadata database and one or more executors as separate parts. Each part has its own process to monitor, scale and restart. Ask your team which of these they already run well, because a missing component is a deployment gap, not a feature gap. Confirm the exact process layout for your executor choice in the Airflow executor documentation before sizing hosts.

Airflow 3.3.2 platform prerequisites

Airflow 3.3.2 supports Python 3.10 to 3.14, PostgreSQL 14 to 18, MySQL 8.0, 8.4 and Innovation releases, and Kubernetes 1.30 to 1.35. MariaDB is not supported as the metadata database, and SQLite should not be used in production. Check these versions against your existing database and cluster standards before you commit, since a mismatch forces a platform upgrade ahead of the Airflow upgrade.

Prefect server bundle

Self-hosted Prefect server bundles an API, a UI and a database that records flow and task run state, logs, deployments, concurrency limits, variables, artifacts, work pool status, events and automations. Operationally this is one service to deploy, back up and upgrade, with workers running your flows separately. Confirm with your team whether a single bundled service fits your existing ownership model for logs and run history.

SQLite default versus PostgreSQL production

Prefect server uses SQLite by default and recommends PostgreSQL for production, so a default install is not a production install. Airflow likewise warns that its SQLite backend is for testing only and can lead to data loss. Plan the PostgreSQL instance, its backups and its high availability from day one in both designs, since the database holds run history you will need for audits and debugging.

Multi-server Prefect requirements

Running more than one Prefect server needs PostgreSQL 14.9 or later, Redis for event messaging and a load balancer in front of the servers. Each added component is another service your team owns, monitors and patches. Confirm whether your platform team already runs Redis and load balancing as shared services, because that decides whether Prefect's multi-server footprint is a small or large addition.

Client and server version skew

Prefect's server documentation says old clients work with new servers, but new clients can be incompatible with old servers because new fields are added to the REST API. Upgrade the server before upgrading worker and flow images, and pin client versions per environment. Airflow upgrades carry a different risk, so compare the two change paths rather than treating Prefect as upgrade-free.

Capability comparison: Airflow 3 and Prefect

This table compares Apache Airflow 3 and Prefect on the capabilities that usually decide a shortlist: licensing, authoring, scheduling, databases, access control and Python support. Read the Prefect column with one caveat in mind: RBAC, SSO and audit logs are documented as Prefect Cloud features, so the self-hosted server needs a different plan for them. The main takeaway is that the two tools differ most in how pipelines are written and where enterprise controls live.

Capability	Apache Airflow 3	Prefect
License	Apache-2.0 from the Apache Software Foundation, with no paid edition from the project itself	Apache-2.0 open-source framework, with the managed Prefect Cloud sold separately
Current release line	Airflow 3.3.2 is the current release; Airflow 2 reached end of life on April 22, 2026	Prefect 3.8.8 released October 6, 2026; the 2.x line still received 2.20.26 on September 2, 2026
Authoring model	Python DAGs that define tasks and dependencies in a directed acyclic graph	Python-native flows and tasks decorated in ordinary Python code
Scheduling and backfills	Scheduler-driven DAG runs; confirm backfill behavior for your DAG patterns against the scheduler documentation	Scheduling is listed as a core capability; confirm backfill support and deployment scheduling in your version
Event-based automations	Confirm event-driven triggering options for your Airflow 3 setup in the vendor documentation	Event-based automations are a documented capability of the Prefect server
Executors or work pools	Several executors, including LocalExecutor, CeleryExecutor and KubernetesExecutor; since 2.10.0 several can run in one deployment	Work pools and workers run flows; confirm which infrastructure types your version supports
Metadata database	PostgreSQL 14 to 18 or MySQL 8.0, 8.4 or Innovation releases; MariaDB and SQLite are not suitable for production	SQLite by default; PostgreSQL recommended for production, and PostgreSQL 14.9 or later for multi-server deployments
Multi-server support	More than one scheduler can run at once, coordinated through database row-level locks	Multi-server deployments need PostgreSQL 14.9 or later, Redis for event messaging and a load balancer
RBAC, SSO and audit logs	Handled by the auth manager, which is documented separately; confirm the auth manager and its features for your target setup	Documented as Prefect Cloud features that the self-hosted server does not include; confirm your plan before relying on them
Python version requirement	Python 3.10 to 3.14	Python 3.11 or later

What is free and what is paid on each side

Apache Airflow is licensed under the Apache License 2.0 (Apache-2.0), and the Apache Software Foundation project has no paid edition of its own. The software itself carries no licence fee, so your spending goes to the infrastructure, the people who operate it and any commercial support or managed service you choose from a third party. Those third-party terms sit outside this comparison.

Software licence: Apache-2.0 covers the core project, so you can run, modify and redistribute it without paying the project.
Infrastructure you pay for: Scheduler, metadata database, workers and executors run in your own accounts or servers, so compute and database storage are recurring costs you size and control.
Upgrade work: Airflow 2 reached end of life on April 22, 2026, so an Airflow 2 estate needs migration to Airflow 3 whichever platform you pick. This work is one-time but can be large.
Third-party operations: Managed Airflow services and paid support are sold by other companies under their own terms.

Before budgeting, confirm in the Airflow auth manager documentation which access and audit features your chosen version provides and which need components you would build or buy.

Where RBAC, SSO and audit logs live

For many regulated teams, this gap decides the shortlist before features are compared. Self-hosted Prefect server does not include role-based access control, audit logs or single sign-on, and the Prefect server documentation places those controls in Prefect Cloud. On Prefect's pricing page, SSO starts at the Team plan at $100 per user per month, while object-level RBAC and multiple workspaces are listed on Enterprise, which uses custom pricing. If your auditors expect these controls to run in your own environment, a self-hosted Prefect server alone will not satisfy that expectation, so the managed tier's cost belongs in the comparison.

Airflow places these controls in its auth manager, so that is the component to check first. The Airflow auth manager documentation describes how Airflow 3 handles authentication and authorization. Confirm, for the exact Airflow 3 release you plan to run, which identity protocols and role models it supports, how permissions map to actions such as triggering or editing DAGs, and where audit events are recorded. Do not assume these behave like Prefect Cloud features. Also note that Airflow 2 reached end of life on April 22, 2026, so an Airflow 2 estate moving to Airflow 3 must carry its access configuration across as part of the upgrade scope.

Put the same questions to each side in writing before shortlisting. For Prefect, ask which features your chosen plan includes: SSO on Team, object-level RBAC and workspaces on Enterprise, and audit logs in Prefect Cloud, as listed on the Prefect pricing page. Ask where audit records are stored, how long they are retained, and how an export reaches your SIEM. For Airflow, ask which auth manager, identity protocol and role model the version you run supports, who maintains that component, and where the audit trail is kept. A written answer from each vendor or implementer is the evidence an auditor or security lead will expect to see.

What drives the running cost of each platform

Running Airflow and Prefect costs different things. Airflow's cost centers on the scheduler, metadata database and workers you operate, while Prefect's self-hosted cost is mostly the server stack, and paid identity and audit features sit in Prefect Cloud. The cards below separate who gets paid for each cost and which parts are one-time versus recurring.

Infrastructure footprint for Airflow

Airflow 3.3.2 recommends at least 4 GB of RAM, and its production guide calls for PostgreSQL or MySQL as the metadata database rather than SQLite. Each scheduler you add for resiliency uses database row-level locks, so the database sizing grows with the deployment. Your executor choice then sets worker capacity: Celery workers run continuously, while Kubernetes pods start per task. Ask your platform team which executor and database tier they will run before estimating the hosting bill.

Infrastructure footprint for Prefect

A single Prefect server runs on SQLite by default, but production use calls for PostgreSQL. Multi-server deployments add PostgreSQL 14.9 or later, Redis for event messaging and a load balancer in front of the API. Each of these components is a separate line item in your hosting plan and a separate patching task. Confirm whether your team needs the multi-server layout at all, since the cost difference between the two layouts is large.

Skills and who writes the pipelines

Airflow pipelines are DAGs built from operators, so teams with provider-package experience and an existing operator library spend less time on integrations. Prefect flows are ordinary Python functions, which suits developers who want to write and test code without learning a scheduler model. The labor cost is paid to your own engineers or to an implementation partner, and it is mostly one-time during migration, then recurring as new pipelines are added. Ask for a skills inventory before comparing salary or contractor rates.

Subscription costs for Prefect Cloud

Self-hosted Prefect server carries no license fee, but teams that need SSO, RBAC or audit logs without building them must consider Prefect Cloud. Its published Team plan is priced per user per month, so the recurring cost grows with every engineer who needs access. Starter and Enterprise have different terms, and Enterprise pricing is custom. Ask Prefect for a written quote covering named users, workspace count and support level, and compare it with the cost of building identity and audit controls in your own environment.

Upgrade work from Airflow 2

Airflow 2 reached end of life on April 22, 2026, so teams still running it receive no fixes. Moving to Airflow 3 requires DAG changes and a new deployment layout, and the hybrid CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported. This upgrade cost is one-time but can be large for a long DAG estate, and it is paid to your engineers or a partner. Prefect has its own 2.x and 3.x lines, so an existing Prefect 2 estate faces a migration decision too.

Identity and audit tooling you add

If your policy requires SSO, RBAC and audit logs on a self-hosted platform, the cost is the identity integration and log pipeline you build or buy, not a license line. For Airflow, the auth manager determines which identity options you configure. For Prefect self-hosted, the server documentation says these features are part of Prefect Cloud, so you would need your own controls around the server. Confirm the required controls with your security team and price them separately before deciding.

Moving from Airflow 2 to Prefect or to Airflow 3

This sequence turns an aging Airflow 2 estate into a documented, tested cutover to either Airflow 3 or Prefect, with clear ownership at each stage. It is a route to plan from, not a schedule to commit to.

Inventory DAGs, operators, connections and variables
List every DAG, the operators and providers each one uses, the connections it reads, the variables and secrets it depends on, and the schedules and sensors that trigger it. Your data engineering lead and the owners of each pipeline should do this together, because many dependencies live in code rather than in documentation. The step is done when every DAG has an owner, a business purpose and a note on whether it is still in use. Unowned or unused DAGs should be retired here, not ported.
Decide between an Airflow 3 upgrade and a Prefect rewrite
Choose the target based on team skills, the share of pipelines that are event-driven, and whether you need Prefect Cloud features such as RBAC, SSO or audit logs for compliance. Airflow 3 keeps the DAG model and the operational habits your team already has, while Prefect means rewriting flows in Python. Record the decision and its reasons in writing, with the people who must approve the identity and audit design. Done means a signed decision record that names the target platform and the owner of the migration.
Stand up the target metadata database and confirm prerequisites
Provision the target environment in your own infrastructure and check its version prerequisites against the current documentation before installing anything. For Airflow 3, confirm the supported Python, PostgreSQL or MySQL, and Kubernetes versions, and note that SQLite is not for production and MariaDB is not supported as a metadata database. For Prefect, confirm the Python requirement and plan PostgreSQL for production. Your platform team should own this work and produce a build record with versions pinned. Done means a reachable production-grade database and a checklist that every prerequisite has been verified.
Port or rebuild DAGs and tests
Move the business logic, SQL and Python libraries first, then rebuild the orchestration layer around them. Scheduling definitions, executor configuration, connections and identity setup generally need rebuilding, not copying. Add tests that run each pipeline against non-production data, and compare outputs with the Airflow 2 results for the same inputs. Your data engineers own the port, and the pipeline owners sign off on output parity. Done means every retained pipeline passes its tests and its outputs match the reference run.
Run both systems in parallel under a cutover plan
Run the new platform alongside Airflow 2 for the pipelines that have been ported, and compare run history, failures, alerts and downstream results. Write a cutover plan for each pipeline that states the switch point, the rollback step and who approves it. Confirm that identity, audit logging and alerting work in the new environment before any production traffic moves. Done means each pipeline has a recorded cutover decision and a tested rollback path.
Retire Airflow 2 after confirming its end of life
Airflow 2 reached end of life on April 22, 2026, and receives no fixes, so every day it stays in production is an unpatched exposure. Keep it running only as long as needed to finish cutovers, restrict its network access, and document the remaining dependencies. Once all pipelines are verified on the target, decommission the scheduler, webservice and database, and archive the configuration and run history your audit team requires. Done means the decommission record is signed and the retained evidence is stored where your compliance lead can find it.
Set the timeline from a written scope
This page does not set a cutover date or effort estimate. The duration depends on the number of DAGs, their external dependencies, the identity and audit requirements, and how much testing your regulator or internal policy expects. Ask any implementation partner, including DeployOpen, to price and schedule the work from a written scope that lists the pipelines, targets and acceptance criteria. Done means an agreed scope and a schedule that the owners of each system have accepted in writing.

Where Airflow and Prefect projects usually run long

Most overruns start in production setup, not in the first DAG or flow. An Airflow 3.3.2 deployment needs a PostgreSQL 14 to 18 or MySQL 8.0, 8.4 or Innovation release metadata database, since the production guide warns that SQLite can lose data and MariaDB is not supported. Teams then have to decide how many schedulers to run, because Airflow supports several at once using database row-level locks, and whether one executor or several will run tasks. Since Airflow 2.10.0 several executors can share one deployment, but the hybrid CeleryKubernetesExecutor and LocalKubernetesExecutor were removed in Airflow 3.0.0, so any Airflow 2 estate using them needs a redesign before the move. Ask your team to confirm the executor choice, the database sizing and the upgrade path from Airflow 2.11.2, which reached end of life on April 22, 2026.

Prefect production work is different in shape. Self-hosted Prefect server uses SQLite by default and PostgreSQL for production, and a multi-server deployment also needs PostgreSQL 14.9 or later, Redis for event messaging and a load balancer in front of the API. Client and server versions must be aligned on purpose, because the server documentation notes that new clients can be incompatible with old servers as new fields are added to the REST API. Identity is the item teams most often discover late. The server documentation says RBAC, audit logs and SSO belong to Prefect Cloud rather than the self-hosted server, so if your policy requires them on your own infrastructure, confirm that requirement and the licensing path before design is final.

Two delays recur on both sides. For Prefect, the cost is usually rewriting existing DAG logic into Python flows, tasks and deployments, and that work scales with how much orchestration logic sits inside the current pipelines. For Airflow, it is executor tuning, queue sizing and worker behavior under load. Identity and audit requirements that surface during security review can reshape either design, and running the old and new schedulers in parallel during cutover doubles the operational load until the last dependency moves. DeployOpen plans and implements these items under a written, fixed scope agreed before work starts, so effort is estimated only for the components, environments and deliverables that scope names. Ask for the scope to list each of these risks explicitly, with the owner and the acceptance test for each.

Questions buyers ask before choosing or hiring help

Can our team run Airflow 3 or self-hosted Prefect without outside help?

Often yes, if you already run Python services in production and have someone who can own a database, a container platform and upgrades. Airflow 3 needs a scheduler, a DAG processor, an API server and a metadata database, and the prerequisites list PostgreSQL 14 to 18 or MySQL 8.0, 8.4 or Innovation releases. Self-hosted Prefect is lighter to start, but a production server needs PostgreSQL, and multi-server deployments add Redis for event messaging and a load balancer. The skill gap is usually operations, not Python: backups, upgrades, secrets, network exposure and on-call. Ask whether your engineers have run a stateful Python service with a database behind it before, and confirm the choice against the Apache Airflow supported versions and Prefect self-hosted documentation for your target versions.

What drives implementation cost, and what should a written quote include?

The main cost drivers are the number of existing DAGs or flows, how many custom operators and integrations they depend on, the number of source and destination systems, the identity and audit requirements, and how many environments you need (development, test and production). Infrastructure is a separate line from labor: you pay for compute, the metadata database and any managed services, and those recur monthly. Implementation labor is one-time, while upgrades and on-call support recur. Ask a quote to list the scope in writing, the deliverables for each phase, which components are installed and where they run, what testing is included, what documentation and handover you receive, and which items are excluded. DeployOpen works from a written scope before any work starts and does not publish a price list, so the quote is the only reliable figure.

How long does an Airflow 2 migration take, and what sets the duration?

The timeline depends on the state of your estate, not on a standard number. Airflow 2 reached end of life on April 22, 2026, so it no longer receives fixes, which makes the migration urgent regardless of effort. Duration is driven by how many DAGs use deprecated patterns, how many depend on the hybrid CeleryKubernetesExecutor or LocalKubernetesExecutor (both no longer supported as of Airflow 3.0.0), how many custom plugins or providers you maintain, how much of the metadata history you must keep, and how many teams must test their pipelines. Ask for a DAG inventory and a dependency review before agreeing on a timeline. The official Airflow 3 upgrade guide lists the breaking changes to check against each DAG.

Can self-hosted Prefect meet our SSO and audit requirements on its own?

Not on its own, if SSO, RBAC and audit logs are mandatory. The Prefect server documentation states that Prefect Cloud provides RBAC, audit logs and SSO, which the self-hosted server does not include. Prefect's pricing page places SSO on the Team plan and object-level RBAC and multiple workspaces on Enterprise. Before you rely on a self-hosted deployment, confirm with Prefect whether your required controls are available in the open-source server, and map each control to the evidence your auditors will ask for. Also confirm where run logs and events are stored and who can read them. If you need those controls on your own infrastructure, plan for a Cloud plan or a different tool, and budget the licensing as a recurring cost.

Should we choose Airflow if most of our work is event-driven?

Probably not as your primary choice, unless your event-driven work can be modeled as scheduled or sensor-based runs. Airflow is built around DAGs that run on schedules, backfills and dependencies between tasks, and it can wait on external conditions through sensors. Prefect describes event-based automations as part of its framework, and its self-hosted server records events and automations in its database. Test your real triggers, such as message queues, file arrivals or API webhooks, against each tool with a proof of concept. Measure latency, retry behavior and how many trigger-driven runs the database must record each day.

What must our team provide before an implementation partner can scope the work?

A partner needs enough access and information to write a scope that holds up. Provide environment access in the target cloud account, data center or air-gapped network, with agreed network paths to source systems and a place to store secrets. Share a DAG or flow inventory with owners, schedules, dependencies and the systems each one touches. Give identity provider details, including the protocol you use (for example SAML or OIDC), group mappings for roles, and who approves access. Also list your database preference, backup and retention rules, upgrade windows and the audit evidence your compliance team expects. Missing items usually extend the timeline and change the quote, so ask for a written list of prerequisites before you sign.

Does the choice between Airflow and Prefect affect what we pay later to switch?

Yes. Switching later means rewriting DAGs or flows, moving run history if you need it, and retraining the team, so the first choice carries real migration cost. Airflow pipelines are DAG files that depend on Airflow operators and the metadata database, while Prefect flows are Python functions with decorators and a server-side state model. Both are Apache-2.0 licensed, so the software itself carries no license exit cost, but the pipeline code and operational knowledge do. Keep business logic in plain Python modules and separate it from orchestrator code to lower the cost of any future move. Ask any partner to estimate the switching work in the written scope.

How DeployOpen helps choose, implement or migrate

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Airflow versus Prefect decision can be tested against your environment before anything is built. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing first.

How we scope

Map which DAGs, schedules and event-driven triggers exist today and which teams author and operate them
Confirm the Airflow 2 estate and the work needed to reach Airflow 3 before comparing it with Prefect
Record SSO, RBAC and audit log requirements, and where each would be met in the chosen setup
Agree deliverables, timelines and exclusions in writing before any build work starts

How we build

Stand up a proof of concept of representative pipelines on each candidate, in your own cloud or data center
Choose and configure the metadata database, executor model and secrets handling for your environment
Test retries, backfills, failure alerts and scheduler behavior under load you define with your team
Document architecture, upgrade steps and access controls so the choice stays auditable

How we hand over

Deliver runbooks for deployment, backups, upgrades and day-to-day pipeline operations
Train the platform and data engineering staff who will author and maintain the pipelines
Provide evidence for access control, logging and change management for your compliance assessors
Hand over the environment with a clear record of what DeployOpen configured and what you own

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover
Plan version upgrades against the vendor's published support windows and your change calendar
Retest pipelines and access controls after each upgrade or configuration change
Ask any independent auditor to review compliance evidence, since DeployOpen prepares it but does not certify it

Apache Airflow vs Prefect