If your batch schedule runs on SAP ECC, the platform underneath it is approaching a critical maintenance expiry date. Most guidance on the 2027 deadline treats the ERP migration as a whole — the data model, the custom code, the functional scope. This guide is narrower and more operational: it’s the plan for the team that owns the jobs. It walks through five steps to take your scheduling estate from an undocumented ECC dependency to a mapped, rationalized, portable workload that moves with you — whichever target you choose.

What the 2027 deadline changes

SAP has set firm dates for the end of mainstream maintenance on SAP ERP 6.0, the core of SAP Business Suite 7. For the enhancement packages most customers run today (EHP 6 through 8), mainstream maintenance ends on December 31, 2027, followed by optional extended maintenance through the end of 2030 at a premium on the maintenance base. The older EHP 0–5 versions already reached the end of mainstream maintenance on December 31, 2025, so those systems have moved into customer-specific maintenance — a phase whose reduced scope no longer includes legal and regulatory updates. Eligible large enterprises moving especially complex programs to cloud infrastructure have one further option: a private-edition transition via RISE that extends ECC operation for select customers, subject to SAP’s eligibility, architecture, commercial, and transition requirements.

Whatever path you choose, the scheduling estate needs an explicit plan: migrate to a supported target, redesign it for a new interface, or retire it. That work runs in parallel with the functional project — it has its own critical path, and the five steps below are that path.

Step 1 — Inventory: map every job before you move any

You cannot migrate what you haven’t mapped, and many ECC estates can’t produce a complete map on demand. Jobs scheduled directly by users in SM36, the SAP transaction for defining background jobs, remain visible in SAP but sit outside any central catalog, so the true scope of a migration is almost always larger than the documented one.

The first move is to bring every unmanaged job under central governance. Job extraction and mirroring pull user-scheduled SAP jobs into a single managed catalog, so the scope you plan against is real rather than assumed. This is the foundation for surfacing hidden dependencies before they become cutover issues.

Step 2 — Rationalize: shrink the estate before you carry it

A smaller system migrates faster. Years of accumulated housekeeping jobs, one-off reports, and superseded processes increase scheduling complexity. Unnecessary application data also increases the volume processed during archiving, system-copy, backup, and migration activities — delaying the S/4HANA roadmap by lengthening every technical step along the way. Reducing unnecessary data and obsolete scheduling logic can simplify the migration scope and reduce effort. Two actions slim the estate:

• Archive with SARA. Data archiving runs — write, delete, and store across archiving objects — shrink the underlying tables that the migration must process.
• Retire the housekeeping jobs running on habit. The central catalog from Step 1 finally lets you see the full set of recurring technical and administrative workloads across the estate. That visibility makes it easier to identify legacy schedules, duplicate processes, obsolete reports, monitoring tasks, and maintenance jobs that no longer provide business value. Review each workload deliberately and retire what is no longer needed before carrying it into the target environment. Our guide to background job scheduling at enterprise scale walks through the housekeeping workloads that typically accumulate and how teams bring them under governance.

Step 3 — Choose the target topology

“Migrating off ECC” is not one destination. The scheduling implications differ across four common landing zones, and the interface your jobs run through changes with each. Decide the target before you convert — it determines everything downstream. Most of these targets expose XBP, SAP’s certified external interface for background processing; one does not.

The through-line: the same SAP job type spans SAP R/3 and S/4HANA, so an S/4HANA move needs no new plugin and a RISE move is a minor configuration change. The one meaningful shift is GROW public cloud, where the scheduling surface is different. Our RISE, clean core, and GROW guide compares the four topologies in full, including agent placement, encryption, and the high-availability model for each.

Step 4 — Convert instead of rebuild

The instinct on a platform change is to rebuild the schedule by hand in the new environment. On an estate of any size, that’s slow, error-prone, and throws away the dependency logic you spent years getting right — and it isn’t necessary.

A conversion tool imports existing job definitions directly — jobs and calendars together — and produces an assessment report enumerating what it found, following a defined sequence: select the project, evaluate the data, run the conversion, validate the results, and load into the target. Converting rather than rebuilding preserves the cross-system logic — the dependencies that tie an SAP job to the file transfer, the bank, or the data platform waiting on it — instead of asking a person to reconstruct it from memory. Our SAP batch jobs and ECC-to-S/4HANA migration guide covers the conversion mechanics in full.

Step 5 — Simulate and protect the cutover

The last risk is cutover weekend itself, and it has two failure modes: a batch run that behaves differently on the new platform, and a job that writes into SAP while Basis work is mid-flight.

• Simulate the run. Forecast and What-If dry-run the batch schedule against the new environment before go-live, so you see the shape of the run — and where it breaks — before it’s carrying real data.
• Protect the window. A global stop, hold, and restart across the entire job estate ensures nothing posts into SAP during the upgrade, support-pack, and enhancement work a conversion weekend involves, then releases the estate cleanly once the window closes. Upgrade and support-pack projects are a well-known source of business-process disruption precisely because jobs keep firing into a system that isn’t ready for them; a global hold materially reduces the risk of that happening.

Build your timeline

The deadline is fixed, so plan from it. S/4HANA program duration varies widely by scope, landscape complexity, data strategy, custom code, deployment model, and rollout approach, so work backwards from the deadline and your organization’s validated program plan.

The arithmetic is tighter than it looks. As of August 2026, roughly seventeen months remain before mainstream maintenance ends for EHP 6–8 systems. Many S/4HANA programs run twelve to twenty-four months depending on scope, which means the shorter end of that range still fits inside the window and the longer end no longer does. A program that hasn’t started scoping is, in practice, already planning around extended maintenance as a bridge rather than around the 2027 date itself — and that bridge carries a premium on the maintenance base.

For the scheduling team, the sequence is the same regardless of target:

• Inventory — map and centralize every job
• Rationalize — archive and retire
• Choose topology — on-prem, RISE private, RISE + BTP, or GROW
• Convert and parallel-run — import, validate, run old and new side by side
• Cutover — simulate, protect the window, release

Steps one and two return value immediately — a mapped, slimmer estate is easier to run today, deadline or not — which is the argument for starting them now rather than waiting for the migration project to formally begin.

Frequently asked questions

What happens to my SAP batch jobs when ECC support ends in 2027?

The maintenance milestone does not automatically stop your SAP system or its batch jobs — they keep running as long as the system runs. What ends is SAP’s mainstream maintenance of the platform beneath them, on December 31, 2027 for EHP 6–8 systems; the older EHP 0–5 deadline passed at the end of 2025. The practical work is not to the jobs but to the estate: inventory every scheduled job, including the ones users created locally in SM36; archive and retire what no longer earns its place; then convert the definitions onto your chosen S/4HANA target rather than rebuilding them by hand, so the cross-system dependencies survive the move. That work runs in parallel with the functional S/4HANA project and is best started well ahead of the deadline.

Do I have to redefine every SAP job when I move to S/4HANA?

No — with one exception. The same SAP job type spans SAP R/3 and S/4HANA, so an S/4HANA move needs no new plugin, and a move to RISE with SAP is a minor configuration change. A conversion tool imports existing job definitions and calendars and reports on what it found, which replaces manual rebuilding for estates of any real size. The exception is GROW with SAP, public cloud, where the scheduling surface differs and the job-definition approach shifts accordingly.

Next steps

To see how a converted estate runs across SAP and non-SAP systems in practice, explore Control-M for SAP.

What the BTP Job Scheduling Service is

The SAP BTP Job Scheduling Service is the job scheduler built into SAP Business Technology Platform (BTP). It lets you define and run jobs (one-time or recurring) against applications and services deployed on BTP. Jobs can trigger application action endpoints over HTTP or launch Cloud Foundry tasks for long-running work, scheduled through a dashboard or programmatically through a representational state transfer (REST) application programming interface (API), with cron-style and human-readable recurrence patterns. The service runs in both the Cloud Foundry environment and the Kyma runtime, supports OAuth 2.0-secured execution and multitenant applications, and can send success or failure events to the SAP Alert Notification service.

It’s also worth placing the service among SAP’s other automation layers. SAP Build Process Automation handles workflow and robotic process automation on BTP, and SAP S/4HANA schedules its own application background jobs through its native framework. Each of these, including the BTP Job Scheduling Service, automates well within its own environment; none of them coordinates dependencies, timelines, or monitoring across environments. That boundary matters later in this article.

For teams building on BTP, the service handles the fundamentals well: it triggers application logic on a schedule, supports asynchronous execution, records run logs per job, and requires no additional infrastructure because it’s a native platform service. If you’re building a clean-core landscape (where custom logic moves out of the S/4HANA core and into BTP) the Job Scheduling Service is the default answer for “how do I run this extension on a schedule?”

That’s a genuinely useful capability, and for many workloads it’s all you need.

Where it fits well

The service is a strong fit when three things are true.

First, the work lives entirely on BTP: the job triggers a BTP-deployed application or Cloud Foundry task, and success or failure of that single unit is the whole story.

Second, the scheduling need is time-based: run at 2 a.m. daily, run every 15 minutes, run on the last day of the month.

Third, the team consuming the results is the team that owns the job: a developer or application owner who checks logs in the same dashboard where the job is defined.

Single-application scheduling, straightforward recurrence, and BTP-resident workloads: within that boundary, adding an external scheduler would be overhead, not value.

Where teams outgrow it

