The word is out! BMC AMI Ops Monitoring delivers a significant financial return. How significant? According to the recently released and commissioned The Total Economic Impact™ of BMC AMI Ops Monitoring study conducted by Forrester Consulting on behalf of BMC, a 130 percent return on investment (ROI), a net present value (NPV) of $2.94 million, and a benefits present value (PV) of $5.19 million over three years. These positive results are driven by halving unplanned mainframe outages, achieving significant cost savings from retiring outdated legacy systems, and reallocating full-time employees to more critical tasks to enhance overall productivity.

BMC AMI Ops Monitoring yielded these results with an integrated solution that automates actions and centralizes control across mainframe environments by monitoring operating systems, databases, networks, middleware, and storage; optimizing performance; and minimizing downtime risks. Additionally, the solution’s advanced automation and observability features enable organizations to proactively manage their mainframes, detecting and resolving issues before they impact operations. This comprehensive approach improves operational efficiency and supports strategic business growth by ensuring high system availability and performance.

130 percent ROI—A closer look

Let’s dive into insights gathered by Forrester Consulting through interviews with professionals who have hands-on experience with the solution. The results were aggregated and combined to form a single composite organization. Weaving together their experiences and analyzing the ROI, Forrester analysts crafted a compelling narrative.

The study found that, in addition to reduced MSU usage and improved visibility, the composite company representing the research achieved a 50 percent reduction in unplanned outage downtime, resulting in a $1.4 million retained profit over three years.

Explore the Key Findings

Looking for a quick summary of the study’s findings? Explore the infographic for a visual overview of the financial and operational benefits organizations achieved with BMC AMI Ops Monitoring.

View the infographic: Forrester TEI Infographic

“We’ve cut downtime in half with BMC AMI Ops Monitoring. Monitoring all in one place has really given us that ability in a way that we didn’t have before.”
—VP of operations, financial services

See How AI Is Improving Mainframe Operations

The Forrester study quantifies the business value of modern monitoring. To see how organizations are applying these concepts in practice, watch our on-demand webinar covering predictive AI, automation, and modern monitoring strategies that help teams improve reliability, identify issues earlier, and reduce time to resolution.

Watch the on-demand webinar: Improve Mainframe Reliability and Performance with AI

$4M+ in legacy solution cost savings

Also, by consolidating and automating monitoring, the composite company reduced retired legacy solutions costs by 80 percent and achieved a three-year total savings of $4,050,000.

“BMC has allowed us to reduce the number of licenses and the number of the functionality that we need from our legacy solution. We will potentially eliminate it entirely, which will generate even more savings going forward.”

—VP of operations, financial services

Dig Deeper into the Research

Want to learn more about the methodology, assumptions, and business outcomes behind the findings?

Download the full study: Forrester Total Economic Impact™ Report

$607k savings by reallocating full-time monitoring employees

As the composite company shows, organizations face the challenge of reducing costs while monitoring numerous environments and navigating a shortage of mainframe talent―all while handling increasingly active and unpredictable workloads.

“Prior to [BMC] AMI Ops, with the legacy system, we had multiple people monitoring usage for multiple platforms. BMC allowed me to reallocate probably three full-time employees from monitoring into other departments and to other areas of the firm. We were able to repurpose them.”

—VP of operations, financial services

Nine-to-five isn’t a thing anymore; every hour is a business hour. Across demographic groups, customers are using the web and online applications to conduct banking transactions, make changes to their insurance, keep track of medical records, or even buy groceries—and they expect instant response times from 24×7 service availability. Minimizing downtime, whether planned or unplanned, can mean the difference between delighting customers and losing them to competitors.

Proactive root-cause analysis to address performance issues before they occur

Whether in mainframe operations or everyday life, an informed, proactive approach is preferable to reactive “firefighting.” Waiting for issues to develop, seeking out their root causes, and then working to resolve them costs the business precious time and leaves you vulnerable to even more significant delays if further problems develop.

Today’s operations teams need more than monitoring dashboards. They need intelligent capabilities that help identify abnormal behavior, connect related events, and guide operators toward faster resolution. By combining centralized visibility, automation, and AI-driven operational insights, organizations can reduce alert noise, improve service reliability, and accelerate problem resolution.

This better aligns the blog with the September campaign themes around modern monitoring, AI-powered operations, and reduced MTTD/MTTR.

“BMC saves me time performing day-to-day tasks by proactively driving to root-cause analysis. The automation and intelligence that the product is giving us helps us make decisions in a timely manner.”

