Customers have moved beyond the question of whether to experiment with AI. The question now is more practical: once an AI agent can interact with a production workflow, how do you give it access while maintaining the control and confidence to stand behind the outcome?

That question sits at the heart of the October Control-M release and reflects what we’re hearing across the market. New AI capabilities are easy to introduce. Running them reliably alongside the critical work the business already depends on is the harder challenge. AI’s value doesn’t come from intelligence alone. It comes from connecting that intelligence to governed action across the systems and workflows the business depends on. where orchestration becomes essential.

What teams need in production

This release responds directly to that daily pressure. AI agents, automation, and hybrid environments are now part of how work gets done, and teams need a unified way to bring them into production, rather than creating a second operating model alongside the first.

Intelligence needs to meet people where they work, without compromising enterprise control. Operators need answers in the context of their workflows, while AI agents need governed access to act. And as automation expands, trusted data, secure credentials, and operational resilience must scale with it.

What changes in October

New AI monitoring capabilities help operators investigate jobs and workflows using natural language, turning production context into clear insights on what happened and why.

The Control-M MCP Server is now generally available on Control-M SaaS, providing a governed path for AI agents to interact with Control-M, from accessing job information and logs to taking approved actions, all within existing security, permissions, and audit controls.

Execution is only as reliable as the data behind it. Control-M Data Assurance is now native on Control-M SaaS, embedding data quality checks directly into workflows to catch issues before they propagate downstream and impact critical business outcomes

Security and resilience advance further in this release. Expanded vault support across SaaS and self-hosted environments strengthens secrets management, while Multi-Region Disaster Recovery provides U.S. SaaS customers greater business continuity through regional failover

Managed File Transfer / Enterprise strengthens resilience for self-hosted customers with a centralized database architecture, simplifying high availability, disaster recovery, and failover across sites while expanding database flexibility.

On Control-M SaaS, a refreshed web experience makes monitoring more intuitive and insightful. A new Gantt view brings the day’s workflows into a single visual timeline, making it easier to spot delays, failures, and anomalies in the broader context of how work is progressing.

New integrations extend Control-M orchestration across ERP, cloud infrastructure, containers, messaging, and AI platforms, replacing custom scripts with native connectivity to Oracle JD Edwards EnterpriseOne, AWS Auto Scaling Groups, Argo Workflows, SAP Build Process Automation, IBM MQ, GCP Managed Instance Groups, Amazon Bedrock AgentCore, and Workato.

Together, these advances reinforce a unified approach to enterprise orchestration: greater intelligence for operators, governed access for AI agents, stronger security and resilience, and broader orchestration across the enterprise.

The technology landscape may change, but the need for trusted orchestration does not. As AI moves from experimentation into enterprise operations, Control-M provides the foundation to run critical work with the control, reliability, and flexibility enterprises require.

Read more on the BMC New Product Innovation announcements:  https://www.bmc.com/blogs/delivering-predictable-outcomes-ai-era/

Enterprise IT has spent decades engineering predictability into its systems. Transactions commit or roll back, data pipelines land on time, and a workload that ran last night runs the same way tonight. That consistency is what lets a bank clear a payment and a hospital admit a patient. Predictability is the product.

AI is the first technology we’ve deployed at enterprise scale that behaves differently. Give a model the same input twice and it may reason its way to two different, equally defensible answers. That property is precisely what makes AI valuable on problems deterministic software was never built to solve, and it’s also what makes AI hard to operate inside businesses that have organized themselves around certainty.

The capability question is settled. What enterprises are working out is how to embed non-deterministic AI inside processes built on certainty. An agent belongs in production when the work it was given completes, the evidence behind its decisions is visible, and a person can still intervene. Agentic AI governance is what now stands between a promising pilot and a production deployment.

Enterprise AI stalls on complexity

IDC projects its Global DataSphere will surpass 700 zettabytes by 2030.[1] Google alone now processes more than 3.2 quadrillion AI tokens a month, up from 9.7 trillion two years earlier.[2] Nearly three-quarters of organizations operate hybrid cloud environments.[3] And our own research finds 94 percent of organizations still treating the mainframe as a long-term platform or a home for new workloads.

Enterprises have managed the data platform, the hybrid estate, and the mainframe as separate programs, each with its own owners and controls. An AI agent placed inside a business process crosses all three domains in a single execution path. A process that once touched three systems now spans enterprise applications, data pipelines, public and private cloud, the mainframe, and a growing population of AI agents.