The limits appear when a scheduled job stops being an isolated task and becomes one step in a business process. At that point, the question changes from “Did this job run?” to “Did the whole process finish correctly, on time, and with enough visibility to recover and audit it?” Five patterns come up repeatedly.

Cross-system dependencies

A BTP job rarely exists alone. The extension it runs may depend on a batch job finishing in the S/4HANA core, which in turn feeds a load in a data warehouse and a file transfer to a bank or carrier. The BTP Job Scheduling Service schedules by time, not by dependency. It has no visibility into whether the upstream SAP job completed, or whether the downstream non-SAP step is ready to start. Teams often compensate by padding start times with buffer time, which is fragile: when the upstream job runs long, the downstream job can run against incomplete data.

Service level prediction

The service tells you whether a job ran and whether it failed, and it can notify you of either outcome. What it cannot do is warn you in advance that at the current pace, a chain of dependent work won’t finish before the business needs it at 8 a.m. There is no concept of a service level agreement (SLA) deadline attached to a process spanning multiple jobs, and no early warning when that process is trending late.

Restart-from-failure semantics

When a multi-step process fails partway through, the recovery question is not whether to rerun everything. It is where did the process fail, which completed steps can be trusted, and how to resume without duplicating work or corrupting downstream data. A time-based scheduler has no model of the end-to-end process, so it has no notion of where the failure occurred in the process.

Spawned-job awareness

SAP background processing frequently spawns child jobs. A parent job can report success while its children are still running or have failed. Any orchestration that treats the parent’s status as the whole truth will release downstream work too early.

Centralized audit and governance

Job logs live per job, per subaccount, in the BTP cockpit. Troubleshooting a cross-system failure means comparing run logs across separate consoles and tracing dependencies by hand. And when auditors ask who ran what, when, and with what outcome—across the S/4HANA core, BTP extensions, and the non-SAP systems in between—there is no single place to answer from.

None of these are defects. They’re the natural boundary of a platform-scoped scheduler being asked to do enterprise-scoped orchestration.

How Control-M relates rather than replaces

Control-M does not replace the BTP Job Scheduling Service; it orchestrates the jobs the service runs. Through native BTP integration, Control-M creates, triggers, and monitors BTP Scheduler jobs over the BTP API using secure connectivity. Those jobs can be orchestrated alongside S/4HANA jobs running through SAP’s certified External Interface for Background Processing (XBP) and connected non-SAP processes, including data loads, file transfers, and cloud service calls, all in a single workflow. (Control-M is SAP-certified and listed on the SAP Store; the core integration runs through SAP’s own certified interfaces.)

This matters for clean core specifically: as custom logic moves out of the core and into BTP, the process doesn’t get simpler—it gets more distributed. Control-M orchestrates the BTP jobs alongside the core, so a business process that spans both remains one visible, governable flow.

The integration is bidirectional. REST and webhook triggers let Control-M react to SAP job completions in near real time. The downstream step starts the moment the upstream job finishes, rather than when a polling interval happens to notice. That’s the concrete difference between event-driven orchestration and buffer-time scheduling. It also answers the spawned-job problem directly: on the SAP core side, Control-M detects and monitors the full parent-child job tree and starts successors only when every predecessor completes—removing the manual buffer-time padding that time-based dependencies force on teams.

The result: keep using the BTP Job Scheduling Service for what it’s good at, and gain the cross-system dependencies, SLA management, restart semantics, and centralized audit trail it was never designed to provide.

GROW with SAP and Public Cloud

In GROW with SAP, the public cloud edition of S/4HANA, the scheduling surface changes because there is no classic XBP path into the core. Instead, the BTP Scheduler and SAP’s External Scheduler API, communication scenario SAP_COM_0948, become the scheduling interfaces. Control-M connects to Public Cloud environments through an OData/REST connector that uses that External Scheduler API, secured with OAuth 2.0 and Transport Layer Security (TLS). The result is an API-based orchestration model that extends to GROW landscapes without requiring a compromise architecture—the same orchestration layer reaches on-premises, RISE, and GROW deployments without a different approach for each.

How to decide when scheduling becomes orchestration

The question is not which tool is better. It’s where a particular job sits.

Use the BTP Job Scheduling Service when the job is BTP-local, runs on a clock, and answers to the team that owns the application. Move to enterprise orchestration when the job starts carrying weight beyond itself: an upstream step it has to wait for, a downstream system it has to release work to, a business deadline someone is holding it to, a recovery path that has to resume rather than restart, or an audit trail that has to account for it alongside everything else.

Few landscapes stay on one side of that line. Most start on the first and arrive at the second as extensions multiply and a single business process spreads across more systems. The useful exercise isn’t choosing once. It’s knowing which side each job is on today.

Frequently asked questions

Is SAP’s BTP Job Scheduling service enough, or will we outgrow it?

The SAP BTP Job Scheduling Service is sufficient when jobs run entirely within BTP, depend only on time-based schedules, and can be monitored individually by the teams that own them. Organizations typically outgrow it when scheduled jobs become steps in larger business processes, where a BTP job depends on an S/4HANA core job completing, feeds a non-SAP system, carries a business deadline, or must be auditable alongside the rest of the job estate. At that point the need shifts from scheduling to orchestration: cross-system dependencies, SLA prediction, restart from the point of failure, and a centralized audit trail. Control-M addresses this by orchestrating BTP Scheduler jobs through the BTP API within the same dependency graph as SAP core jobs and non-SAP workloads, so the platform scheduler keeps its role while the end-to-end process gains visibility and control.

Does Control-M replace SAP BTP Job Scheduling Service?

No. Control-M does not replace the BTP Job Scheduling Service; it orchestrates the jobs the service runs. The BTP scheduler stays responsible for triggering BTP-local jobs. What Control-M adds is the context around them: the BTP job can wait on an S/4HANA core job, release downstream non-SAP work the moment it finishes, count toward an SLA deadline, and appear in a central audit trail, all without changing what it is inside BTP.

How does Control-M help with clean core and BTP extensions?

Clean core moves custom logic out of the S/4HANA core and into BTP. That’s the right architectural direction, but it doesn’t make the business process simpler; it makes it more distributed. Control-M orchestrates the BTP Scheduler jobs alongside the SAP core jobs and the non-SAP steps around them, so the process stays visible, dependency-aware, and governed from end to end. The extension stays cleanly decoupled from the core, and the flow that runs through both stays one thing you can see and manage.

Next steps

If you’re mapping where your BTP jobs sit inside larger business processes, the place to start is seeing how BTP Scheduler jobs join a cross-system dependency graph in practice. Explore Control-M for SAP or access the Control-M demo library.

When you evaluate a workload automation or job-scheduling tool for SAP, you run into a wall of credentials: SAP-certified, SAP Store listed, SAP partner, SAP Endorsed App. They sound like rungs on one ladder, and vendors tend to present them that way. They aren’t quite. Each represents something different, and only some of them affect whether a tool can schedule and monitor jobs in your SAP landscape. This guide defines each term plainly, explains what each certification verifies, and gives you a short checklist that tells you more than any badge. 

SAP credentials 

Four terms come up most often, and it helps to separate them: 

• SAP-certified integration: SAP has tested the product against a specific SAP interface and confirmed it works as documented. It’s tied to that interface—for schedulers, the background-processing interface—not to the whole product. 

• SAP Store listing: the product has a validated listing in SAP’s marketplace. A listing signals a real, purchasable integration and typically follows certification. 

• SAP partner: the vendor has a commercial relationship with SAP to build, sell, or service. This is about the business relationship, not a technical test. 

• SAP Endorsed App: SAP’s premium tier—a distinct, curated category of solutions that SAP has validated beyond baseline certification and actively co-markets. 

Partner status and certification usually come before a Store listing or endorsement, so the idea of a “ladder” is loose. Treat these as distinct signals rather than strict steps. 

What certification tests

For a scheduler, the credential that governs whether it can drive SAP background jobs is certification on SAP’s External Interface for Background Processing—XBP, designated BC-XBP in SAP’s certification catalog. SAP exposes XBP to certified vendors through its Computing Center Management System (CCMS). A scheduler certified on XBP can schedule, start, and monitor classic ABAP background jobs from outside SAP NetWeaver, and certification is granted against a defined scenario: background-processing job scheduling for SAP S/4HANA. 

Certification comes in versions, and the version tells you what was tested. XBP 2.0 is the mandatory baseline, covering the core job lifecycle an external scheduler needs—defining and scheduling a job, starting it, monitoring it through to completion or failure, and retrieving job logs and spool output. XBP 3.0 layers on top of that baseline and adds the job-interception model, which lets an external tool govern jobs that users scheduled directly inside SAP: interception rules hold those jobs so the external scheduler can attach conditions and dependencies, and extraction mirrors otherwise unmanaged SAP jobs into central governance. 

So “certified on XBP 3.0” is a more precise and more useful statement than “SAP-certified” alone—it tells you which interface version and which capabilities were tested. 

Two things certification does not do: it doesn’t move job execution outside SAP’s control, and it doesn’t change who is allowed to run a job. That leads to the credential everyone asks about: endorsement. 

What endorsement adds—and doesn’t

SAP Endorsed App is a real distinction and worth understanding accurately. It is SAP’s premium validation tier: beyond baseline certification, SAP applies added security review, deeper testing, and benchmark measurement, and promotes the solution through its own go-to-market. As of 2026, RunMyJobs by Redwood is the only workload automation platform that holds SAP Endorsed App status. 