—Technical support manager, insurance

Knowing what caused previous issues, looking for warning signs, and working to prevent those issues gives you a clear advantage. Operations teams that use manual processes and rely on several monitoring solutions can easily miss not only warning signs but also active issues, leading to costly outages and extended resolution times. And it’s nearly impossible for operators, regardless of their experience, to keep track of past issues and their causes while simultaneously monitoring and analyzing multiple environments for similar trends.

BMC AMI Ops Monitoring helps avoid these situations by analyzing both historical and real-time data, all in a single view. Armed with the knowledge of conditions that have led to issues in the past, as well as the ability to monitor for the recurrence of these conditions, it informs operations teams that trouble is brewing, allowing them to reallocate resources and work to fix problems before they even happen. Combined with a real-time view of critical resources and usage metrics across multiple mainframe environments, this gives teams unprecedented visibility into system health.

No amount of monitoring will prevent every issue, though. When problems do arise, BMC AMI Ops Monitoring doesn’t leave teams guessing. Providing guided navigation to the source of the issues helps teams identify problem components and processes and reduce mean time to resolution (MTTR).

Ensuring high performance

Even when things work normally, mainframe operations teams are busy maximizing resource usage efficiency while keeping costs low and maintaining maximum availability. They can’t rely on traditional slow periods, such as overnight hours or weekends, to conduct maintenance or fine-tune their systems. As transaction and data volume increase and become more unpredictable, they must adjust their practices to ensure maximum uptime and customer satisfaction.

“With BMC AMI Ops Monitoring, it’s a one-stop-shop, comprehensive solution. We can use this on one console rather than using a combination of [point solution], some in-house functionality, and other systems. It’s allowed us to streamline our staff and put certain people in charge of certain functionality in a way that we were unable to before. It’s improved efficiency a great deal.”

—VP of operations, financial services

By offering real-time monitoring and a single point of control for multiple systems, BMC AMI Ops Monitoring empowers operations teams to reallocate resources, adjust parameters, and make system changes without costly downtime. This standardized, single-view system also helps onboard new team members faster and empowers less-experienced operators, improving workforce efficiency and simplifying monitoring to deliver additional cost savings.

A positive impact

As shown in the study, the enhanced visibility, actionable insights, and increased efficiency offered by BMC AMI Ops Monitoring not only lead to improved system availability but also help streamline operations and reduce costs, positively impacting your organization’s bottom line and your customers’ satisfaction.

To learn more about the quantified and unquantified benefits of adoption and see more of the findings, read The Total Economic Impact™ of BMC AMI Ops Monitoring.

Each year, BMC asks members of the mainframe community to share their thoughts on the platform—the technologies and processes used to keep the platform thriving, what has changed over the past year, and where they see it headed in the near future. Results of the 2026 BMC Mainframe Survey show that the mainframe remains an integral part of the modern digital economy, with artificial intelligence (AI) poised to lead the platform into a new era of innovation.

A changing approach to AI integration

The survey shows that confidence in the platform remains near record highs, with 94 percent of respondents seeing it as a long-term platform or one that attracts new workloads, and 69 percent report growth of general-purpose capacity. In short, the mainframe continues to grow, spurred by modern processes like DevOps and AIOps and by technological advances like AI.

Just like the technology itself, the application of AI on the mainframe is maturing and advancing at breakneck speed. The 2026 survey shows that organizations are adapting their adoption of the technology, moving from enthusiastic experimentation to a more deliberate, business outcome-focused approach. It has become clear that the next era of mainframe innovation will be driven by organizations that approach AI strategically while those that hesitate risk being left behind.

From the use of generative AI (GenAI) to assist developers, the deployment of AI-powered monitors to aid in performance tuning and problem detection, and the increasing use of agentic AI to manage the platform, organizations are willing to employ the technology across the mainframe environment. But trust in the technology is evolving. The survey shows that mainframe professionals prefer AI that recommends actions over AI that acts autonomously,  implementing systems where AI advises first, with humans retaining control over execution.

As adoption of AI on the mainframe increases and new use cases are developed, the most successful organizations will be those that combine domain expertise, operational context, and governance to help people make better decisions rather than simply automating them.

Security remains a top priority