Our customers cite four primary concerns about scaling AI: data quality and fragmentation, the operational demands of new AI workloads, tool sprawl across hybrid environments, and the gaps between the mainframe and everything around it. All four concerns predate agentic AI, and agents compound each one by multiplying connections faster than organizations can govern them.

Orchestration restores predictability

An AI agent determines its course of action each time it runs, so two attempts at the same incident can follow unique paths to a diagnosis. But the agent doesn’t execute its own proposals. Orchestration decides whether to permit the action, sequences it against work in flight, and records the result, and agentic AI governance enforces identity, scope, approval, and audit at that moment. A policy document works only if someone reads and follows it. Policy enforced in the execution path applies to every agent, every time, regardless of which team built it.

Enterprises already own orchestration built for their most critical workloads. Extending it to AI is faster and less expensive than standing up governance separately inside every AI project.

Any capable team can now assemble an agent that retrieves information, calls tools, and finishes a defined task. The difficulty sits around the agent, in giving it access to live operational context, a supported way to act, and an owner when conditions change. A customer’s own agent can run inside those same controls, and it should.

Three outcomes determine whether that extension succeeds: scalability, so automation grows with the business; operational resilience, so disruption stays contained and recoverable; and trust and confidence, so teams can explain and defend what their systems did. The work we’re announcing across our portfolio maps to these outcomes.

Governance must hold across every workload

Consider loan origination. Intake, processing, underwriting, decisioning, booking, funding, and servicing have long been orchestrated across a chain of enterprise systems. In the agentic version of that same process, several of those stages are handled by AI agents and AI orchestrators sitting alongside custom applications, real-time & batch data exchange, and traditional systems. The business process stayed the same while the mix of systems executing it changed. An agent in that chain matters for its effect on whether the process finishes, along with the dependencies, exceptions, and service levels around it.

That’s co-orchestration of mixed workloads: deterministic tasks and non-deterministic agents coordinated as one process, with dependencies, service levels, and recovery applied uniformly across both. Without it, agents run outside the system that governs everything else, the same problem enterprises solved when they consolidated unsanctioned scripts and schedulers.

Teams grant agents authority in proportion to what they can verify and reverse, so scope must be concrete. An agent with a defined task and a defined blast radius earns trust faster than one with broad latitude, and the boundary matters more than the capability.

In practice that means starting with a single task, measuring it against how the work runs today, and widening an agent’s remit when the results hold up.

The same holds for the data underneath. An agent reasoning over stale or incomplete inputs will produce a defensible answer from bad evidence, and a well-coordinated process will carry that answer downstream without objecting. Knowing where data came from, whether it’s fit to use, and what depends on it is an operational question now.

The mainframe raises the stakes further. It holds the transactions and the business logic the rest of the enterprise depends on, and the knowledge required to operate it sits with fewer people every year. Governance that stops at a platform boundary isn’t governance. One set of policies must apply across every environment an agent touches, with a single audit path behind it, because governance built separately inside each product becomes as fragmented as the estate it was meant to control.

Three questions decide whether an agent runs

An agent proposes a fix. Three questions come before the action: how far this agent’s reach extends, who extended it, and what undoing the fix would cost.

Those are questions about the system around the agent, and they’re answerable only if the answers were built before the incident. An agent that can explain its diagnosis but not its authority won’t get approval, and it shouldn’t.

This is also why variance is tolerable. The same agent may reach the same conclusion by a different route on a different day, and that costs nothing when every route passes the same checks and leaves the same record. The route becomes a problem only when it decides what the agent was permitted to touch.

Production runs on discipline

The first phase of enterprise AI rewarded experimentation. Production asks a harder question. The number of agents an organization runs says little about whether any of them can be trusted with consequential work. What counts is whether they run inside the same discipline as everything else the business depends on, where work is sequenced correctly and a decision can still be explained months later to an auditor who was never in the room. That is what agentic AI governance does.

Models will change, and so will agent frameworks. The need for critical work to complete predictably will outlast both. A capability that cannot answer those three questions does not belong in the systems that run your business, whoever builds it. Enterprises learned once how to let software act on their behalf without watching every step, and predictability is still the product.

That is why the capabilities we are introducing sit in the execution path. Control-M’s latest release advances AI-ready orchestration that connects AI agents to business workflows, available across both SaaS and self-hosted environments. Control-M’s new AI Pilot capabilities bring conversational analysis and workflow explanations into Monitoring viewpoints, so an operator can understand and resolve an issue in natural language instead of assembling that context by hand. Data Assurance for Control-M SaaS improves the quality of the data a workflow depends on, which matters here because an agent reasoning over unverified inputs will produce a confident answer from bad evidence. And Multi-Region Disaster Recovery protects mission-critical workflows against the one condition no agent can reason its way out of, which is the environment itself failing.