Here is the part that matters for a technical evaluation: endorsement is a premium-certification and go-to-market designation, not a technical prerequisite for scheduling jobs in a RISE with SAP environment. XBP is exposed to any certified vendor through CCMS, and job execution is bounded by SAP’s own authorization model regardless of a vendor’s tier—only a user with the correct SAP roles can run or monitor a job, managed through transaction codes PFCG and SU01 and inheriting SAP Governance, Risk, and Compliance (GRC) controls. Certification for integration with RISE with SAP is held by multiple vendors, not only endorsed ones. A certified scheduler runs jobs under SAP’s own security, as if they were managed inside SAP; endorsement adds validation and go-to-market weight on top of that, not additional capability. 

Where Control-M stands

Stated plainly, Control-M is SAP-certified on XBP 3.0, is listed on the SAP Store, and carries the “SAP Certified — Integration with RISE with SAP S/4HANA Cloud” designation. It is fully compatible with RISE with SAP and works through SAP-certified interfaces with no changes to existing SAP job logic. Control-M is an SAP-certified application and data workflow orchestration platform; it is not an SAP Endorsed App. Execution inherits SAP’s roles and GRC governance through XBP, so orchestration stays audit-compliant under SAP’s own security model. 

Five questions worth more than a badge

When you compare schedulers for SAP, these tell you more than tier: 

• Which interface does it use? For classic background processing, look for certified XBP over Remote Function Call (RFC), secured with Secure Network Communications (SNC). 

• Which RISE topologies does it support? XBP stays exposed under RISE Private Cloud, secured with SNC, and RISE with SAP Business Technology Platform (BTP) adds the platform’s cloud services alongside the certified core. 

• What’s the path for GROW with SAP? S/4HANA Public Cloud has no classic XBP, so ask which interface the tool uses there—SAP’s External Scheduler API, communication scenario SAP_COM_0948, reached over OData/REST and secured with OAuth 2.0 and Transport Layer Security (TLS). XBP certification alone does not answer this. 

• Does execution inherit SAP’s authorization model? Jobs should run under SAP roles (PFCG and SU01) and inherit GRC governance, not under a separate credential store outside SAP’s control. 

• Is there conversion tooling? Moving an existing estate (from another scheduler, or from ECC to S/4HANA) is far cheaper when the tool imports existing job definitions instead of requiring a manual rebuild. 

Frequently asked questions

Which workload automation tools are SAP Endorsed Apps, and what does that certification verify?

As of 2026, RunMyJobs by Redwood is the only workload automation platform that holds SAP Endorsed App status. SAP Endorsed Apps are a distinct, premium-certified category in SAP’s partner ecosystem: beyond baseline certification, SAP applies added security review, deeper testing, and benchmark measurement, and actively co-markets the solution. It is a strong validation and go-to-market signal, but it is not a technical prerequisite for driving SAP background jobs. SAP’s certified background-processing interface—the External Interface for Background Processing, or XBP—is exposed to any certified vendor through the Computing Center Management System (CCMS), and job execution is always bounded by SAP’s own authorization model (transaction codes PFCG and SU01, inheriting SAP Governance, Risk, and Compliance controls) regardless of a vendor’s tier. Several schedulers, including Control-M, hold SAP certification for integration with RISE with SAP; Control-M is SAP-certified on XBP 3.0, listed on the SAP Store, and fully compatible with RISE with SAP, though it is not an Endorsed App. When comparing tools, the more decisive questions are which SAP interface each one is certified on, which RISE and GROW topologies it supports, and whether job execution inherits SAP’s roles and GRC governance. 

Next steps

If you’re comparing schedulers on what their credentials actually verify, the next step is checking each one against the interface it’s certified on. Explore Control-M for SAP or access the Control-M demo library.

What SAP BW process chains are

An SAP Business Warehouse (BW) process chain is a sequence of automated steps — data loads, transformations, activations, and housekeeping tasks — defined and maintained in transaction RSPC. A chain strings together processes such as InfoPackage loads, data transfer processes (DTPs), and attribute change runs so that data moves from source system to report-ready InfoProvider in a defined, repeatable order. 

Native monitoring is where the limits start. When a chain runs, what SM37, the SAP job overview transaction, shows is BI_PROCESS_TRIGGER — the job that starts the chain, not the steps inside it. RSPCM adds chain-level status monitoring, but it remains a BW-side view: it sees chains, not the dependencies outside BW such as upstream extracts, downstream reports, or non-SAP systems. For a single BW system with self-contained loads, that can be workable. For an analytics estate that spans systems, it leaves gaps. 

The silent-failure problem

BW pulls data continuously, from SAP and non-SAP sources alike. That constant motion is what makes failures expensive: if a load fails silently at 2 a.m., the morning numbers are wrong, and nobody knows. 

Native tools tell you what happened only after you go looking. A step fails, the chain stalls or limps forward, and the first signal is often a business user questioning a report. Worse, the dependencies that matter most — the file that must land from an external system before the chain starts, the downstream refresh that must wait for the load — sit outside BW’s visibility entirely. RSPC can sequence what’s inside the chain; it cannot see what’s around it. 

What full orchestration covers

Bringing process chains under a workload orchestration platform such as Control-M closes those gaps at the chain level first. All process chains can be scheduled regardless of whether the chain is event-based, a meta chain, or direct scheduling — with complete visibility and control. Individual InfoPackages and DTPs can be orchestrated the same way, so partial loads and targeted refreshes follow the same governance as full chains. 

Failure handling changes character, too. Instead of diagnosing a stalled chain step by step, the rerun option defined on the job itself — restart from point of failure — can resume the chain at the failed step rather than reprocessing everything before it. And downstream reporting or BW broadcasting can be sequenced after successful BW completion, so reports distribute only after the data behind them has arrived. 

The chain doesn’t end at BW

Modern analytics pipelines rarely stop at the BW boundary, and orchestration shouldn’t either. On the SAP side, the same flow can include SAP HANA database jobs such as SQL procedures, queries, and data movements via the certified HANA plugin, plus SAP Datasphere task chains and SAP Analytics Cloud steps. 

The non-SAP legs join the same dependency graph: Snowflake and Databricks loads, Talend jobs, and Amazon Web Services (AWS) steps including Lambda, Step Functions, and QuickSight. The result is one picture of the pipeline, where the BW chain becomes a segment in an end-to-end flow rather than an island monitored on its own terms. 

Morning readiness as an SLA

The real question for a BW estate isn’t “did the chain finish?” It’s “will the numbers be right, on time, tomorrow morning?” That’s a service-level agreement (SLA) question, and it’s answerable before the deadline, not after. 

SLA jobs attached to the analytics service predict a miss before the first meeting, based on where the flow stands against its deadline — giving operations time to intervene while intervention still helps. Data Assurance adds the second half: validating the data itself before anyone reports on it, so “the chain ran” and “the numbers are trustworthy” stop being separate conversations. 

Frequently asked questions

How do we handle SAP BW process chain (RSPC) failures and cross-system dependencies? 

Native BW tools make cross-system troubleshooting harder. SM37 displays the BI_PROCESS_TRIGGER job, while RSPCM monitors BW process chains without visibility into surrounding systems. A workload orchestration platform addresses both problems: it schedules and monitors every chain type—event-based, meta chain, and direct scheduling—plus individual InfoPackages and DTPs, can restart failed chains from the point of failure rather than rerunning them entirely, and places BW chains in the same dependency graph as the HANA, Datasphere, SAP Analytics Cloud, and non-SAP steps they depend on, including Snowflake, Databricks, Talend, and AWS. Cross-system dependencies are enforced rather than assumed, and failures surface before business users see wrong numbers. 

What is the difference between RSPC, RSPCM, and SM37 for SAP BW process chain monitoring? 

RSPC is where SAP BW process chains are built, scheduled, and maintained. RSPCM provides a BW-focused monitor for process-chain status. SM37 shows the underlying SAP background jobs, which commonly appear as BI_PROCESS_TRIGGER for BW process chains. Together, these tools help teams manage BW execution, but they do not provide a single end-to-end view of upstream files, downstream reporting, cloud services, or non-SAP dependencies. That is where workload orchestration adds value: it connects the BW chain to the full business workflow. 

How can SAP BW process chains be orchestrated with cloud data platforms and downstream analytics? 

SAP BW process chains can be orchestrated as part of a broader analytics workflow by connecting the chain to the systems that must run before and after it. For example, orchestration can coordinate external file arrivals, SAP HANA or SAP Datasphere tasks, data warehouse loads, ETL jobs, and downstream reporting refreshes. This turns the BW process chain from an isolated technical schedule into one step in an end-to-end data pipeline, helping teams manage dependencies, detect failures earlier, and meet reporting deadlines. 

Next steps 

To see how BW chains run under end-to-end orchestration, explore Control-M for SAP. For related reading, see our overview of orchestrating data pipelines.

If your organization schedules SAP jobs through SAP Central Process Scheduling by Redwood, the ground has shifted. The product line CPS belongs to has reached end of support, which means the software running your business-critical batch processing no longer receives updates or fixes. This guide explains what that means, why years of accumulated scheduling logic cannot simply be copied to a new tool, and how a conversion-based migration moves it onto supported software with its cross-system logic intact. 

