Migrate from Control-M to Apache Airflow

How long a Control-M to Airflow migration takes and what it involves

To migrate from Control-M to Apache Airflow, plan a staged coexistence with a folder-by-folder cutover, not a single switch. Effort depends mainly on three things: the number of jobs in each Control-M folder, the complexity of the calendars that decide when those jobs run, and how many downstream systems depend on each job's output. Airflow is released under the Apache License 2.0 with no paid edition from the project itself, so the cost of the move is implementation and operating effort: building and testing DAGs, standing up the platform, and running it afterward. Licensing is not the line item to model.

Start by inventorying folders, jobs, calendars, conditions and SLAs, and by naming an owner for each folder. Then decide how long Control-M and Airflow will run side by side. The Control-M for Apache Airflow plug-in lets Control-M connect to Airflow endpoints, run and monitor Airflow jobs alongside existing Control-M jobs, and attach SLA jobs to them, so enterprise jobs can keep their current dependencies while individual folders move. Confirm with BMC which plug-in version matches your Control-M release and your Airflow version, since the documented minimum Airflow version for the 9.0.22 plug-in is 2.5.0. Airflow 3 is the target for new work, so check that the plug-in supports it before you commit to a version.

Ask any implementation partner to quote against a written list: job count per folder, calendar and rule types, external dependencies, SLA definitions, and the number of environments to build. Each item changes the work. Calendar translation and SLA monitoring are the usual sources of rework, so validate them early. For SLA rules, review the Apache Airflow deadline alerts documentation, which describes Deadline Alerts as experimental in Airflow 3.1, before you map Control-M SLA jobs onto them. Confirm the feature's current status for your version, and plan a fallback monitoring path in case it changes.

Which Control-M concepts map cleanly to Airflow and which do not

This table pairs each Control-M concept with its closest Airflow equivalent and notes where the mapping is partial or needs redesign. Read it as a starting inventory: a row marked partial means the behavior must be confirmed against your own jobs before you commit to a translation.

Control-M concept	Airflow equivalent	Migration note
Job types and job folders	DAGs grouped by team, folder or repository, with operators per task	Folders become DAG bundles or repositories, not a single container. Each Control-M job type needs an operator or custom code, and some types have no direct operator to confirm.
Conditions and dependencies	Task dependencies inside a DAG and asset-based scheduling across DAGs	In-DAG dependencies map cleanly. Cross-folder conditions often need redesign into assets or explicit triggers, so confirm each one.
Calendars and scheduling	Cron expressions and timetables, including custom timetables	Simple calendars translate well. Business-day, holiday and rolling calendars usually need a custom timetable or a check task, and must be tested against real dates.
Resources and quantitative limits	Pools, task concurrency limits and queues	Pools cover many cases, but Control-M resource semantics may differ. Confirm how each shared resource is consumed and released.
SLA and deadline monitoring	Deadline Alerts (experimental in Airflow 3.1) and SLA-style callbacks	Deadline Alerts are marked experimental, so treat them as partial coverage. Confirm the reference and callback behavior your alerts need, and keep Control-M SLA jobs running during coexistence.
File watchers	Deferrable sensors or triggers that wait for files	Waiting maps well, but polling load, file locations and access from workers need redesign. Test timeouts and missed-file handling.
Restartability and reruns	Task retries, clearing tasks and backfills	Reruns work differently. Rerun semantics for partially completed workflows need explicit design and a test in staging.
Alerting and notifications	Callbacks, notifiers and alerting integrations	Alert routing rarely translates one to one. Rebuild alert rules and confirm recipients and escalation paths before cutover.

How the Control-M for Apache Airflow plug-in supports coexistence

The Control-M for Apache Airflow plug-in is the piece that lets Control-M keep governing enterprise jobs while Airflow takes on new pipelines. BMC documents it as a component that connects to Airflow endpoints, runs and monitors Airflow jobs alongside other Control-M jobs, and can attach SLA jobs to them. That means during coexistence your existing Control-M calendars, dependencies and alerting can still gate work that now executes in Airflow, so a batch chain can cross both platforms without someone rewriting the handoff by hand.

Check the version pairing before you design around the plug-in. The BMC documentation for Control-M for Apache Airflow lists a minimum Airflow version of 2.5.0 for the 9.0.22 documentation. Airflow 2 reached end of life on April 22, 2026, so it gets no fixes, and the target for new work should be Airflow 3, currently at patch 3.3.2. Confirm with BMC that the plug-in supports both your Control-M release and the Airflow 3 line you plan to run. Ask whether the plug-in needs any change to how Airflow API access is authenticated, since Airflow 3 replaces the older webserver with an API server and changes how credentials are handled.