For the seventh consecutive year, compliance/security ranks as the top priority of survey respondents. The increase in AI-based applications and services, of course, adds a new wrinkle to platform security. As more of these tools and AI agents access mainframe data, there is sure to be an increase in the volume of security certificates issued. With CA/Browser Forum requirements reducing the lifecycle of TLS certificates from 398 days in 2025 to just 47 days by March 2029, management of new certificates, renewal, and monitoring activity for most organizations will become too complex and unwieldy for most organizations to handle manually.

The 2026 survey shows, however, that the majority of respondents are either managing certificates manually or using automated solutions developed in-house. Preparing for this influx of new certificates and accompanying regulation changes should be a priority over the coming year.

Data security and recovery a growing concern

The priority seeing the most significant change (a 4 percent increase) over the 2025 survey was data recovery. Respondents cited increasing the number of recovery points, recovery times, and backup/recovery automation as the top data recovery challenges faced by their organizations.

Data safety is also a concern in relation to AI implementation. The 2026 survey shows that organizations prioritize safe and effective AI connection to their mainframe data, data integration issues cited as the third-highest concern when implementing AI solutions.

As the platform continues to grow, data volumes will follow suit. And with more AI-based solutions accessing that data, mainframe organizations should and will continue to prioritize certificate management, data storage, security, and recovery.

A platform poised for the future

As the 2026 BMC Mainframe Survey makes clear, the mainframe is not simply maintaining its relevance, it is evolving to meet the demands of an AI-driven digital economy. Organizations are embracing new technologies while remaining focused on the fundamentals of security, resilience, and operational excellence. The challenge ahead is not whether the mainframe can support the next generation of innovation, but how effectively organizations can balance growth, governance, and trust as they modernize. Those that invest in intelligent automation, strengthen their security and recovery strategies, and empower experts with AI-driven insights will be best positioned to unlock the full potential of the platform in the years ahead.

For more insights from the 2026 BMC Mainframe Survey, read our full report, “How AI is driving the next era of mainframe transformation.”

The mainframe remains the transactional backbone of many of the world’s largest organizations and the primary repository for “System of Record” data. While mainframe reliability provides an enormous business advantage, it can also create complacency. As artificial intelligence (AI) dramatically lowers the expertise and time required to identify vulnerabilities and develop attacks, organizations need to rethink assumptions about what has historically kept the mainframe secure.  AI-based attacks have increased the concern for mainframe security and preparedness and should be a wake-up call for organizations that have overlooked investment into hardening the security and resilience of the critical mainframe platform.

Mythos and variants: A brief overview

As AI is advancing to perform deep-dive vulnerability analysis and create attack vectors based on those vulnerabilities, how can we protect our critical mainframe infrastructure?  Mythos is an advanced AI model developed by Anthropic that can find and exploit software flaws better and faster than most humans.  Access was provided to 12 companies as part of Project Glasswing, where the model successfully identified thousands of high-severity vulnerabilities, according to Anthropic.  Recently, Mythos successfully “broke out” of a secured sandbox environment.  Additionally, OpenAI admitted that it’s model “broke loose” and successfully attacked the AI company Hugging Face.

Autonomous AI-powered attack models are here.  With Mythos and its variants becoming more powerful, more capable, and more adaptable, no computing platform will be out of reach.

AI is breaking three long-held assumptions about mainframe security

Mythos and variants destroy 3 key assumptions that I see across some organizations that rely on mainframes:

• Security by obscurity. This is the belief that a small group of mainframe professionals understands the complexity of mainframe operating systems (z/OS, USS, VM, etc), therefore the likelihood of a successful attack on their organization’s mainframe is very low.  AI models are or will be able to consume the full documentation for mainframe operating systems and their subsystems, assess vulnerabilities in versions and configurations, then identify attack vectors that leverage those vulnerabilities, making these AI models more capable than most mainframe professionals.
• Reliance on ESM (RACF, ACF2, Top Secret) logs. Many organizations review updates to ESM profiles for users, resources, and privileges with the expectation that ESM controls are sufficient to detect security threats on the mainframe.  As virtually every mainframe has vulnerabilities that are beyond the scope of ESM controls, those controls can be exploited to successfully attack mainframes.
• Assuming network/perimeter defense protects the attack surface of the mainframe. The limited number of organizations in receipt of Mythos includes Palo Alto Networks and Cisco—the network devices most often used to secure the network perimeters—where Mythos reported finding over 23,000 vulnerabilities from the limited set of companies.  If the initial releases of AI-powered vulnerability assessment and attack planning are this effective, we can expect future releases to be even more threatening.

What can we do to protect mainframes?