What SAP CPS is

SAP Central Process Scheduling by Redwood (SAP CPS) is the central scheduling tool SAP offered on top of the SAP NetWeaver platform. Where the built-in transactions SM36 and SM37 schedule and monitor jobs only on the local system, CPS was designed to run and monitor time- and event-driven jobs and job chains across an entire SAP landscape. It connects to SAP systems through the External Interface for Background Processing (XBP) and ships in two editions: a free-of-charge license for SAP-only scheduling and a chargeable license that adds non-SAP processes. Co-developed by SAP and Redwood Software, it was, for years, SAP’s recommended step up from local background processing. 

CPS is a legacy product. Its last major version, CPS 8.0, shipped in 2010, and SAP’s own guidance points customers to its successor, SAP Business Process Automation by Redwood (SAP BPA). 

Its support status today

The support milestone that matters is BPA’s, not CPS’s. As part of SAP’s strategic focus on S/4HANA Cloud, SAP ended mainstream maintenance on December 31, 2024 for many applications built on the NetWeaver Java stack, SAP BPA among them, which means no further upgrades or new features are released. Well before that date, SAP’s guidance had already been pointing customers toward its successor products. 

For teams still running CPS or BPA, the practical position is straightforward: business-critical batch processing now depends on software that no longer receives updates. The vendor’s own path forward is a move to its SaaS scheduler, RunMyJobs by Redwood, on a subscription, execution-based pricing model. That is one option. It is not the only one, and the interface CPS was built on gives you a second. 

What a CPS configuration contains

A CPS configuration is rarely just a list of jobs. Over years of operation, it accumulates job definitions with their program variants and parameters, calendars and scheduling rules, cross-system job chains, and the dependencies between them, much of it undocumented and held in the heads of the people who built it. That accumulated logic, not the raw job count, is what makes migration hard. 

Why lift-and-shift falls short

Because the value is in the dependencies, a straight lift-and-shift rarely works. Recreating hundreds or thousands of job definitions and chains by hand is slow, error-prone, and loses exactly the cross-system logic that matters most. The goal of a migration is not to copy jobs one by one; it is to bring everything under new control with its structure intact. 

Convert instead of rebuild

Control-M approaches a CPS migration as a conversion, not a rebuild. The Control-M Conversion Tool imports existing SAP job definitions, jobs and calendars together, and produces an assessment report that enumerates what is already there, so the scope is measured rather than guessed. The workflow runs in defined stages: select the project, evaluate the data, run the conversion, validate the results, and load the converted jobs into Control-M. Manual re-entry, and the transcription errors that come with it, drops out of the process. 

Where converted jobs land

The landing zone is the same interface family CPS used. Control-M connects to SAP through the certified XBP interface, so converted jobs arrive in an environment built on the connection they already ran on. Once there, they gain capabilities native background scheduling could not offer at enterprise scale: interception of jobs scheduled directly by users, detection of the full parent-child job tree so successors start only when every child process has finished, and service level agreement (SLA) management that flags a missed deadline before it happens. 

Simulate before you cut over

A scheduler migration is only as safe as the cutover. Before go-live, Control-M’s Forecast and What-If simulate the batch run against the converted schedule, so you can see how it behaves without touching production. A parallel-run period, old and new scheduling side by side, lets you confirm results match before the old system is retired. For the cutover weekend itself, maintenance-window control can globally stop, hold, and restart every scheduled job, so nothing writes into SAP mid-transition. 

Frequently asked questions

Is SAP CPS still supported? 

SAP CPS is a legacy product, superseded by SAP Business Process Automation by Redwood (SAP BPA). SAP ended mainstream maintenance for SAP BPA on December 31, 2024 as part of its move away from the NetWeaver Java stack, and no further upgrades are issued for it. Organizations still running CPS or BPA are, in practice, operating on software that is no longer maintained, and should plan a migration. 

What are the options for replacing SAP CPS? 

The vendor’s own path is RunMyJobs by Redwood, a subscription SaaS scheduler. Enterprises also have the option of moving to an established workload automation platform such as Control-M, which connects through the same certified XBP interface CPS used and converts existing job definitions rather than requiring a manual rebuild. 

Do existing jobs have to be rebuilt by hand? 

No. The Control-M Conversion Tool imports existing SAP jobs and calendars and produces an assessment report of what is already scheduled, so the migration converts what already exists instead of recreating it from scratch. 

Next steps

If you’re planning a move off CPS, the next step is seeing how converted jobs run under end-to-end orchestration. Explore Control-M for SAP or access the Control-M demo library. 

What SM36 and SM37 do

SAP ships with a complete, native toolset for background processing. SM36 is where a job is defined: its steps, program variants, start conditions, and recurrence. SM37 is the job overview, where administrators monitor, analyze, and troubleshoot runs. Two companion transactions manage the events that trigger them: SM62 and SM64 handle event definition and administration. 

These transactions are well designed for the work they were built for, and that work is substantial. A team can schedule an ABAP program to run nightly, chain steps in sequence, and review the log the next morning — reliably, with no additional software and no additional interface to learn. For single-system batch processing, native SAP tooling is the right answer and remains so. 

What changes is the shape of the work. As a business grows, a background job stops being a standalone task and becomes one step in a business process that spans SAP and the systems around it: carriers, banks, data platforms, partner networks. The transaction still runs the job correctly. What the business now needs to see is whether the process completed. That is a different question, and it is where an orchestration layer extends what SAP already provides rather than replacing it. 

Four places make that shift concrete. 

1. Dependency logic: from linear chains to process flows

SM36 expresses mainly sequential dependencies: run step B after step A. That models a linear chain accurately. Enterprise business processes rarely run in a straight line — they fan out into parallel branches that rejoin, and they carry logical dependencies where a successor runs only if a condition is met. Native scheduling has no integrated way to express this and, just as importantly, no way to display it. Without a flowchart of the run, the shape of the process lives in documentation and in the knowledge of the people who built it. 

An orchestration layer models the whole process as a visual flow, with sequential, parallel, and logical dependencies in one view. The dependency graph becomes something a team can read, hand off, and audit rather than reconstruct. 

2. Spawned and child jobs: seeing thewhole processtree

Many SAP programs spawn child jobs at runtime. SM36 and SM37 have no reliable detection of these spawned processes, so a parent job can report success while its children are still running. The available workaround is to pad the schedule with buffer time and let the children finish before the next step begins. That buffer is idle runtime on a good night and a broken dependency on a bad one. 

Child-tree detection removes the estimate. When the full parent-child tree is tracked, the next step in the process starts the moment every predecessor child completes — not on a timer, and not on an assumption. 

3. Monitoring across the estate: from after-the-fact toahead-of-time

SM37 reports on the system it runs in, which is exactly its design. At enterprise scale, that means an administrator opens SM37 in each system and reads logs after the run. Failures and delays surface when someone looks; a process can hang in a yellow state without a timely signal; and there is no forward prediction that a run is trending toward a missed deadline. Processes that cross system boundaries—an SAP run feeding a carrier, a bank, or a business intelligence platform—sit outside SM37’s field of view, because SM37 sees SAP. 

This is where a service level agreement (SLA) becomes the unit of management. Central orchestration watches the whole estate from one place, alerts on a stalled process before it cascades—including when background work is starved because dialog processes are consumed with no free background process—and predicts an SLA breach early enough to act on it.

4. Governance at scale: bringing every process under one view

Anything scheduled directly in SM36 is, by default, outside central control. Individual teams create jobs on individual systems, and no single view holds the complete picture of what runs where. Two mechanisms close that distance. Interception, using SAP’s certified External Interface for Background Processing (XBP) 3.0, holds user-scheduled jobs so conditions and dependencies can be applied before they run. Extraction mirrors those unmanaged jobs into central governance, so the real estate is visible and managed rather than assumed. 

The recurring housekeeping layer

Much of what keeps an SAP landscape healthy is recurring maintenance that runs through these same transactions and gets watched by hand. The inventory below is representative rather than exhaustive, and it is the work that scales least gracefully as landscapes grow. 

Every row is work someone monitors, escalates, and restarts by hand. Consolidating it under one control point is the difference between a team that babysits background processing and one that manages the business process by exception. 

Frequently asked questions

What are the main limitations of SM36 and SM37 at enterprise scale? 

SM36 and SM37 are well suited to defining and monitoring background jobs within a single SAP system, and they do that job reliably. Organizations reach past them when those jobs become steps in larger business processes that span systems. Four things drive the shift: SM36 expresses mainly sequential dependencies, with no visual flow and no support for parallel or logical branches; it cannot reliably detect spawned child jobs, so teams pad schedules with buffer time; SM37 monitoring is system-by-system and after the fact, with no forward SLA prediction and no visibility into non-SAP steps; and anything scheduled directly in SM36 sits outside central governance. Closing that distance calls for an orchestration layer that models the full process, detects the parent-child job tree, monitors the estate against SLAs from one point of control, and brings unmanaged jobs under governance through interception and extraction. 

Can SAP background jobs be scheduled across SAP and non-SAP systems? 

Not natively. SM36 schedules and SM37 monitors work inside the SAP system where they run, so a process step that lands in a carrier portal, a bank file transfer, a data platform, or a partner system is invisible to them; the SAP job reports success, and what happens next is tracked somewhere else, usually by a person. An orchestration layer that integrates through SAP’s certified XBP interface places SAP and non-SAP steps in a single dependency graph, so the end-to-end business process is defined, monitored, and recovered as one unit instead of a set of handoffs. 