Treat the plug-in as a coexistence tool with a defined end date, not a permanent bridge. Record every job that Control-M triggers into Airflow, every SLA job attached to it, and every point where a Control-M calendar still decides when Airflow work starts. Each of those links is a dependency you must retire or re-express in Airflow before the Control-M job folder is switched off. Confirm with BMC how the plug-in reports status when an Airflow run is queued, retried or cancelled, because that behavior determines whether your Control-M alerts stay accurate during the transition.

Choosing a migration path by job estate

An estate with mostly independent jobs is the simplest to move. Each job reads its inputs, writes its outputs and has few links to other folders, so a folder can be translated and cut over without holding the rest of the estate still. The plug-in is useful here mainly as a bridge: it lets Airflow tasks be triggered and monitored from Control-M while each folder is proven, which keeps one scheduler in charge of every job during the early weeks.

Move by folder, one at a time: Pick a low-risk folder first, translate its jobs and run both schedulers until outputs match.
Keep the plug-in for visibility: Use it to run and monitor Airflow jobs from the existing Control-M console while teams learn the new tooling.
Retire Control-M jobs as they are verified: Disable the original job only after its DAG has produced matching outputs across a full cycle.
Avoid long dual runs: Independent jobs do not need a lockstep window, so keep the coexistence period short for each folder.

Before you commit, confirm with BMC which plug-in version matches your Control-M release and that your Airflow version meets its stated minimum.

Documented import paths and interfaces for the move

No automated converter from Control-M job definitions to Airflow DAGs is documented in the sources supplied for this topic. The cards below cover the interfaces that do exist, so the team can plan a rebuild-and-review approach around them.

Control-M for Apache Airflow plug-in

BMC documents a plug-in that connects Control-M to Airflow endpoints, runs and monitors Airflow jobs alongside existing Control-M jobs, and can attach SLA jobs to them. This is the documented route for a coexistence phase, where Control-M keeps the calendar and the enterprise view while DAGs take over workloads one folder at a time. Check the plug-in's minimum Airflow version against the release you plan to run, and confirm which Control-M and Airflow versions BMC supports together.

Airflow REST API and Task SDK

In Airflow 3, task code can no longer use the metadata database sessions or models directly. Tasks that need to read or report state must go through the REST API or the Task SDK. Any Control-M-side integration that touches run state, or any custom operator that reads a Control-M handoff value, has to be designed against these interfaces rather than the old database access patterns.

Airflow 3 upgrade guide

The upgrade guide lists the removed features and interface changes that affect job code written for earlier releases. Teams that already run Airflow 2 as the coexistence target should read it before they write new DAGs, because the guide sets the baseline for what a rebuilt job must avoid. Use it as the checklist for review, not as a source of migration automation.

Ruff AIR301 and AIR302 checks

The upgrade guide recommends checking DAG code with the Ruff AIR301 and AIR302 rules. These checks flag patterns that Airflow 3 no longer supports. Run them on every rebuilt DAG in CI so that a job translated by hand from a Control-M definition does not carry a removed import or deprecated call into production.

The apache/airflow repository

The project source is public on GitHub under the Apache License 2.0. Use the repository as the reference for operator signatures, provider behavior and release notes when a rebuilt job depends on a specific feature. Pin the Airflow version your team tests against, and confirm behavior in the tagged release rather than in the main branch.

Translating Control-M calendars and dependencies into DAGs

Start with an inventory of every Control-M calendar, date rule and inter-folder condition before translating any job. Control-M separates when a job runs, set by its scheduling criteria and calendars, from what must finish first, set by conditions that link jobs across folders. Export both from the Control-M environment, record which folders each condition crosses, and mark which calendars are shared by several folders. Ask your Control-M administrators to identify jobs that depend on manual overrides, ad hoc reruns or special date handling, because those exceptions are the ones that break quietly after cutover. The inventory also shows which folders have no cross-folder conditions, so they can be translated and moved first.