On the mainframe, where both the stakes and the skills problem are sharpest, BMC AMI Agentics for Ops and BMC AMI Agentics for Data put specialized agents to work investigating problems, explaining root causes, and recommending next steps, and bring the same expertise to Db2 performance and optimization. BMC AMI Assistant brings mainframe knowledge and AI assistance directly into Microsoft Teams, because evidence is only useful where the work already happens. New development capabilities go at the skills problem from the other end, generating synthetic test data from a program’s own code to cut cycle time and improve quality. And enriched security context strengthens cyber resilience in the place where disruption is least affordable.

These capabilities run on the systems we have helped enterprises operate for four decades, and that is the ground any claim about dependable AI must stand on. The work now is making predictability hold while the systems inside it begin to reason. For the full release details, explore the What’s New pages for Control-M and BMC AMI.

Explore what’s new:

• What’s new in Control-M
• What’s new in BMC AMI
• 2026 BMC Mainframe Survey

Throughout its history, the mainframe has adapted to every major shift in enterprise computing. The client-server model expanded how applications connect to the platform, and hybrid cloud computing connected it to the broader distributed world.

AI feels different.

Not because it changes how systems connect, but because it changes how people access knowledge, understand what is happening, make decisions, and increasingly, how work gets done.

The question I keep coming back to is not whether AI belongs on the mainframe. That seems inevitable. The more interesting question is what kind of AI organizations will ultimately trust with some of their most critical workloads.

This creates a new opportunity, one to Agentify the Mainframe, ensuring that AI on the platform is grounded in the expertise, context, and governance on which business depends. It means rethinking outdated perceptions and reimagining workflows so that mainframe teams can innovate more quickly while maintaining the resilience, security, and operational excellence that have always defined the platform.

In conversations with customers, I’ve found that the discussion quickly moves beyond AI capabilities. The real conversation is about confidence. Can AI understand operational context? Can it explain its reasoning? Can it act within clear boundaries? These questions have shaped our approach at BMC.

To achieve these goals, the BMC vision goes beyond general-purpose tools that simply access mainframe data. It makes AI mainframe-native with purpose-built AI that brings intelligence directly into the workflow, combining decades of BMC expertise, your organization’s institutional knowledge, and live operational context with infused governance. The goal is not simply to bring AI to the mainframe. It is to extend the value, expertise, and operational knowledge of the mainframe into the broader enterprise AI ecosystem.

In my time with BMC, I’ve seen firsthand the passion our customers have for the mainframe and the critical role it continues to play in their businesses. One thing they have consistently made clear is that the mainframe isn’t going anywhere. They are not looking to replace it. They are looking to optimize it, extend its value, and ensure it evolves alongside the rest of the enterprise.

Agentifying the Mainframe is one way of supporting that evolution. It places the mainframe alongside enterprise AI initiatives while helping organizations scale hard-won expertise across more people and workflows. The result is the ability to onboard employees faster, make decisions more quickly, reduce dependency on a limited number of specialists, and create more capacity for innovation.

In short, Agentifying the Mainframe is about making mainframe expertise more accessible, scalable, and actionable through purpose-built digital workers, increasing confidence and capacity without compromising resilience, security, or control.

How do we make any AI mainframe-native?

If AI is going to earn trust on the mainframe, I believe a few characteristics become especially important.

The BMC vision of Agentifying the Mainframe is defined by six characteristics:

• Mainframe-native expertise that applies specialized mainframe knowledge to critical workflows and decisions.
• Integrated intelligence that connects expertise, institutional knowledge, and live operational context.
• Enterprise openness that securely integrates with enterprise tools, models, agents, and ecosystems.
• Governed execution that applies policy, oversight, transparency, and control to agentic actions.
• Customer data that keeps enterprise data governed by established security, access, and control policies.
• Investment protection that extends existing mainframe, BMC AMI, and enterprise AI investments rather than creating another isolated platform or collection of point solutions.

Each of these characteristics is valuable on its own. Together, they form the basis of BMC’s approach to agentic AI on the mainframe: purpose-built, mainframe-native AI employing specialized agents that understand the context of the workflows in which they operate and coordinate with other agents and tools to extend human expertise by investigating, analyzing, explaining, recommending, and advancing defined work within governed boundaries.

One finding from the 2026 BMC Mainframe Survey particularly stood out to me. As organizations become more familiar with AI, they are not necessarily becoming more comfortable handing over complete control. In several areas, preference is shifting toward AI that recommends actions rather than executes them autonomously.