How do you monitor SAP background processing across multiple systems from one place? 

SM37 gives a per-system view, so multi-system landscapes mean opening SM37 in each system and reading logs after the run, with CCMS (RZ20) alerts sitting in their own per-system silos. A central orchestration layer aggregates the estate into one point of control: active status across every connected system, alerting on stalled or starved processes as they happen, SLA prediction that flags a run trending toward a missed deadline, and captured job logs and spool output routed to the team that owns the process. The practical shift is from reading logs after a failure to being told before a deadline is missed. 

Next steps

If your background processing has outgrown a single system, the next step is seeing how SAP and non-SAP jobs sit in one dependency graph. Explore Control-M for SAP or access the Control-M demo library. 

Enterprise Automation has entered the AI era

For decades, automation focused on making predictable processes faster and more reliable. That remains essential, but it is no longer enough.

Enterprises must now orchestrate applications, data, and AI across increasingly complex hybrid environments, without compromising security, resilience, or human control.
Against this backdrop, I am proud that BMC has been named a Leader in the 2026 Gartner^® Magic Quadrant^™ for Service Orchestration and Automation Platforms for the third consecutive year.

More significant than recognition alone is our year-over-year progress. BMC advanced meaningfully in both Ability to Execute and Completeness of Vision. We believe this reflects the strength of our strategy, disciplined execution, and sustained investment in Control-M.

It also demonstrates that BMC is not simply responding to the changing technology landscape. We are helping shape it, building the orchestration capabilities enterprises will need as AI moves from experimentation into production.

One platform across applications, data, and AI

The world’s largest organizations depend on thousands of interconnected workflows spanning mainframes, distributed systems, cloud services, enterprise applications, data pipelines, AI models, and autonomous agents.

The challenge is no longer automating an isolated task or scheduling a single workload. Enterprises must orchestrate the entire flow of work and data with visibility, speed, and control.

Control-M provides that foundation.

It spans mainframe, distributed, cloud-native, AI/ML, and data-pipeline environments. Customers can deploy it as SaaS, in their own cloud environments, or on premises. That flexibility matters because global enterprises are not moving uniformly toward a single operating model. They must modernize without disrupting the critical systems on which their businesses depend.

But the next phase of orchestration requires us to go further.

A production-grade control plane for agentic AI

AI agents introduce a fundamentally different form of automation.

Traditional automation follows predetermined rules. AI agents can interpret information,make decisions, and initiate actions dynamically. That creates enormous opportunity, but also new risks. Enterprises need to understand what an agent is doing, which data it is using, which systems it can access, and when human approval is required.

Gartner identified BMC’s agentic AI innovation as a strength. Control-M is being positioned as a production-grade control plane through which AI agents and copilots can discover and execute enterprise automation tasks within defined access and governance constraints.

Our expanding investment includes Jett AI Advisor, native Model Context Protocol server capabilities, and deeper partnerships with AWS and SAP.

Our intent is clear: enable enterprises to put AI agents to work within their most important operations without surrendering control.

Through Control-M, agentic AI and large language model tasks can be executed as observable, governed jobs. Role-based access controls define authority. Audit trails create accountability. Service-level requirements protect operational performance. Human-in the-loop approvals provide oversight before consequential actions occur.

For enterprise AI, intelligence alone is not enough. Execution must also be secure, observable, and accountable.

Protecting the data that powers AI

Every AI outcome depends on the quality of the data behind it.

Gartner cited Control-M’s data-pipeline assurance as a strength. Control-M embeds data quality validation directly into the execution layer rather than relying on custom scripts or separate testing tools.

Customers can establish validation rules, apply severity-based gates, and maintain dataset-level visibility within the orchestration platform. If data fails to meet the required standard, Control-M can prevent it from progressing into downstream workflows, analytics, or AI/ML models.

This turns data quality from a retrospective exercise into active operational control.

As enterprises expand their use of AI, data orchestration must address not only whether a pipeline ran, but whether its output can be trusted.

Governance designed into the workflow

Gartner also recognized BMC’s intelligent automation governance.

Control-M routes AI interactions through its native MCP server and runtime gateway, applying the same enterprise controls used for other mission-critical workflows.

This enables organizations to execute nondeterministic AI and LLM tasks within observable orchestration jobs, with access controls, auditability, security guardrails, service levels, and human approvals before state-changing actions occur.

Governance should not be added after AI has been deployed. It must be embedded in how AI work is initiated, executed, and monitored.

That is the role we believe Control-M can play: connecting the flexibility of AI with the operational discipline the enterprise requires.

Customer trust remains the most important measure

Recognition from Gartner is important. Customer trust matters even more.

More than 110 customers shared their experiences through Gartner Peer Insights^™, awarding Control-M an average rating of 4.5 out of 5 stars—with more than twice the number of reviews received by our closest competitor.

To every customer who provided a review: thank you.

We never take your trust for granted. Your feedback tells us where we are delivering value, where we must improve, and where we should invest next. It pushes us to maintain the reliability customers expect from Control-M while accelerating the innovation they need from BMC.

Our customers consistently tell us they want greater simplicity without less control, faster innovation without greater risk, and AI that can operate confidently at enterprise scale.

Those priorities continue to shape our roadmap.

Progress built by our people

Our year-over-year progress and continued recognition as a Leader belong to our people across BMC.

They reflect the commitment and execution of our teams in Product, Engineering, Sales, Marketing, Customer Success, Support, and Operations.

Building mission-critical enterprise software takes more than a strong product. It requires disciplined execution across the entire customer experience and a determination to keep improving.

I am grateful to our teams for the standards they set and the accountability they bring to serving our customers every day.

What comes next

We are proud of our progress, but the more important question is what our customers will need next.

Applications, data, and AI are converging into a single operational environment. Enterprises will need a control plane capable of coordinating that environment while preserving visibility, governance, and human accountability.

Over the coming months, we will introduce the next wave of Control-M innovation—expanding how enterprises orchestrate data pipelines, operationalize AI agents, and govern increasingly dynamic workflows at scale.

Our position in the 2026 Magic Quadrant reflects the progress we have made. Our focus now is to deliver what our customers will need next.

Read the 2026 Gartner^® Magic Quadrant^™ for Service Orchestration and Automation Platforms

BMC has been recognized, for the third consecutive year, as a Leader in the 2026 Gartner® Magic Quadrant™ for Service Orchestration and Automation Platforms (SOAPs). We believe this recognition reflects our continued commitment to helping organizations orchestrate end-to-end business services across increasingly complex hybrid environments, while advancing the future of enterprise orchestration for AI, event-driven operations, and data-driven business processes.

What drives Control-M’s position in the SOAPs market

Our strategy is focused on helping customers orchestrate end-to-end business workflows across the enterprise.

As organizations modernize, business services increasingly span applications, data platforms, cloud services, file transfers, AI technologies, and core systems. The challenge is no longer simply automating tasks. It is coordinating the end-to-end flow of work across these technologies while maintaining visibility, governance, reliability, and control.

We believe Control-M’s position in the market reflects our focus on helping enterprises manage this complexity through a unified orchestration platform. By connecting workflows across cloud, SaaS, data, Agentic AI, distributed, and mainframe environments, Control-M helps organizations orchestrate business outcomes rather than isolated technology activities.

Customers can modernize at their own pace through a hybrid operating model that combines SaaS innovation with self-hosted deployment flexibility when governance, compliance, data residency, or operational requirements demand it.

How Control-M continued to advance in 2026

Over the past year, Control-M introduced innovations designed to help customers orchestrate increasingly dynamic, data-driven, and AI-enabled business services.

Our AI strategy is focused on more than adding AI assistants. We have two major focus areas in our AI strategy:

• Embedding Agentic AI across the workflow lifecycle to help teams design, understand, operate, and optimize, the workflows that power critical business workflows.
• Orchestrating and governing AI agents safely as they become part of business workflows across the enterprise.

New capabilities such as AI Workflow Creator help users translate business intent into operational workflows, while Execution Insights, workflow explainability, and agentic root cause analysis help teams better understand workflow behavior, accelerate troubleshooting, and uncover optimization opportunities. Together, these innovations help organizations operate increasingly complex business services more efficiently and with greater confidence.

As organizations move beyond AI experimentation and begin operationalizing AI at scale, they face a different challenge: orchestrating AI agents alongside applications, data pipelines, and core business workflows. To address this need, Control-M expanded support for AI-agents through integrations with technologies such as CrewAI, LangGraph, and Snowflake Cortex, helping organizations govern, monitor, and orchestrate AI-Agents as part of end-to-end enterprise workflows with policies and guardrails

Control-M also expanded support for event-driven orchestration, enabling workflows to respond dynamically to business and technology events. As organizations move beyond static schedules toward more responsive operating models, automation increasingly depends on timely and trustworthy data. To support this shift, we introduced Control-M Data Assurance, which helps organizations validate data quality as part of operational workflows. By embedding data validation directly within workflow orchestration, Control-M helps customers ensure that the events, decisions, and processes driving business outcomes are based on trusted data, reducing the risk of issues propagating downstream.

Looking Ahead