Most calendar logic moves into the schedule of each DAG. A cron-style or custom timetable can reproduce a recurring business-day pattern, and a downstream DAG can be triggered when an upstream task updates an asset. Pay close attention to logical dates. An Airflow run carries a logical date that marks the start of its data interval, and the run starts after that interval ends. A Control-M order date is the day a job is scheduled for, so a job that Control-M starts on a given morning may map to an Airflow run labeled with the previous interval. Record this offset for every calendar-driven job, and confirm with business owners which date appears in output file names, reports and downstream loads. A mismatch here usually shows up as a missing or duplicated day, not as a failed run.

Decide how each folder maps to Airflow structure. Jobs that share one schedule can become a group of related DAGs or TaskGroups inside one DAG, and the choice depends on how the folder's jobs are triggered and monitored. Do not plan around SubDAGs. The Airflow 3 upgrade guide lists them as removed in favor of TaskGroups, so any folder design that nests DAGs as SubDAGs must be rebuilt. Cross-folder conditions that cannot be expressed as assets or DAG triggers need an explicit decision: keep the dependency in Control-M while coexistence lasts, or add a sensor that waits on a known completion signal. Record an owner for each cross-folder link before cutover, because each choice changes what operators see when a run stalls.

The sequence from inventory to decommissioning Control-M

This sequence moves Control-M workloads to Airflow in controlled stages, so each folder is proven on Airflow before its schedule and SLA duties leave Control-M. The output is a retired Control-M estate with a documented, evidenced cutover for every folder.

Inventory folders, jobs, calendars and owners
Export every Control-M folder, job definition, calendar, SLA and dependency, and record a named business owner and technical owner for each folder. Your Control-M administrators and the job owners confirm the inventory, and the team flags jobs that read local files, call agents on specific hosts or depend on other folders. The step is done when every job maps to a folder, an owner and a disposition (move, retire or keep on Control-M for now).
Build the Airflow platform on supported components
Deploy Airflow 3 on PostgreSQL 14 to 18 as the metadata database, on Kubernetes 1.30 to 1.35 or on virtual machines you control. Lay out more than one scheduler from the start, since Airflow supports concurrent schedulers using database row-level locks, and separate the API server and DAG processor as Airflow 3 requires. The step is done when a test DAG runs through every component and the platform team has tested a scheduler restart without losing runs.
Pilot one folder end to end
Choose one folder with a small job count, few external dependencies and a low business impact, then rebuild its jobs as DAGs with their calendars, retries and alerting. The pilot runs in Airflow while Control-M still holds the production schedule, so outcomes can be compared without risk. The step is done when the pilot team signs off the DAG behavior, the failure alerts and the run history against the agreed acceptance criteria.
Coexist through the Control-M plug-in
Connect Control-M to Airflow with the Control-M for Apache Airflow plug-in so Control-M can run and monitor Airflow jobs alongside its existing jobs. Confirm that your Airflow version meets the plug-in's minimum (2.5.0 per BMC's 9.0.22 documentation) and check the plug-in release against your Airflow version before connecting. The step is done when a Control-M workflow triggers an Airflow DAG and reports its status back correctly.
Run parallel and compare outcomes and SLA timing
Run each migrated folder in both systems for an agreed period, comparing run status, output data, row counts, start times and completion times against Control-M. Record SLA timing in both systems, and review any gap that changes when a downstream consumer receives data. The step is done when the operations and business owners accept the comparison report and each difference has a documented cause and fix.
Cut over folders in dependency order
Move folders one at a time, starting with low-risk folders that have the fewest upstream and downstream dependencies, and leave high-impact or tightly coupled folders for later. For each folder, disable the Control-M schedule, switch the production schedule to Airflow, and keep a documented rollback path until the folder has run cleanly. The step is done when the folder's cutover record shows the owner's approval, the rollback window closed and the Control-M schedule was removed.
Decommission agents and server after retention
After every folder has run cleanly on Airflow and the agreed retention period for Control-M definitions, logs and audit records has passed, stop the Control-M agents and then the Control-M server. Archive job definitions, calendars and run history in a form your auditors can read, and confirm the retention terms with your compliance team before deletion. The step is done when agents and server are shut down, the archive is verified and the decommissioning record is approved.

What drives the cost and duration of the move

This table compares each driver of Control-M to Airflow effort, what pushes it up, what brings it down, and what to request in a fixed-scope quote. Read it before comparing quotes, because a low headline number often reflects a narrower scope than the one you actually need.