The first thing that has to change amongst the mainframe community is the security mindset. Taking the following steps will help your organization harden its security against AI-based attacks:

• Employ Zero Trust on the mainframe. Assume that threat actors are on your mainframe who understand where the vulnerabilities are and will exploit them.
• Know your vulnerabilities before your adversaries know your vulnerabilities. Complete an independent comprehensive penetration test by mainframe-fluent professionals and develop a remediation plan to close the vulnerability gaps.
• Detect threats by deploying a comprehensive security monitoring solution that identify suspicious or malicious activity in real time. This should include behavior analytics to pinpoint activity that deviates from normal—a key defense capability for detecting AI-based activity. All significant security events should be sent to the organizational SIEM for enterprise visibility and appropriate response.
• Protect your data by implementing 1) periodic immutable backups that can not be changed, deleted or accessed by threat actors and 2) continuous immutable streaming of transaction recovery assets.
• Exercise recovery processes periodically, leveraging the immutable backups and transaction recovery steps to properly prepare in the event of a successful attack.

The reality of mainframe protection

Now at lightning speed, an AI-based attack mimics the steps that a well-trained mainframe hacker would perform:  uncover vulnerabilities, identifying existing credentials, expanding capabilities through elevated privileges or increased access, and deploying programs that exfiltrate and/or encrypt data or incapacitate the platform.   All of these activities are atypical for most users on a mainframe and detecting this atypical behavior is paramount.  Numerous indicators of compromise, “honeypot” datasets to attract/detect threat actors, and behavior analytics with real-time notification to the SOC for high-priority security events are the best protection.

As change increases, agility becomes more critical

Security monitoring tools that require extensive programming, extensive consulting, or massive infrastructure to move millions of logs impact the ability to adapt to new mainframe security pressures.  Modern mainframe security tools enable fast deployment of new indicators of compromise with behavior analytics, SIEM integration, and forensic analysis built into the foundation of the toolset.  Forensic Analysis enables mainframe experts that have extensive platform experience to dive deep into behavior that looks suspicious.  Don’t underestimate your local experts, empower them.

Mythos and variants increase the likelihood of catastrophic attack

A ransomware attack could encrypt your data but leave the mainframe operational.  A catastrophic attack would disable the mainframe from functioning, likely through the destruction of critical operating system datasets.

In each case, recovery plans that have been exercised and tested are critical to support the organization’s return to normal business operations.

Summary

AI is changing the economics of cyberattacks by allowing adversaries to identify vulnerabilities, develop attack paths, and operate at a speed and scale that were previously impossible. For organizations that depend on the mainframe, that makes traditional assumptions about security increasingly risky.

The answer isn’t fear of AI, it’s eliminating the blind spots AI can exploit. That means understanding vulnerabilities before attackers do, detecting abnormal activity as it occurs, integrating mainframe security into the enterprise SOC, and maintaining a tested path to recover critical systems and data in the event that an attack succeeds.

The mainframe cannot remain a security island. When the platform supports the transactions and data that keep the business running, mainframe security is enterprise security.

When I joined IBM at the beginning of my career, I saw firsthand how reliable, available, scalable, and secure the mainframe was for customers. Over the years, I have watched as concepts like virtualization were pioneered on the mainframe and how mainframe technology has consistently evolved to enhance its importance to the enterprise. According to IBM, mainframes now manage up to 19 billion encrypted transactions a day. That’s why I’m not surprised when SHARE says that mainframes handle 90 percent of all credit card transactions, or when IDC says most large enterprises have mainframes that run mission-critical workloads.

As organizations work to be more agile, data-driven, and customer-centric, continued mainframe transformation will be critical, and companies must integrate their mainframes with the wider IT ecosystem.

BMC’s acquisition of BMC AMI Strobe is an example of how we are helping customers speed their modernization journey. Forrester said of the acquisition: “CIOs have realized their digital transformations get stuck if they don’t modernize their core systems, many of which run on mainframes… The bet of BMC and BMC AMI Strobe is to scale DevOps on the mainframe like any other platform. We like this move by BMC.” The acquisition provides mainframe developers a fully integrated DevOps toolchain that supports agile, high-quality mainframe application development.

We have connected innovative mainframe solutions that will help customers thrive now and in the future. We announced an integration between Control-M, BMC’s leading application workflow orchestration solution, and BMC AMI Ops Automation for Batch ThruPut, BMC AMI Strobe’s best-in-breed mainframe batch processing optimization solution. Here’s a look at how one customer is already using the integration to improve the management of its month-end close processes.