When we look across industries today, it’s clear that the pace of change continues to accelerate. New business models are emerging, existing industries are being reshaped, and AI is becoming part of everyday operations. Behind all of this is a growing web of applications, data, infrastructure, and intelligent agents that organizations must connect and manage.

That complexity is what makes automation and orchestration more challenging than ever. It’s also why our mission remains as relevant today as it was when Control-M was first introduced: helping customers bring order to complexity and turn it into business outcomes. Our focus has always been on simplifying how work gets done across the enterprise.

As organizations move AI agents from experimentation into production, trust becomes just as important as innovation. Before you put agents into production, you need technology you can trust and a partner with a proven track record of delivering business-critical outcomes across industries. The same trust that thousands of customers around the world have placed in BMC to run and orchestrate some of their most important business services will help them operationalize AI with confidence. When organizations consider what’s next, they should start with the foundation for enterprise AI. BMC First.

Read the full Gartner report to learn why BMC was recognized as a Leader for its Control-M solution in the 2026 Gartner Magic Quadrant for Service Orchestration and Automation Platforms and explore the latest innovations shaping the future of enterprise orchestration.

Gartner, Magic Quadrant for Service Orchestration and Automation Platforms, Hassan Ennaciri, Daniel Betts, Chris Saunderson, 5 August 2026

“Gartner, Magic Quadrant for Service Orchestration and Automation Platforms, Hassan Ennaciri, Daniel Betts, Chris Saunderson, 5 August 2026

Gartner and Magic Quadrant are trademarks of Gartner, Inc. and/or its affiliates.

Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.”

Learn how Control-M orchestrates a production-grade AI governance pipeline with Amazon Bedrock, Snowflake, DataBrew, SES, and QuickSight — reliably.

Getting an AI agent to produce a compelling response in a playground is straightforward. Getting that same agent to produce reliable, trustworthy output every quarter – on fresh data, in the right sequence, with results delivered to the right people and systems – is an entirely different problem.

The gap between a demo and a production AI workflow usually is not the agent itself. It is everything around it, such as data validation, orchestration, synchronization, and operational visibility.

Agents require validated upstream data before they reason over it. A hallucination caused by a stale governance snapshot or a missing risk indicator is not simply a model problem — it is a pipeline reliability problem. At the same time, downstream systems must act on the agent’s output correctly: reports need to be generated, dashboards refreshed, recommendations archived, and governance decisions persisted for auditability.

All of this must happen in the correct sequence, with operational visibility, dependency management, and failure handling across the entire workflow.

This is the orchestration problem. It is also one of the biggest challenges organizations face when moving AI agents from experimentation into production.

In this post, we show you how to build an end-to-end, production-grade AI governance pipeline using Control-M from BMC for workflow orchestration, Amazon Bedrock Agents for AI-powered portfolio reasoning, and AWS analytics services including AWS DataBrew, Amazon Simple Email Service (Amazon SES), Amazon QuickSight, and Amazon Simple Storage Service (Amazon S3). The pipeline ingests S&P 500 governance data from Snowflake, invokes an Amazon Bedrock Agent to generate strategic portfolio rebalancing recommendations, and orchestrates the complete downstream lifecycle including PDF report generation, email distribution, decision persistence, and dashboard refresh.

What we built and why

This is Phase 3 of a three-part series on operationalizing data and AI workflows with Control-M. Phase 1 covered building a reliable ETL and descriptive analytics pipeline for S&P 500 market data, orchestrated by Control-M and visualized through Amazon QuickSight. Phase 2 extended that foundation into predictive analytics, orchestrated by Control-M to generate return forecasts, volatility estimates, confidence scores, and buy/sell signals.

Phase 3 takes the next step: instead of generating only predictive scores, an AI agent now reasons over current market conditions, evaluates governance signals, and produces portfolio rebalance recommendations that drive downstream operational actions.

The business outcome is a quarterly governance workflow for strategic portfolio rebalancing.

An Amazon Bedrock Agent – the Sentinel-1 Strategic Asset Allocator / Portfolio Rebalancing Agent – ingests governance-ready market intelligence from Snowflake, compares it against the current portfolio allocation, and determines whether market fragility signals such as declining breadth, volatility expansion, and return dispersion justify a more defensive allocation strategy.

When elevated risk conditions are detected, the workflow recommends trimming Technology exposure and redistributing allocations toward Staples, Utilities, and Cash.

Control-M orchestrates the downstream operational lifecycle generating executive PDF governance reports, archiving reports to Amazon S3, distributing reports through Amazon SES, persisting governance decisions back into Snowflake, and refreshing Amazon QuickSight dashboards for operational visibility.

This is what transforms an AI workflow from an isolated model invocation into a production-grade governance platform.

Architecture

The Phase 3 pipeline builds on the Snowflake and S3 data foundation established in the earlier phases. Control-M orchestrates the complete workflow lifecycle across Snowflake, AWS DataBrew, Amazon Bedrock, AWS Lambda, Amazon SES, Amazon S3, and Amazon QuickSight.

At a high level, the orchestration workflow follows this dependency chain:

Each job starts only after its upstream dependency completes successfully. If any stage fails, Control-M halts the workflow before incomplete or unreliable governance outputs reach downstream users.

Two architectural decisions became especially important during implementation.

The first was separating Bedrock reasoning from PDF generation. Earlier versions attempted to pass PDF content directly through the Bedrock response. This caused corruption issues because binary data was being handled as text. The final architecture keeps the Bedrock Agent focused on reasoning and structured JSON generation while Lambda handles PDF generation, chart rendering, S3 archival, and Snowflake persistence.

The second was introducing an S3 watcher as a synchronization gate. Even after Bedrock Flow completed, the generated PDF could still be uploading through the downstream Lambda process.

The Control-M Managed File Transfer (MFT) watcher solved this by waiting until the report physically existed in S3 before releasing the email and dashboard refresh steps.

This transformed the workflow into a deterministic orchestration pipeline instead of a collection of loosely connected cloud services.

Prerequisites

Before deploying this solution, ensure you have the following in place:

• An active AWS account with administrative access
• Access to Amazon Bedrock with Anthropic Claude 3.5 Sonnet enabled in your AWS Region
• A Snowflake account with the S&P 500 curated governance datasets from Phases 1 and 2
• Control-M environment (v9.0.21+) with the Control-M for AWS integration plug-in installed
• An Amazon S3 bucket for staging governance snapshots and archiving PDF reports
• IAM roles configured for Bedrock, Lambda, S3, SES, and QuickSight access (see Security Considerations)
• Amazon SES configured with verified sender and recipient identities for email distribution
• AWS Lambda functions deployed for PDF generation, S3 archival, and Snowflake persistence (with required Lambda layers for ReportLab and Matplotlib)
• An Amazon QuickSight account with a Snowflake connection configured for governance dashboard visualization

Step 1: Export the governance snapshot from Snowflake

The S&P 500 historical and curated governance datasets reside in Snowflake. Before the Bedrock Agent can reason over the data, the workflow exports governance indicators into a structured JSON snapshot staged in Amazon S3.

The governance context comes from VW_MARKET_TREND_CONTEXT, a curated Snowflake view that provides market breadth indicators, volatility metrics, Bollinger Band width, return dispersion, moving-average strength signals, and governance risk scores.

The workflow exports this data into market_snapshot.json, which becomes the governance context consumed by the Bedrock Agent.

COPY INTO @SP500_CURATED.GOVERNANCE.SP500_S3_STAGE/market_snapshot.json 
FROM ( 
SELECT ARRAY_AGG( 
OBJECT_CONSTRUCT( 
'date', DATE, 
'risk_score', RISK_SCORE, 
'vol_change', VOL_CHANGE, 
'breadth_change', BREADTH_CHANGE, 
'avg_volatility', AVG_VOLATILITY, 
'pct_overbought', PCT_OVERBOUGHT, 
'return_dispersion', RETURN_DISPERSION, 
'dispersion_change', DISPERSION_CHANGE, 
'pct_above_ma30', PCT_ABOVE_MA30, 
'avg_bb_width', AVG_BB_WIDTH 
) 
) AS market_data 
FROM SP500_CURATED.MARKET.VW_MARKET_TREND_CONTEXT 
) 
FILE_FORMAT = (TYPE = 'JSON' COMPRESSION = NONE) 
OVERWRITE = TRUE 
SINGLE = TRUE; 

Exporting governance snapshots into Amazon S3 before invoking the Bedrock Agent creates a reproducible AI input artifact. Every workflow run becomes traceable to the exact governance snapshot used during reasoning. It also decouples Bedrock execution from direct database dependencies, improving operational reliability and auditability.

The workflow later writes governance outputs back into Snowflake tables including:

• BF_REPORT_RUNS
• BF_REPORT_ALLOCATIONS
• BEDROCK_DECISION_RESULTS
• DECISION_LOG

These tables provide governance history, workflow metadata, recommendation tracking, and operational auditability for downstream reporting and dashboarding.

Step 2: Validate the snapshot for AI readiness

Before the Bedrock Agent processes the governance snapshot, AWS DataBrew validates the exported data. This becomes the AI-ready data gate within the orchestration pipeline.

The validation layer checks for conditions that could cause the Bedrock Agent to produce misleading governance recommendations:

• Empty governance snapshots
• Missing governance indicators such as risk_score or breadth_change
• Duplicate records
• Structurally invalid numerical values
• Schema inconsistencies