Driver	What increases it	What reduces it	Ask for in the quote
Folders and jobs in scope	Many folders with hundreds of jobs, jobs owned by several teams, and jobs with no current owner	A current inventory exported from Control-M, grouped by folder, owner and business service, with retired jobs removed first	Job count by folder, the migration order, and whether retired jobs are excluded from scope
Calendar and condition complexity	Custom business calendars, rolling and relative date rules, and conditions that depend on other folders or prior-day outcomes	Calendars consolidated into a short list of named rules before translation, and conditions confirmed with the business owner	How each calendar and condition type will be translated, and who signs off on the mapping
Control-M-specific features in use	Event-based triggers, file watchers, resource pools, quantitative resources and custom job types that have no direct Airflow equivalent	A feature audit that lists each Control-M object type used, with a chosen Airflow pattern for each	Written mapping for every object type found in the audit, including any items to be redesigned rather than translated
SLA definitions	SLAs tied to completion times across many dependent jobs, or SLAs that business teams expect to be measured the same way they were in Control-M	A short list of critical SLAs, each with a named owner, an agreed measurement point and an alert route	How SLAs will be attached to Airflow jobs, how Deadline Alerts (experimental in Airflow 3.1 per the Airflow deadline documentation) will be used or avoided, and how alerts reach existing on-call tools
Downstream consumers	Files, databases or APIs consumed by many systems, each needing a cutover notice and a validation step	A consumer register with contacts, agreed cutover dates and a defined validation check per consumer	Number of consumers covered, validation steps per consumer, and who performs sign-off
Data platform and connection work	Many connection types, new credentials to store in a secrets backend, network paths that need firewall changes, or heavy use of Control-M agent-side scripts	Existing Airflow connections or providers already approved for use, and a plan to reuse secrets stores already in place	Connection list by type, secrets backend in use, and which network changes the client must approve
Parallel-run length	Business requirements for a long period where both schedulers run the same jobs and results are compared	A parallel run limited to critical folders, with defined comparison criteria and an agreed end date	The parallel-run window per folder group, comparison method, and the decision owner for cutover
Airflow 3 upgrade needs	A target Airflow 2 environment, which must be upgraded (the upgrade guide requires Airflow 2.7 or later first), or DAG code that needs Ruff AIR301 and AIR302 fixes	Greenfield Airflow 3 deployment, or an existing version already on a supported release line	Current Airflow version, whether an upgrade is included in scope, and the plan for checking DAG code
Team skills	Few staff who know both Control-M and Airflow, and limited Python or Git experience among job owners	Job owners trained on DAG authoring and review in the coexistence phase, and a named internal owner for each migrated folder	Who on the vendor side will do the translation, who on your side will review it, and what training is included

What usually goes wrong in a Control-M exit and how to prevent it

Most failed Control-M exits fail in the coexistence period, when two schedulers hold partial truth about the same pipelines. The cards below cover the failure modes we see most often, each with the check that prevents it.

Double runs during coexistence

When a job is live in both Control-M and Airflow, both schedulers can fire it for the same business date. The result is duplicate loads, doubled notifications or conflicting writes to the same target. Before cutover, assign each job one owner in a shared inventory, disable the Control-M schedule for any job that Airflow now owns, and confirm that the DAG's outputs are idempotent so a rerun does not duplicate rows.

Calendar drift between systems

Control-M calendars combine working days, rule-based schedules and exceptions that often accumulate over years. A translated Airflow schedule can match the calendar on normal weeks yet miss month-end, holiday shifts or fiscal exceptions. Export each calendar's effective dates for the next twelve months from both systems and compare run dates job by job before any schedule is switched.

Lost implicit dependencies

Some Control-M dependencies are never written as conditions. They live in shared file paths, prerequisite conditions set by an operator or a job that happens to finish before another starts. These do not appear in an export of defined dependencies. Trace input and output paths, database tables and file watchers for each job, then add explicit Airflow dependencies or sensors where the link is real.

SLA timing changes

Control-M measures deadlines against its own schedule and job history, while Airflow SLA-style alerting depends on how the team defines the reference point. A deadline that was met in Control-M can appear missed in Airflow, or the reverse. Define each business deadline in writing, then compare the Control-M SLA job and the Airflow deadline configuration for the same job on a set of historical runs. Confirm the exact behavior of Deadline Alerts in your Airflow version, since the feature is experimental.

Secrets and connections not carried over

Control-M stores credentials in its own agent and vault configuration. When DAGs are moved, connections, passwords and API tokens are often left behind, so jobs fail only when they first run in Airflow, sometimes at night. Inventory every host, database and account a job uses, recreate each as an Airflow connection backed by your secrets store, and test each connection with a non-production run before the schedule moves.