When asked about AI problem diagnosis, willingness to have AI complete actions fell from 32% to 23% year-over-year, while preference for AI-generated recommendations increased from 36% to 41%.

I don’t view this as resistance to AI.

I view it as a sign that organizations are thinking carefully about where trust belongs.

This suggests that many mainframe leaders see AI first as an advisor, and only later as an autonomous executor.

Agentifying the Mainframe addresses this need with governed boundaries and human-in-the-loop controls, creating a trusted advisor that assists mainframe professionals and enhances their work rather than replacing them. Organizations may eventually choose higher levels of automation, but trust must precede autonomy.

In my experience, organizations rarely become comfortable with automation all at once. Confidence is built gradually, one successful interaction at a time.

The appropriate level of autonomy will always depend on workflows, risk, and governance requirements. Organizations should be able to expand AI responsibility as trust grows and business needs evolve, while maintaining the oversight required for critical operations.

Governance by Design

The BMC approach includes governance embedded directly into the operating model itself, rather than bolted on later as an additional feature or service.

It is governance by design, practiced across four pillars: agent performance, resource utilization, policy compliance, and auditable activity tracking.

Here, too, a human-in-the-loop approach remains important. Human oversight is incorporated wherever intervention or approval is required. With this governance foundation, mainframe-native AI can move thoughtfully from intelligence to action.

Making It Real

Ideas only matter when they improve the way people work.

That is why we have focused on bringing these concepts into practical workflows today.

Agentifying the Mainframe is not simply a future vision. BMC is making it a reality through new BMC AMI Agentics offerings. These solutions use agents to investigate, analyze, explain, recommend, and help move defined work forward.

Rather than replacing operators, developers, or data professionals, these capabilities are designed to help them investigate faster, understand complex situations more clearly, and move work forward with greater confidence.

BMC AMI Agentics for Ops uses purpose-built agentic workflows that advance defined operational investigations, explain findings, and recommend next steps for proactive anomaly detection and AI-guided root-cause analysis, helping teams investigate faster and act with confidence without leaving their workflow. Agentic CPU investigation in BMC AMI Ops Monitoring increases the speed with which operations teams can investigate CPU spikes; incorporation of agentic AI into BMC AMI Ops Insight provides Db2 probable cause insights and recommends next steps; and a new explain agent within BMC AMI Ops Automation explains REXX scripts in plain language to help operators understand existing automation scripts more quickly, especially when the original authors or subject matter experts are not available.

BMC AMI Agentics for Data uses AI agents to investigate database issues, explain findings, and guide optimization. AI Reorg Advisor adds a new agentic workflow to BMC AMI Utilities for Db2®, which investigates REORG indicators and custom criteria, then explains recommendations in plain language. The SQL Workload Advisor explains application and SQL performance and recommends tuning actions.

AI-Assisted Application Development

Making AI mainframe-native also means rethinking how developers work.

With the new BMC AMI DevX Code Pipeline MCP server, now in beta, developers can connect familiar AI coding assistants such as Cursor, GitHub Copilot, and Claude Code to mainframe build and deployment processes.

Instead of treating the mainframe as a separate development environment, we are making it part of the AI-assisted workflows developers increasingly use every day.

The goal is simple: allow developers to use the tools they already know while making the mainframe a natural part of the modern development experience.

A Vision of Agentifying the Mainframe

System complexity continues to grow, and so does the pressure to innovate faster. As AI adoption accelerates across the enterprise, expectations are increasing while specialized mainframe expertise remains limited.

For me, that is the real opportunity behind Agentifying the Mainframe.

Combining mainframe-native expertise, integrated intelligence, enterprise openness, and governed execution can help organizations make AI more useful, more trusted, and more closely aligned with the realities of enterprise operations. The outcome is not simply greater automation, but greater capacity, resilience, and confidence.

As AI continues to evolve, I believe the most important question is not how quickly organizations can introduce intelligence into their systems.

It is how thoughtfully they do so.

The mainframe has earned trust over decades because of its reliability, resilience, and ability to support business processes that matter most.

As we enter the agentic era, those qualities become even more important.

In many ways, Agentifying the Mainframe is not about changing what makes the platform valuable.

It is about extending those strengths into a new generation of human and AI collaboration.

Learn more about BMC’s vision for agentic AI on the mainframe on the Agentic Mainframe page of BMC.com.

See all of the new features included in the October release of BMC AMI enhancements on the What’s New in Mainframe Solutions page.

Read more about BMC’s approach to agentic AI governance in Delivering Predictable Outcomes in the AI Era, by Chief Technology Officer Ram Chakravarti.

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.