This step becomes one of the most important operational safeguards in the architecture.

AI systems reasoning over incomplete governance data often do not fail obviously. Instead, they produce confident-looking recommendations grounded in unreliable inputs. By validating the snapshot before Bedrock execution begins, Control-M ensures that only trusted governance data reaches the reasoning layer.

If validation fails, the Bedrock workflow never starts.

This is one of the clearest differences between a demo AI workflow and a production AI workflow.

Step 3: Invoke the Bedrock Portfolio Rebalancing Agent

With validated governance data staged in Amazon S3, Control-M invokes the Bedrock workflow.

The workflow uses Amazon Bedrock Flow and the Sentinel-1 Portfolio Rebalancing Agent running on Anthropic Claude 3.5 Sonnet. The agent benchmarks current market conditions against the 2018 stress period and evaluates whether defensive portfolio positioning is warranted.

Model selection

The agent uses Anthropic Claude 3.5 Sonnet on Amazon Bedrock. This model was selected for its:

• Strong performance on structured reasoning and financial analysis tasks
• 200K context window — sufficient for ingesting full governance snapshots without truncation
• Consistent structured output generation with strong JSON schema compliance
• Cost-effective balance between reasoning quality and invocation latency for quarterly governance workloads

Agent configuration

The Sentinel-1 Portfolio Rebalancing Agent is configured with:

• Data context: S3 bucket containing Current_Portfolio.csv and the historical 2018 stress period benchmark snapshot (market_snapshot.json)
• Action Group: ReportArchiver tool receives the structured JSON analysis, generates a PDF governance report with allocation charts, archives it to S3, and returns a secure pre-signed download link
• Instructions: Evaluate volatility expansion, market breadth deterioration, return dispersion, and sector concentration against historical stress periods. Classify market state, produce rebalancing recommendations, and invoke ReportArchiver with the complete structured JSON analysis.

The final workflow prompt used during implementation was:

The Q1 2026 data is staged in S3 (using the file Current_Portfolio.csv). Conduct a fragility benchmark against the 2018 stress period and generate a PDF strategic rebalancing proposal for Q2. I need to see the chart of recommended sector shifts both here and inside the PDF; please render all charts at 100 DPI to ensure the PDF is optimized for archival. Finally, archive that PDF to S3 via the ReportArchiver tool and provide me with the exact secure download link.

The Bedrock Agent evaluates volatility expansion, market breadth deterioration, return dispersion, governance risk scores, sector concentration risk, and similarity to historical stress conditions.

The resulting response contains governance classifications, confidence scores, rebalance recommendations, and executive governance summaries.

Example output:

{
"market_state": "HIGH_RISK",
"confidence": 0.91,
"recommended_action": "STRATEGIC_REBALANCE",
"rebalance_summary": "Trim Technology exposure by 4-5% and redistribute to Staples, Utilities, and Cash.",
"drivers": [
"Breadth deterioration",
"Elevated risk score",
"Volatility expansion",
"Technology overweight relative to defensive allocation"
],
"executive_summary": "Market fragility indicators suggest reducing concentration risk and increasing defensive allocation."
}

This becomes the governance decision point within the workflow. The Bedrock Agent is not simply generating a classification score — it is producing a portfolio governance recommendation grounded in multi-factor market analysis.

Step 4: Confirm the report has landed in S3

After Bedrock Flow completes, the generated PDF report may still be uploading through the downstream Lambda process.

This creates a synchronization challenge.

If the SES email job starts immediately after Bedrock execution completes, it could attempt to retrieve a report that has not fully landed in Amazon S3 yet.

Control-M solves this using an MFT watch-only job.

The watcher monitors:

s3://sp500-lambda-bedrock/reports/

for reports matching:

Strategic_Rebalance_*.pdf

The workflow only proceeds once the report physically exists in Amazon S3 as a confirmed, completed governance artifact. This transforms the S3 watcher into a synchronization gate rather than a simple monitoring task. It ensures downstream email distribution and dashboard refreshes always operates.

Step 5: Distribute the report via Amazon SES

Once the report is confirmed in Amazon S3, Control-M invokes the downstream email distribution workflow.

A Lambda function retrieves the latest governance PDF report from Amazon S3 and distributes it through Amazon SES to the configured recipients.

The distributed report includes:

• Governance risk analysis
• Historical stress benchmarking
• Current versus target allocation charts
• Strategic rebalance recommendations
• Executive governance summaries
• AI-generated portfolio rationale

This turns AI reasoning into an operational governance deliverable rather than an isolated analytical result.

The investment committee receives an executive-ready governance report immediately after the workflow completes, without requiring any manual intervention.

Step 6: Refresh the QuickSight governance dashboard

At the same time the governance report is distributed, Control-M refreshes the Amazon QuickSight dashboard connected to the Snowflake governance tables. The dashboard is automatically refreshed after each successful workflow execution, providing operations teams with the latest portfolio analysis and governance metrics.

The dashboard provides an operational view of the portfolio by displaying:

• Current vs. Target Allocation by sector, allowing users to compare existing portfolio weights against the AI-recommended allocation.
• AUM Impact by Sector ($M), highlighting the projected increase or decrease in assets under management for each sector based on the recommended rebalance.
• Key portfolio risk indicators, including Risk Score, Market Breadth KPI, and IT Weight Percentage, which summarize the current market conditions used during the portfolio analysis.
• Run History, showing each workflow execution, generated report filename, execution timestamp, and key market metrics for historical tracking and auditability.

The dashboard complements the generated PDF report by providing an interactive operational view of portfolio allocation changes, market indicators, and workflow execution history.

While the PDF serves as an executive-ready governance report for quarterly portfolio review meetings, the QuickSight dashboard enables operations teams to monitor portfolio metrics, validate workflow executions, and review historical results.

Together, they transform AI-generated portfolio recommendations into actionable operational intelligence.

Key Architectural Decisions

Decision 1: Separate Bedrock reasoning from PDF generation

Earlier versions of the workflow attempted to pass PDF content directly through the Bedrock Agent response. This caused binary data corruption when handled as text. The final architecture keeps the Bedrock Agent focused exclusively on reasoning and structured JSON generation, while a dedicated Lambda function handles PDF generation, chart rendering, S3 archival, and Snowflake persistence. This separation makes each component independently testable – a critical advantage when iterating on a production governance pipeline.

Decision 2: S3 watcher as a synchronization gate

Even after Bedrock Flow completes, the generated PDF may still be uploading through the downstream Lambda process. Triggering email distribution immediately after Bedrock execution would cause Lambda to attempt to retrieve a report that has not yet physically landed in S3. The Control-M MFT watch-only job solves this by monitoring the S3 reports path for the matching PDF filename pattern and only releasing downstream jobs once the file actually exists. This transforms a race condition into a deterministic orchestration gate.

Decision 3: DataBrew as an AI-ready data gate

AI agents reasoning over incomplete or malformed governance data do not always fail obviously. They produce confident-looking recommendations grounded in unreliable inputs. Placing AWS DataBrew as an explicit AI-ready data validation layer before Bedrock execution ensures that only complete, structurally valid governance snapshots reach the reasoning layer. If validation fails, the workflow halts before the agent is invoked, preventing the pipeline from producing and distributing a governance recommendation based on bad data.

Security Considerations

This solution implements defense-in-depth security across the orchestration pipeline:

IAM least-privilege access

• Bedrock Agent role: Scoped to bedrock:InvokeAgent and bedrock:InvokeModel for Claude 3.5 Sonnet only
• Lambda execution roles: Separate roles per function with least-privilege access to S3, SES, and Snowflake
• Control-M service role: IAM role with sts:AssumeRole permissions, scoped to specific resource ARNs

Data protection

• All data in S3 encrypted at rest using AWS KMS customer-managed keys
• Data in transit encrypted via TLS 1.2+ between all service endpoints
• Snowflake connection uses encrypted JDBC with private link where available
• Pre-signed S3 URLs for report access expire after a configurable TTL (default: 72 hours)

Amazon Bedrock Guardrails

For production deployments, we recommend configuring Amazon Bedrock Guardrails to:

• Filter outputs that do not conform to expected JSON schema
• Block responses containing personally identifiable information (PII)
• Apply content filters to prevent model hallucinations about specific financial instruments
• Log all guardrail interventions for audit purposes

Monitoring and Observability

The solution provides multi-layer observability:

Control-M monitoring

• Real-time workflow execution visibility in the Control-M Web interface
• Dependency-aware alerting: if any upstream step fails, downstream steps are held
• SLA management: configure time-based alerts if the full pipeline exceeds expected duration
• Historical execution reports for trend analysis

AWS CloudWatch integration

• Lambda function logs and metrics (duration, errors, throttles) via Amazon CloudWatch
• Bedrock invocation metrics (latency, token usage, throttling)
• S3 event notifications for object creation tracking
• Custom CloudWatch alarms for anomalous Bedrock response times

Governance audit trail

Every governance decision is persisted to the Snowflake DECISION_LOG table with timestamps, confidence scores, model version, and the input snapshot hash. This provides a traceable audit trail for regulatory compliance and model performance tracking.

What the complete workflow delivers

When the workflow executes at the end of a quarter, the investment committee receives a governance report containing market fragility analysis, historical stress benchmarking, current versus target allocation recommendations, and AI-generated governance summaries.