Control-M features with no direct equivalent

Some Control-M capabilities, such as specific agent-based job types, certain file triggers, or resource and quantitative controls, may not map one to one to Airflow operators or features. Make a feature register that lists every job type and control in use, marks each as directly mapped, mapped with custom code or retained in Control-M, and records who approved the decision. Confirm each mapping against the provider package and version you deploy.

Decommissioning before audit evidence is retained

Retiring Control-M removes run history, job logs and approval records that auditors may request for prior periods. Once the server is shut down, that evidence may be gone. Before decommissioning, export run logs, calendars, job definitions, change records and access lists to retained storage, and agree with compliance which retention period applies. Keep a read-only copy of the job definitions for the period auditors may still examine.

Questions buyers ask before moving off Control-M

What does a Control-M to Airflow migration cost, and what drives the price?

The cost depends on how many jobs, calendars, dependencies and SLA rules you have, how much of each job must be rebuilt rather than translated, and how many systems the jobs touch. A quote follows from a written scope, so the useful work happens first: an inventory of job folders, calendars and conditions, and a list of the target systems each job calls. Costs fall into one-time items (inventory, translation, testing, parallel runs, cutover) and recurring items (the Airflow platform, Control-M licensing you keep during coexistence, and support). Ask for the quote to separate the plug-in work, the calendar translation and the SLA monitoring design, so you can see what each part costs. Ask BMC to confirm your current Control-M licensing terms for the coexistence period.

How long does it take to move job folders off Control-M?

Duration is set by the number of job folders, how interdependent they are, and how many parallel runs your business requires before a folder can be cut over. A folder with simple time-based schedules moves faster than one with cross-folder conditions, resource locks, or month-end calendars that must match exactly. Planning the order of folders is often the longest early step, because moving a upstream job before its consumers creates split-brain dependencies. Your timeline should be written into the scope with milestones per folder group. Treat any duration you hear before the inventory is complete as a guess, and ask for the inventory output to be the first deliverable.

What must our internal team provide during the migration?

Three roles are needed from your side, and the project slows down without them. Job owners confirm what each job does, which inputs it reads, which outputs matter, and what failure looks like to the business. Calendar owners confirm business days, holidays, close calendars and any exceptions that Control-M applies through calendars or conditions. SLA owners define the deadlines, the acceptable lateness, and who is notified when a deadline is at risk. Each of these people needs time booked in the plan, and each sign-off should be recorded. Also name an owner for the Control-M administration side, since that team holds the definitions you will export and the conditions you will need to explain.

Can our own team migrate off Control-M without a partner?

Yes, if the team has Airflow engineers who can write and test DAGs, someone who understands Control-M's object model, and time for parallel runs. A partner is most useful when the inventory is large, when calendars and conditions are tangled, or when the same people must keep production running during the change. The decision rests on skills and capacity rather than on the tool. Ask your team to list which Control-M objects they can translate without help, which SLA rules they have documented, and who will own the coexistence period. Whichever path you choose, the written scope should name the owner of each deliverable.

Can the Control-M plug-in run Airflow jobs during coexistence?

BMC documents a Control-M for Apache Airflow plug-in that connects to Airflow endpoints, runs and monitors Airflow jobs alongside other Control-M jobs, and can attach SLA jobs to them. This lets you keep one operational view while individual folders move, which is the main reason to use it during coexistence. Confirm with BMC that the plug-in version in your environment supports the Airflow version you plan to run, since BMC's 9.0.22 documentation lists a minimum Airflow version of 2.5.0. Also confirm which Control-M features your jobs depend on, because not every object type may map cleanly to Airflow. Test the plug-in in a non-production Control-M environment before relying on it.

Do we need Airflow 3 to move off Control-M?

Airflow 3 is the current major line, first released on April 22, 2025, and it is the version we would plan for a new target unless a constraint says otherwise. The BMC plug-in documentation lists 2.5.0 as a minimum version, so the plug-in itself does not force Airflow 3. Airflow 3 does change how DAGs run: task code cannot use the metadata database directly, the webserver is replaced by an API server, and the DAG processor runs separately. Older DAG code may need changes before it runs on 3, so check it with Ruff rules AIR301 and AIR302. Airflow 2 entered limited maintenance on October 22, 2025 and reached end of life on April 22, 2026, so a new platform on Airflow 2 would be a poor choice.

How is run history from Control-M kept after cutover?