Automating the complexity out of financial close processes

Every company, regardless of industry, completes financial close processes to verify and adjust account balances and produce summary financial statements. These financial statements are critical to help executives make strategic data-driven decisions.

A large financial services company that offers banking, insurance, and investment services decided to use application workflow orchestration and mainframe batch management to improve their monthly financial close processes. To ensure timely delivery, their financial close processes required the flow of accounting and summarization jobs–triggered from different lines of business–to enter the system in the middle of the last business day of the month, and to be executed at the optimal point in time.

This meant that financial close workflows must be given preference over daily cycle jobs, which are accommodated once the monthly jobs are completed. But they had to ensure that daily jobs would not be delayed too long, or business service SLAs could be missed.

However, this integration changes all that, customers running Control-M for z/OS and BMC AMI Ops Automation for Batch ThruPut needed to write substantial amounts of code to be able to align the prioritization logic of the two solutions. However, the recently announced integration changes all that.

Control-M for z/OS and BMC AMI Ops Automation for Batch ThruPut

Control-M for z/OS simplifies the orchestration of mainframe application workflows. It helps customers define, schedule, manage, and monitor mainframe application workflows so business services are delivered on time, every time. It is part of a wider platform that enables end-to-end application workflow orchestration, mainframe to cloud.

Control-M’s orchestration planning is based on a rich set of data, including predefined date and time schedules, job durations, dependencies, priorities, SLA deadlines, and other logical requirements. It also includes historical run-time statistics, which are used to refine plans and improve SLAs over time.

With this built-in intelligence, Control-M for z/OS produces an accurate job prioritization that determines the job submission order. It submits jobs in that specific order to the system for execution but does not have control over their actual execution. That’s where BMC AMI Ops Automation for Batch ThruPut enters the equation.

BMC AMI Ops Automation for Batch ThruPut automates the processing of batch queues and determines the execution order of jobs, based on its own service levels, queue waiting times, resources, and CPU utilization. It constantly reprioritizes jobs in the queue and adjusts the load based on workload performance. As a result, BMC AMI Ops Automation for Batch ThruPut delivers intelligent batch processing, optimal system loading and balance, higher service levels, maximized throughput and speed, and reduced MLC charges.

In summary, Control-M for z/OS managed the job submission order, based on scheduling insights, and BMC AMI Ops Automation for Batch ThruPut controlled the job execution order, based on real-time environment insights.

However, the customer still faced a critical challenge. Their month-end close jobs, submitted by Control-M for z/OS with high priority order, were not being selected for execution with the same priority. BMC AMI Ops Automation for Batch ThruPut can give precedence to other Control-M daily jobs or even ad hoc workloads or online workloads, based on its prioritization criteria. But it doesn’t have visibility into the scheduling view and information such as when jobs need to start and complete to meet SLAs, or their average duration.

Better together

Instead of having to build a lot of cumbersome (and difficult to scale) code logic to check both BMC AMI Ops Automation for Batch ThruPut and Control-M for z/OS for priorities, the products’ integration does this for the customer automatically. The scheduling logic built in Control-M for z/OS is leveraged by BMC AMI Ops Automation for Batch ThruPut to drive intelligence in real-time execution of jobs.

In addition to real-time environment load levels, BMC AMI Ops Automation for Batch ThruPut now has visibility to SLA business requirements to prioritize workload execution most effectively, respecting business priorities and infrastructure constraints. It defers or anticipates the execution of workloads depending on real-time system loads, resource availability, and CPU consumption, plus scheduling needs and SLA impacts.

This helps the customer optimize workload performance based on business service levels and real-time resource utilization, ultimately:

• Ensuring critical business services are delivered on time, every time
• Providing executives accurate, timely monthly financial close data
• Reducing costs through optimized mainframe performance

What Control-M for z/OS and BMC AMI Ops Automation for Batch ThruPut can do for you

The integration between Control-M for z/OS and BMC AMI Ops Automation for Batch ThruPut helps companies optimize mainframe performance by syncing business requirements with real-time resource utilization and system load data. The result? You get more efficient, cost-optimized batch workload and SLA performance, and improved resource utilization.

Want to learn more? Check out these great resources:

• Fact Sheet: BMC AMI Ops Automation for Batch ThruPut : Modernized Batch System Management
• Webpage: Control-M for Mainframe

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.