The industry has spent the last two years proving agents can “think.” The next few years will be about proving they can operate reliably.

Depending on who you ask, agentic fabric (sometimes called agent fabric, agentic control plane, or agent control fabric) is either a meaningful architectural idea or the latest label attached to AI agents.

The most useful conversations are happening among platform teams, IT operations leaders, architects, and automation professionals asking: What happens after agents move from experiments to production? What does it take to operate hundreds or thousands of them reliably and securely?

That’s where the discussion quickly moves from what agents can do to how they’ll be operated.

What Do People Mean by “Agentic Fabric”?

Agentic fabric is best understood as an architectural concept, not a product, platform, or framework.
In practice, the term describes the layer that connects, coordinates, governs, and observes AI agents as they interact with systems, data, tools, and each other.

Strip away the terminology and it’s an effort to create a control plane for agents. A way to:

• Connect agents to systems and data
• Govern what they can and can’t do
• Coordinate work across multiple agents
• Monitor actions and outcomes
• Maintain accountability when agent-driven decisions affect business operations

Agentic fabric is giving a new name to a challenge IT teams have been dealing with for decades: coordinating increasingly complex systems in a way that’s reliable, secure, observable, and scalable.

Whether the label lasts is beside the point. The underlying operational challenges are real and arriving regardless of what we call them.

Agentic Fabric vs. Orchestration

At this point, some of you may be thinking: Isn’t this just orchestration?

It’s a fair question and, in some cases, a fair criticism. Many products being marketed as agentic fabric are fundamentally orchestration platforms, workflow engines, integration layers, or governance tools wrapped in AI terminology.

At the same time, it’s hard to talk about agentic fabric without talking about orchestration. The difference is that agent discussions tend to surface a broader set of operational questions around governance, identity, accountability, lifecycle management, and shared context, particularly as agent populations grow.

What’s Interesting About Agentic Fabric?

Agentic fabric is getting attention because agents are increasingly interacting with tools, data, business systems, and each other, expanding the range of what’s possible.

• Specialized agents are becoming practical

We can now realistically envision operations agents, customer service agents, finance agents, software delivery agents, and data analysis agents working alongside human teams, each focused on specific domains and responsibilities.

Agents are starting to mirror the environments they’re entering, acting as specialized systems performing specialized functions as part of larger processes.

• Multi-agent workflows are moving beyond theory

Teams are implementing workflows where agents coordinate work, access different tools, and participate in larger business processes. What’s interesting is that we’re beginning to structure business processes around that collaboration.

• Agents are becoming platform consumers

Platform teams are used to building services for developers, operators, SREs, and business users. Now they’re designing for another consumer: agents.

As agents become participants in operational systems, familiar questions surface:

• How do they authenticate?
• What permissions should they have?
• How are policies enforced?
• How is their behavior observed?

The idea of agents as platform consumers may be one of the more underappreciated discussions happening now.

These three developments are interesting because they expand the range of work agents can participate in and the number of systems they can interact with. But they’re still largely conversations about capability and possibility.

The next challenge is operational.

What’s Important About Agentic Fabric?

What makes agentic fabric important is how the idea shows up in real operational requirements and solution capabilities that move agents from isolated interactions into business operations.

Powerful models and capable agents are increasingly accessible. As intelligence becomes commoditized, the differentiator is execution: the ability to deploy, coordinate, and govern agents across systems, workflows, and teams in a reliable, secure, and scalable way.

If control, not intelligence, is becoming the differentiator, agentic fabric solutions should:

1. Help agents contribute to outcomes, not just tasks

A customer issue might require data collection, analysis, approval, escalation, and action across multiple systems. A software delivery process might involve testing, validation, deployment, and notification workflows.

In practice, that means breaking larger objectives into smaller tasks, routing them to specialized agents or systems, and adapting when something doesn’t go according to plan.

An agent’s ability to perform a task is only the starting point. What’s important is enabling multiple agents to contribute to a broader process without manual coordination between steps.

2. Give agents access without giving up governance

Agents need access to applications, APIs, databases, knowledge sources, and business systems to be useful. But we don’t want them operating with uncontrolled access. Standards like MCP make connections easier to establish, but they don’t replace policy enforcement, monitoring, and accountability.

What’s important is that those connections can happen inside existing security and governance frameworks rather than forcing teams to invent an entirely new operating model for AI.

3. Bring agents into the operating model

If an agent can take actions on behalf of the business, questions like ownership, authorization, and accountability become unavoidable:

• Does the agent have the right amount of resources available?
• Are we able to recover from transient failures?
• Can the agent handle an increase in request throughput?
• Can we pause the agent if we need to verify inputs?
• Can we rollback to a previous version of this agent?

Those questions need to be part of the operating model, not something we sort out after deployment.

4. Make agent behavior visible enough to trust

If an agent makes a recommendation, takes an action, accesses a system, or triggers a workflow, we need to understand what happened and why. That means being able to see prompts, decisions, tool calls, workflow execution, and outcomes. The more autonomous agents become, the more valuable that visibility becomes.

Taken together, these capabilities help move agents from experimentation to production.

What’s Immediate About Agentic Fabric?

The immediate issue is that agents are starting to enter production environments faster than many teams can inventory and govern them as a population. That creates two practical challenges now: discovering where agents are showing up, and maintaining operational control as their number, scope, and interdependence increase. A call for preparation, not panic.

Agent sprawl is becoming harder to ignore

Your organization may already have more agents than you realize. Agents are arriving through Microsoft Copilot environments, SaaS platforms, internal development teams, departmental initiatives, third-party solutions, and embedded AI capabilities.

Before we can manage agents, we need to be able to find them. While most teams can inventory applications, infrastructure, and workflows, fewer can say how many agents are operating in the environment today.

Complexity is the real challenge

As agent populations grow, teams will need to manage conflicting actions, dependencies, permission drift, ownership ambiguity, tool contention, workflow failures, escalation paths, and audit requirements.

None of these are unique to AI. Enterprises have spent decades managing dependencies, permissions, failures, ownership, and coordination across applications and workflows. What’s different is that those dependencies now involve software participants that can make recommendations, invoke tools, initiate actions, and interact with one another without direct human involvement.

Consider the progression: a single agent can be reviewed manually. Ten agents begin to affect workflows. Hundreds of agents interacting with systems, data, workflows, and other agents require a stronger operating model.

What’s the Control Plane for Agents?

The industry has spent years building control planes capable of coordinating applications, infrastructure, workflows, and data pipelines at scale. It’s hard to see most of us standing up a separate operating model just to manage agents.

A more likely outcome is that agents become another participant in the environments we’re already managing, alongside applications, data, infrastructure, and business processes. The practical question is whether existing operational control planes can evolve to incorporate agent-driven work, rather than whether we should introduce yet another operational layer.

That’s where solutions like Control-M come into play. Not as standalone agent platforms, but as a way to bring agent-driven work into the same operational framework teams use to coordinate, govern, and monitor business operations across the broader environment.

See how Control-M operationalizes AI

Evaluating Agentic Fabric: Questions That Matter

As the market fills with products claiming to be agentic fabrics, agent control planes, and multi-agent platforms, leaders should continue to focus on operational capability.

Discovery

• Can you identify all agents operating in the environment?
• Does every agent have a business owner?
• Can unmanaged or “shadow” agents be detected?
• Can you see where agents are interacting with critical systems and data?

Governance

• Are permissions consistently enforced across agents?
• Can agents operate within existing security and identity frameworks?
• Are policies centrally managed and auditable?
• Can access be reviewed and revoked when agents change roles or are retired?

Visibility

• Can actions, decisions, tool calls, and outcomes be observed?
• Can activity be traced across multiple agents, systems, and workflows?
• Is there a complete audit trail when investigators need to reconstruct events?
• Can teams understand why an agent took a particular action?

Coordination

• How does agent-driven work interact with existing workflows?
• Are dependencies managed across agents, applications, and data pipelines?
• What happens when an agent fails, stalls, or produces an unexpected outcome?
• Can human intervention be incorporated when needed?

Data and Context

• How do agents access trusted business data?
• Is access governed and monitored?
• Can context be shared consistently across multiple agents?
• Are business rules and policies applied consistently regardless of which agent is acting?

Scale and Control

• Would the current approach still work if the number of agents increased tenfold?
• What happens when agents begin interacting with other agents at scale?
• Can operational teams maintain visibility and governance as adoption grows?
• What becomes the control plane as agent populations expand?

Agent Lifecycle

• How are agents approved before deployment?
• How are changes reviewed and tested?
• When should an agent be retired?
• How do you verify inactive agents no longer retain access?
• Who is responsible for periodic review of permissions, behavior, and outcomes?

The strongest agentic fabric architectures won’t simply help agents act. They’ll help teams operate large populations of agents with the same discipline already applied to applications, workflows, infrastructure, and data.

Whether we call it agentic fabric, agent orchestration, or a control plane for agents, the job remains the same: maintaining operational control as large populations of agents become part of how work gets done.

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.

“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.