At the same time, QuickSight dashboards refresh automatically, governance history is persisted into Snowflake, and Control-M captures the workflow lifecycle end-to-end.

No manual intervention is required.

And if anything fails – stale governance data, validation issues, Bedrock quota problems, synchronization failures, or downstream delivery issues – the workflow stops before unreliable outputs reach stakeholders.

That is what production-grade AI orchestration looks like.

Conclusion

In Phase 3, we built an automated AI governance pipeline spanning governance data preparation, AI-ready validation, Bedrock reasoning, PDF report generation, operational notification, dashboard visualization, and Snowflake persistence – all orchestrated reliably through Control-M.

By integrating Amazon Bedrock Agents, Bedrock Flow, AWS DataBrew, Lambda, Amazon SES, Snowflake, Amazon QuickSight, and Control-M, AI governance becomes a dependable operational capability rather than an experimental AI exercise.

The result is a scalable orchestration pattern for enterprise AI governance workflows: agents reason, cloud services execute, and Control-M ensures the entire process runs in the correct order with reliability, visibility, auditability, and operational control.

Try it yourself

To help you get started, we’ve published the Control-M workflow used in this solution in a public GitHub repository:

https://github.com/mol-bmc/bedrock-portfolio-rebalance

The repository currently includes:

• The exported Control-M job definitions (jobs.json) for the end-to-end orchestration workflow.
• A README with basic information about the project.

These assets provide a starting point for understanding how the workflow is orchestrated with Control-M. You can import and review the workflow definitions, then adapt them to your own AWS, Snowflake, and Amazon Bedrock environment by configuring your own connection profiles, IAM roles, cloud resources, and datasets.

As the project evolves, additional implementation assets and supporting examples may be added to the repository.

Although this implementation demonstrates an AI-governed portfolio rebalancing use case, the orchestration pattern can be applied to many enterprise AI workflows that require trusted data preparation, agent reasoning, downstream automation, monitoring, and auditability.

Enterprises are adopting generative AI and agentic AI at the same time, often without a clear account of how the two differ or what each demands from the systems that actually run production work.

The distinction is operational, not just conceptual. Generative AI creates content: drafts, summaries, code. It changes how work gets designed. Agentic AI acts: it plans steps, takes actions across systems, and adjusts when conditions change. It changes how work gets executed. And the two also fail differently, need different kinds of oversight, and place different demands on the orchestration layer.

These differences shape what each form of AI requires from enterprise workflow orchestration. Agents moving into production are changing what that layer has to do.

What is generative AI?

Generative AI creates content. Given a prompt, it produces text, code, images, or summaries—new material shaped by patterns learned from the data it was trained on. It’s the technology behind AI assistants that draft documents, answer questions, and write and explain code.

It’s reactive, performing a standalone task with each prompt, and its output, such asa draft, an answer, or a report,typically goes to a person in the enterprise who reviews it and decides what happens next. In other workflows, generative outputs feed directly into automated pipelines without a human reviewing each one. In either case, the value is speed and accessibility: summarizing a failure log in plain language, drafting a workflow structure from a description of what needs to run — work that once required specialist time now takes minutes.

What generative AI doesn’t do is act. It changes how work gets designed and understood. It doesn’t change how work gets executed.

What is agentic AI?

Agentic AI pursues goals. Given an objective, an agentic system makes a plan, carries it out, and adjusts it when conditions change. It draws on a language model for reasoning, with generative AI now functioning as a component rather than a standalone tool, and on external tools for action: it queries systems, triggers processes, calls APIs. Where generative AI responds only to prompts, agentic AI can also be set in motion by events: a threshold crossed, a job failed, a deadline approaching.

Instead of producing a draft, agentic AI changes the state of a system: a job is re-sequenced, a workload rerouted, a recovery initiated. A person still sets the goal and the boundaries, but the work between goal and outcome happens without step-by-step human direction.

In an operations context, an agentic system might detect that a critical data feed is running late, determine which downstream jobs depend on it, and re-sequence them to protect the delivery deadline—within the policies the enterprise has set.

How do agentic AI and generative AI compare?

In production, the differences that matter most come down to two questions: what happens when each system is wrong, and what each needs from the systems around it.

When AI is wrong: the risk asymmetry

When generative AI fails, it produces bad content, such as an inaccurate summary, a flawed piece of code, or a report that misstates the numbers. Whether a person reviews that output or it flows into an automated pipeline, the failure is informational: wrong content, not a wrong action. The systems downstream may act on bad information, but the AI itself hasn’t changed a system state.

When agentic AI fails, it takes a wrong action. A job triggered against the wrong environment, a workload rerouted on a faulty premise, a remediation step that compounds the original problem. The AI has changed a system state directly, and there may be no pause between the mistake and its consequences.

This asymmetry is why oversight built for generative AI doesn’t transfer to agentic AI. Review of outputs, whether human or automatic, can catch bad content before it spreads. But when the AI produces actions rather than content, governance has to move into the runtime itself: enforcing policies at the moment of execution, holding boundaries the agent cannot cross regardless of what it decides, and keeping a complete record of what it actually did.

What this means for enterprise AI workflow orchestration

Both kinds of AI place demands on the workflow orchestration layer: the systems enterprises already use to run workflows, enforce dependencies, and meet SLAs across applications, data pipelines, and infrastructure. But the demands are different.

Generative AI needs reliable workflows around it. Models are only as good as the pipelines that feed them current, correct data, and the processes that move their outputs to where decisions get made. That’s what orchestration has always done—it makes sure the right work runs in the right order, every time.

Agentic AI needs something more: governed execution. If agents are going to act on production systems —triggering jobs, rerouting workloads, initiating recoveries— then something has to enforce the policies those actions must follow, maintain the audit trail of every action agents take, and make those actions visible enough for the enterprise to intervene when an agent’s plan diverges from the enterprise’s interests.

Some in the industry describe agentic AI as becoming the orchestration engine itself—the intelligence that coordinates jobs, adjusts schedules, and optimizes resources on its own. Agents will certainly participate more and more in how work gets sequenced and run. But collapsing the agent and the orchestration layer into a single thing gives up something enterprises should not give up: an independent layer that governs what agents do, sitting outside the agents themselves. The rise of agentic AI means that layer has to expand to do more than it ever has before—not that the layer can be replaced by agentic AI itself.

Generative AI creates the intent. Agents carry it out. The orchestration layer governs execution, applying the same policies, auditability, and controls to agents as to everything else it runs.

How Control-M approaches this

Control-M, BMC’s orchestration platform, provides a unified orchestration layer for both generative AI and agentic AI by governing the execution of AI workflows, agents, applications, and data pipelines through a single operational framework.

On the generative side, Control-M orchestrates AI workflows that contain generative AI tasks, in addition to the data pipelines, application workflows, and dependencies that generative AI runs on. It also uses generative AI internally to help users: Control-M’s built-in AI advisor, Jett, answers questions about workflows and their status in plain language; AI Workflow Creator builds workflow structures from natural-language descriptions.

On the agentic side, Control-M orchestrates AI agents and AI-powered tasks alongside the data pipelines, applications, and event-driven workflows it already runs—with the same reliability, visibility, and governance. Integrations with agent frameworks including CrewAI, LangGraph, and Snowflake Cortex bring agent-driven work into governed workflows. And through the optional Control-M MCP Server, built on the Model Context Protocol (an open standard for connecting AI agents to external systems), external AI agents can interact with Control-M itself— triggering jobs, checking workflow status, investigating failures—without bypassing enterprise controls.

FAQ

What’s the main difference between agentic AI and generative AI?

Generative AI creates content (text, code, summaries) in response to a prompt. Agentic AI pursues a goal: it plans the steps, takes actions across systems, and adjusts when conditions change. The difference shows in the output: Generative AI produces an artifact that a person or an automated process reviews. Agentic AI produces an outcome—a changed system state.

Can generative AI and agentic AI work together in the same workflow?

Yes, and in practice they’re deeply intertwined. Agentic systems are built on language models—they use them for reasoning, planning, and intermediate tasks like summarizing data or interpreting results. The orchestration layer coordinates both, making sure the generative steps get the right inputs and the agentic steps run under the controls the enterprise sets.

Why can’t enterprises govern agentic AI the same way they govern generative AI?

Because they fail differently. When generative AI is wrong, it produces bad content: an inaccurate draft, a flawed summary. The damage is contained until that output is acted on, and a review—by a person or an automated process—can intercept it. When agentic AI is wrong, it takes a wrong action on a live system, and the consequences can play out before anyone knows a mistake has been made. That’s why oversight has to move from reviewing outputs to setting limits the agent can’t exceed and enforcing them as it acts.

What role does workflow orchestration play in running AI in production?

Both kinds of AI depend on the orchestration layer, but differently. Generative AI needs reliable workflows around it. Agentic AI needs governed execution—policies enforced on its actions, a complete record of what it did, and visibility while it runs. The orchestration layer is the natural place to govern agents’ actions, because it already enforces dependencies, SLAs, and recovery for the workloads around them.

Where to go from here

As agents enter production alongside data pipelines, applications, and human operators, the orchestration layer can’t treat them as an exception. They need the same oversight as everything else that runs—governance that moves at the speed of the agents themselves, with the auditability and controls the enterprise already depends on.

Learn how Control-M orchestrates AI workflows and AI agents in production.

Explore BMC’s approach to enterprise agentic orchestration.