Control-M run history stays in Control-M unless you export it, so decide what must be retained before cutover. Most teams keep Control-M read-only for the audit window their policies require, and they keep Airflow's own run history for new runs. Confirm the retention period with your compliance owner and check which logs, return codes and outputs Control-M stores that you need to reproduce or cite. Export formats and retention behavior depend on your Control-M version and configuration, so confirm both with BMC and in your environment. Airflow retains its own run history according to your metadata database cleanup settings, which should be configured deliberately rather than left at defaults.

How do SLA alerts from Control-M carry over to Airflow?

Control-M SLA jobs and the alerts they raise must be re-created as Airflow alerting or monitoring, and Airflow's own deadline feature is a starting point. Airflow 3.1 introduced Deadline Alerts, which are marked experimental and need a reference, an interval and a callback. Async callbacks run in the Triggerer, and sync callbacks, added in 3.2, run in the executor. Decide which SLA rules must be proven equivalent in parallel runs before you turn off the Control-M alert. Your SLA owners should sign off on each rule, including who receives notifications and how escalation works.

Where to confirm plug-in and Airflow version details

Before you scope a coexistence phase, confirm the plug-in details with BMC rather than working from memory of older releases. The Control-M for Apache Airflow documentation is the starting point, and the version you read should match the Control-M release you run, because the minimum Airflow version it lists (2.5.0 in the 9.0.22 documentation) affects whether your current Airflow can be used as a target at all. Ask BMC to confirm which Airflow endpoints the plug-in calls, how it authenticates to them, which SLA job types it supports for Airflow jobs, and whether it works with the Airflow 3 API server and the separate DAG processor that Airflow 3 requires. Get those answers in writing, since they determine what your Control-M administrators can monitor during coexistence.

Next, read the Apache Airflow deadline alerts guide if your Control-M SLA jobs need to be replaced rather than mirrored. Deadline Alerts arrived in Airflow 3.1 and are marked experimental, so confirm with your platform team whether your target version is one you are willing to run in production. Note which reference points each alert can use, and whether your callbacks need to run asynchronously in the Triggerer or synchronously in the executor, since that choice changes how alerts behave when workers are saturated. Then open the Airflow version life cycle page and record the current patch release and support status of each Airflow line you are considering, so the target version is not already in limited maintenance when your migration ends.

Finally, confirm details that only your own environment can answer. Inventory which Control-M job folders depend on the plug-in, which Control-M agents and Airflow hosts sit on the same network segments, and which credentials each side will hold. Check the Airflow prerequisites for the Python, database and Kubernetes versions your infrastructure supports, and confirm that your metadata database is PostgreSQL or MySQL rather than a default SQLite backend. Ask your security team to review how the plug-in's service account is authorized in both systems. A short written list of these answers, signed off by the Control-M owner and the Airflow platform owner, becomes the input for scoping the work.

How DeployOpen works on this

DeployOpen plans and implements self-hosted Apache Airflow inside infrastructure you control, and works through a Control-M exit as a written, fixed-scope engagement. The scope fixes which job folders move, in what order, and how coexistence with Control-M is run and retired.

How we scope

Inventory of Control-M job folders, calendars, dependencies and SLA jobs in scope
Written mapping of each folder to a migration wave and an owner
Agreed list of Control-M features that need replacement or retirement before cutover
Confirmed list of Airflow endpoints, connections and secrets the plug-in will reach
Scope, deliverables and timelines agreed in writing before work starts

How we build

Airflow 3 deployed on the metadata database, executor and DAG delivery you approve
Control-M for Apache Airflow plug-in configured for the coexistence phase, checked against your Control-M version
Calendars and dependencies translated into DAGs, with each translation reviewed against the original job
SLA monitoring rebuilt and tested with sample failing and late runs before go-live
Parallel runs compared job by job, with differences logged and resolved before cutover

How we hand over

Runbooks for DAG deployment, scheduler recovery, backups and job restarts
Mapping document linking every retired Control-M job to its DAG and owner
Cutover and rollback records for each job folder, kept as change evidence
Knowledge transfer sessions with the operators who will run Airflow after handover
Decommissioning steps for the Control-M agents and plug-in once each wave is confirmed

How we support

Post-cutover review of failed, late and missed runs during an agreed stabilization period
Ongoing support, upgrades and testing available as a retainer after handover
Planned upgrade path for Airflow releases, including review of deprecated features before each move
Documentation kept current with the deployed DAGs, connections and configuration
Confirm with your auditors which evidence they require before scoping the controls work