SAP landscapes have become considerably more complex than the tools most teams use to automate and optimize how heavy backend workloads run.
A decade ago, background job scheduling was a contained problem. SM36 and SM37 handled ERP processing, local schedulers covered the rest and the architecture those tools were built for was largely self-contained.
That architecture is gone for most enterprises. A single business process now routinely spans SAP S/4HANA, SAP Cloud ERP, SAP Business Technology Platform (BTP), SAP Business Data Cloud (BDC), SAP Analytics Cloud, Databricks, Snowflake, AWS … and the list goes on … before producing a result anyone can act on. Each platform executes reliably within its own boundary. Whether the process completes reliably across all of them is a problem local scheduling can’t solve.
To answer the question, “How does this job impact the entire business chain?” SAP architects must differentiate between simple task scheduling and true enterprise orchestration.
When local scheduling remains the right call
Native scheduling tools are legitimate architectural choices, not placeholders until something better comes along. For isolated, self-contained tasks with no upstream dependencies and no downstream impact — and where advanced or variable calendaring handles any scheduling complexity — they’re often exactly what the job requires.
Across a modern SAP estate, that means:
SM36 and SM37 for standard background processing in SAP S/4HANA and SAP ECC: batch jobs, reports and ABAP programs that live entirely within a single ERP instance and don’t depend on external system state
SAP BTP Job Scheduling Service for Cloud Application Programming (CAP) model applications running on SAP BTP Cloud Foundry: time-based or one-time job execution for CAP services that operate independently within the SAP BTP environment
Application Jobs for RESTful ABAP Programming (RAP) model extensions on SAP S/4HANA: the metadata-driven, Fiori-integrated successor to SM36/SM37 for modern ABAP development, appropriate when the job scope stays within the SAP S/4HANA system boundary
Native scheduling within SAP Integrated Business Planning (IBP), SAP SuccessFactors and SAP Digital Manufacturing: purpose-built schedulers for localized workloads inside those solutions, where cross-system coordination isn’t required
Built-in schedulers in Snowflake and Databricks for internal scripts and transformations that begin and end within those platforms
The common thread is isolation. Each of these tools executes reliably when the task it governs doesn’t depend on the state of another system and doesn’t need to trigger work in one.
Trigger points: When traditional scheduling becomes operational risk
Three conditions reliably signal that native scheduling is no longer sufficient.
The job becomes a link in a cross-system chain. As soon as a task has an upstream dependency outside its own platform or triggers a downstream action in another system, local schedulers start operating on assumptions. For a material requirements planning (MRP) run that depends on an external warehouse feed completing first, a Datasphere refresh that needs to finish before SAP Analytics Cloud models publish or a CAP service on SAP BTP that should only execute after an upstream SAP S/4HANA job confirms success, native schedulers in each of those systems can only confirm that their own job ran. None of them can verify the state of the system that the next step depends on.
You need resource-aware, resilient execution. High-concurrency workloads like SAP Datasphere task chains, Databricks pipeline runs and overnight batch sequences across multiple platforms require load balancing, automated retry logic and intelligent error handling. Without a coordination layer, a single failure can cascade across dependent processes before anyone is notified.
Your roadmap involves eliminating operational blind spots.RISE with SAP and clean core transformations distribute process logic across SAP BTP services, cloud extensions and non-SAP platforms. That distribution improves architectural flexibility and creates a new operational problem: no single view of what’s running, what’s waiting and what failed across the landscape. Each platform reports on itself, but nothing reports on the process.
Governed execution in practice
RunMyJobs by Redwood is designed to take over at the boundary where native scheduling capabilities end. Rather than replacing SM36/SM37, Application Jobs or the SAP BTP Job Scheduling Service, it coordinates them — along with every other system in the landscape — into governed, end-to-end process flows. Workflows execute based on verified event completion and real-time system state, where a downstream process starts because the upstream transformation succeeded, not because a timer reached a predetermined hour.
The difference a dependency makes
Scheduling
Orchestration
Runs isolated tasks
Coordinates end-to-end business processes
Time-based execution
Event-driven, latency-aware execution
Local system visibility
Cross-platform visibility
Static, assumed dependencies
Dynamic, verified dependencies
Reactive troubleshooting
Centralized operational intelligence
RunMyJobs’ out-of-the-box connectors span SAP S/4HANA, SAP BTP, SAP BDC, SAP Datasphere, SAP Analytics Cloud, SAP Cloud ALM, SAP Build Process Automation, Databricks, Snowflake, AWS and ServiceNow, making cross-platform dependency management possible without custom code.
For RISE with SAP and SAP Cloud ERP environments, RunMyJobs connects through its Secure Gateway and agentless architecture, consistent with how SAP Cloud Connector operates. It’s the only workload automation and orchestration platform included in the RISE with SAP reference architecture. With no agents inside the ERP and no custom ABAP, RunMyJobs supports clean core principles from the start.
Coverage extends across the full range of modern SAP development models: Application Jobs, RAP-based extensions, CAP services on SAP BTP, SAP Datasphere pipelines, SAP Integration Suite workflows and AI-driven scenarios involving Joule.
Job requirements decision tree
Build the control layer before you need it
Most teams introduce enterprise orchestration after complexity has already compounded — after the first SLA breach that took half a day to trace, the planning run that produced results on incomplete data or the migration that left three separate scheduling tools running in parallel with no consolidated view across them.
Getting ahead of that inflection point is considerably easier than resolving it afterward. Teams that introduce RunMyJobs early in their RISE with SAP journey retire legacy schedulers, establish governed dependency management and build a control layer that scales with the architecture from the start.
SAP’s native tools still do what they were designed to do, while orchestration governs what happens between them.
Think about programming a destination into a GPS before the roads to get there are fully built. The route looks clear on screen and the technology is working exactly as designed. But somewhere along the way, the path runs out, and you’re left improvising.
That’s a fair comparison to where many manufacturers are in their efforts to achieve autonomous SAP production planning right now. The destination is well defined: AI-driven production scheduling that anticipates disruptions, adjusts in real time and executes across SAP and connected systems without constant manual intervention. Investments and roadmap conversations are happening. SAP Cloud ERP has the capabilities, and the SAP Production Planning (PP) module continues to evolve.
But according to Redwood Software’s “Manufacturing AI and automation outlook 2026,” roughly 98% of manufacturers are exploring or preparing for AI-driven automation, whereas only about 20% consider themselves fully prepared to execute on it.
The destination is there, but the path hasn’t been cleared. Here’s what’s in the way.
1. Production data is still fragmented across systems
SAP production planning is only as accurate as the inputs feeding it. Demand signals, inventory positions, quality results and MES outputs all need to arrive consistently and on time. In most manufacturing environments, those sources still live in separate systems that weren’t intended to share data automatically.
Around 20% of manufacturers identify a lack of integration across ERP, MES and PLM as a direct bottleneck. That number likely understates the problem, because partial integration — where connections exist but data quality or timing is inconsistent — can be just as limiting as no integration at all. Planning in SAP operates on whatever it can see. When visibility is incomplete, the plan reflects that.
2. Manual exception handling breaks the automation loop
Production rarely runs exactly as planned. Equipment fails, suppliers miss windows and quality deviations surface mid-run. Those disruptions need a response, and right now, for most manufacturers, that response is a person.
Only about 40% of manufacturers have automated exception handling. The other 60% rely on teams to identify, triage and act on disruptions, then manually update the systems involved. That process takes time, creates gaps between what happened and what SAP knows about it and makes closed-loop planning effectively impossible.
If exceptions are the moments that matter most in production, automating around them while leaving the exceptions themselves to manual workflows puts a ceiling on how autonomous your planning can get.
3. Planning cycles are batch-driven, not event-driven
Traditional SAP environments run planning jobs on schedules: nightly MRP runs, periodic capacity updates, batch refreshes of demand data. That made sense when the alternative was manual. It doesn’t make as much sense when production conditions are shifting continuously throughout the day.
A schedule change, a material shortage or a machine coming back online are things that happen in real time. Planning tools that update on a cadence can’t reflect them until the next cycle runs. By then, decisions downstream have already been made on outdated information.
Autonomous planning assumes the system responds to events right when they happen. Getting there requires moving from time-based job scheduling to event-driven orchestration, where a change in one system triggers the right response across all the connected ones, immediately.
4. Forecasting inputs are inconsistent and disconnected
Accurate production planning in SAP starts upstream, with the demand forecasts and signals feeding into it. When those inputs come from disconnected sources, arrive on inconsistent schedules or require manual reconciliation before they’re usable, the planning outputs reflect the same uncertainty.
Roughly 24% of manufacturers cite forecasting accuracy as a major supply chain bottleneck. What’s often behind that number isn’t the forecasting model itself, but the data reaching it. Disconnected demand signals, late updates from commercial systems and cross-functional coordination done via email rather than integrated workflows all degrade forecast reliability before any planning algorithm runs.
You can’t optimize what you can’t trust.
5. Skills and ownership of automation are unclear
Autonomous production planning sits at the intersection of SAP configuration, systems integration, process design and operational knowledge. That’s a lot of ground for any one team to cover, and in practice, it tends to fall awkwardly between IT and operations. It’s not owned by either clearly enough to move fast.
About one-third of manufacturers cite a skills gap in advanced automation technologies as a barrier to progress. This points to organizational structure rather than a lack of talent. When automation initiatives require coordination across multiple teams and knowledge domains, momentum slows. People spend cycles on alignment that could go toward execution. The work that needs to be done is clear; who’s accountable for doing it often isn’t.
This is one of the more underestimated barriers. Technical complexity gets a lot of attention, but organizational complexity doesn’t get enough.
6. Change management feels riskier than the status quo
Production-critical processes carry a particular kind of weight. When something touches the line, the tolerance for disruption is low. That’s a reasonable instinct, and it’s also one of the reasons autonomous planning initiatives stall.
Around 22% of manufacturers cite retraining teams and change management as barriers to adopting new automation approaches. Shifting how planning decisions get made, how exceptions get handled and how workflows are structured touches roles and habits that teams have built over years. Even when the destination is clearly better, the path there feels uncertain.
The organizations making progress have found ways to reduce that perceived risk: starting with contained workflows, building confidence incrementally and showing teams how the changes work before asking them to trust them at scale. Incremental adoption isn’t a compromise. It’s often the only path that actually holds.
7. Perceived integration complexity causes teams to stall
SAP production planning doesn’t operate in isolation. It touches finance, procurement, warehouse management, quality systems and shop floor execution. Making planning more autonomous means those connections need to work reliably, not just for the data going into SAP but for the actions coming out of it.
About 24% of manufacturers cite system integration concerns as a primary barrier to automation progress. That’s not surprising when you consider what the integration surface generally looks like, with multiple SAP modules, third-party platforms, cloud environments and on-premises systems, all of which need to stay in sync as planning decisions cascade through them.
The perceived complexity here often leads to underinvestment. Teams assume the integration work will be costly and disruptive, so they defer it. What they’re deferring is the connective tissue that autonomous planning depends on.
Autonomous planning is closer than it seems
These seven challenges share a common thread. None of them is about SAP being insufficient. And none of them is about AI not being ready. They’re about the data pipelines, production processes and connections — the roads — not yet being ready to support autonomous operations end to end.
Organizations that have worked through these gaps by connecting data sources, automating exception responses, replacing scheduled MRP run cycles with event-driven triggers and clarifying ownership of automation are already seeing measurably better resource utilization and operating at higher levels of automation maturity. When infrastructure catches up to ambition, autonomous production planning stops being a future goal and starts being next quarter’s project.
RunMyJobs by Redwood has been providing this kind of deterministic orchestration infrastructure for manufacturers for years — the event-driven workflows, cross-system coordination and purpose-built SAP integrations that make autonomous planning operationally possible. Think of it as the paving crew that’s already been at work: many Redwood customers are already running production environments where planning responds to real conditions rather than scheduled cycles. The roads to autonomous operations are more built out than most teams realize.
The “Manufacturing AI and automation outlook 2026” examines where manufacturers stand across all of these dimensions: where the gaps are, what separates early adopters from those still in early stages and what the path forward looks like for organizations at different points in the journey.
Download the report to see how other manufacturers are approaching the shift to autonomous, AI-driven operations.
There’s a pattern I keep seeing in technology. It’s a common one in everyday life, too: fix the part people can see and leave the part they can’t alone. You repaint the house and ignore the foundation. Then, when something goes terribly wrong, everyone acts surprised. I’ve watched this play out across enough technology cycles — client-server to web, web to cloud, on-premises to SaaS — that at this point it’s less a surprise and more a kind of grim recognition.
Customer onboarding in financial services is one of the most consequential places this pattern is playing out right now. Financial institutions have invested heavily in the onboarding experience with cleaner application flows, faster identity verification, biometric authentication and near-real-time decisions. The digital customer onboarding process feels faster, more intuitive and closer to the frictionless experience customers expect. And they notice that, so completion rates and customer acquisition have increased in many cases. The onboarding journey looks like a success.
But the process doesn’t end at submission. In fact, that’s where the risk starts to build.
Encompass Corporation’s 2025 research found that 86% of organizations have already reported direct financial losses from lengthy or complex onboarding journeys. Yet the factor most responsible for that complexity — the automation coordinating workflows, compliance checks and account opening across systems — often remains fragmented, legacy-driven and difficult to change.
In most financial institutions, there’s no single system coordinating the end-to-end onboarding process. Execution is split across legacy workload automation tools, point solutions and manual handoffs. As digital onboarding accelerates, that disjointed model increases the likelihood of exceptions, inconsistencies and compliance risk.
The gap between “approved” and “done”
What looks like a single step in a digital onboarding process is anything but simple. When a new customer submits an application, a chain of dependent actions begins: identity verification, Know Your Customer (KYC) and Anti-Money Laundering (AML) checks, risk scoring, data validation and account opening across multiple systems. Some run in the cloud, some on-premises and many through third-party providers. Every step has to complete correctly and in sequence for the outcome to be trustworthy.
In most financial institutions, that coordination isn’t unified. It’s split across application, data and infrastructure technologies and tools, stitched together with APIs and custom integration scripts and often reliant on legacy, batch-driven automation that assumes everything runs on time.
A customer can be “approved” in seconds while a compliance check completes minutes later — or fails without any immediate indication. An account can be opened in one system but not fully set up in another. No one notices that the underlying customer record is lacking because speed masks the inconsistency, at least for a little while.
Speed exposes what wasn’t built to scale
Onboarding workflows weren’t designed for the speed they’re now expected to support. At lower volumes and longer timelines, gaps between systems were manageable. That buffer is gone. Now, thanks to “born-in-the-cloud” digital competitors, customers are more used to and demanding of a real-time app experience. If a customer can be approved while a compliance check is still in progress, and their data moves forward before it’s fully validated, the compliance risks compound — and at scale, they get expensive.
As digital onboarding accelerates, exceptions multiply, meaning more rework, more investigation and more pressure on operations teams to resolve issues after the fact. In a regulated onboarding process, every KYC, AML and compliance step must execute correctly, in order and with proof.
Most financial institutions still rely on self-hosted, legacy workload automation or batch scheduling to hold this process together. The infrastructure costs are visible in servers, upgrades and maintenance support. But the bigger impacts are harder to quantify and often overlooked: the human resource costs of manual remediation, the customer impact of delayed onboarding outcomes and the growing regulatory risk exposure from workflows that don’t execute consistently.
The total cost of ownership (TCO) and opportunity cost have increased, driven not just by infrastructure, but by the growing costs of change, delayed modernization and the effort required to keep inconsistent workflows running.
Turning onboarding into a system you can trust
A modern application and data pipeline orchestration platform changes how onboarding executes. It’s purpose-built for hybrid environments, delivered as SaaS and designed around event-driven execution.
Workflows move when something actually happens — a KYC result returns, a document is verified, a risk score is issued. Steps don’t progress until the required conditions are met. When something fails, it’s isolated and visible instead of cascading across the process.
Instead of drifting out of sync as volume increases, workflows stay aligned. Instead of relying on manual intervention, execution is consistent by design, and errors and failures are remediated automatically. And instead of reconstructing what happened after the fact, every step is tracked as it happens to meet the most difficult compliance requirements with ease.
That last point is what shifts onboarding from an operational concern to a control point. When a regulator asks whether a specific AML check was executed correctly, the answer comes directly from the system, and it’s complete, ordered and auditable. There’s no gap between what was supposed to happen and what you can prove happened.
How you reduce risk: Orchestration control
RunMyJobs by Redwood is built to operate in exactly this environment. As a cloud-first, SaaS Service Orchestration and Automation Platform (SOAP), RunMyJobs replaces self-hosted legacy infrastructure with a fully managed platform delivering 99.95% uptime, frictionless connectivity and event-driven execution across hybrid onboarding architectures.
It doesn’t require you to rebuild onboarding from scratch. It gives you control over how it runs, enabling:
Fewer exceptions and less manual remediation
Lower infrastructure and maintenance overhead
Faster, more reliable onboarding outcomes for new customers
Stronger, provable control over compliance workflows
RunMyJobs connects on-premises systems and modern cloud platforms without requiring you to rearchitect stable workflows that already run reliably, enforces consistent sequencing across KYC, AML, identity verification and account provisioning and gives compliance and operations teams end-to-end visibility across every dependency. UBS cut costs by 30% and replaced 16 applications by consolidating onto a modern SaaS orchestration layer.
When you move mission-critical application and data workflows from fragmented, legacy workload schedulers to a modern, hybrid cloud orchestration platform, you can innovate faster, eliminate technical debt and — as an added bonus — you stop paying the hidden tax of maintaining infrastructure that’s working against your transformation goals.
The investment case is straightforward
The real cost of fragmented onboarding orchestration isn’t on anyone’s budget. It’s spread across server infrastructure, upgrade cycles, operations headcount absorbing exceptions that shouldn’t exist, compliance remediation triggered by workflows that can’t prove what they did and modernization projects perpetually delayed because the team is too busy keeping inconsistent processes running.
Digital onboarding can scale with less risk. But if your exception rate is climbing alongside your completion speed, a better application form won’t fix it.
See how RunMyJobs can bring reliable, efficient orchestration to your onboarding environment.Book a demo.
Retail has changed faster in the last five years than in the previous 20. Unified commerce, same-day fulfillment, dynamic pricing, loyalty programs sophisticated enough to feel genuinely personal — these aren’t competitive differentiators anymore. They’re the baseline.
What hasn’t kept pace is the infrastructure making it all run.
Underneath most large retail operations sits a collection of scheduling tools, batch processes and integration scripts that accumulated over years of platform additions, acquisitions and tactical decisions. None of it was designed with unified commerce in mind, because unified commerce didn’t exist when most of it was built. And now it’s the foundation that real-time retail is running on.
The omnichannel promise has a back-end problem
Your customers don’t think about systems. They think about whether the promotion they saw online applied at checkout, whether the item that showed as available for in-store pickup was actually there when they arrived and whether the loyalty points from last weekend’s purchase showed up before the offer expired.
What they experience as a seamless retail interaction is, behind the scenes, a chain of scheduled and event-driven jobs, batch processes and file transfers running across systems that weren’t designed to talk to each other. That interaction depends on a pricing update that ran overnight and actually reached every channel. On a replenishment batch that finished before the procurement window closed. On order routing logic threading through eCommerce, warehouse and store systems fast enough to mean something. Most of the time, it works.
The problem is that “most of the time” is doing a lot of heavy lifting. When the chain holds, nobody notices. When it breaks, the customer finds out before IT does. The failures aren’t visible, and they’re almost always downstream from automation that wasn’t built to operate as a connected whole.
What’s running underneath retail
Most large retailers are managing a fragmented set of legacy and application-native schedulers accumulated over years of platform additions, acquisitions and tactical decisions. The fragmentation itself isn’t the biggest issue. But what does it mean for specific retail operations and workflows?
Pricing and promotions are where timing risk is most visible. Retailers run thousands of price changes weekly across promotional batches, markdown schedules and flash sale activations — all dependent on jobs running in sequence with no real tolerance for delay. When one slips, the chain slips. The customer finds out at the register.
Inventory and replenishment carry a different kind of exposure. Replenishment cycles depend on forecasting batches completing before procurement windows close, but fragmented tools give no unified view of whether that actually happened. Poor inventory management means stock sitting in the wrong location while the right locations run dry — and inventory levels that don’t reflect what’s actually on the shelf. The data to prevent stockouts exists.
The gap between retailers who have solved this and those who haven’t is measurable. nShift research found that only 17% of retailers consider their omnichannel logistics mature, and those in the top tier with truly unified back-end operations achieved 31% lower fulfillment costs and 24% higher customer satisfaction. The operational advantage of a connected back end isn’t theoretical. It shows up in the numbers.
Order fulfillment is where the complexity compounds. Buy online, pick up in store (BOPIS), ship-from-store and same-day delivery aren’t one process in most retail environments. There are three or four integrated, event-driven workflows running in sequence across eCommerce, warehouse management systems (WMS) and store systems, monitored across separate tools, with no single view of end-to-end completion. The customer doesn’t get an error if something fails. They just get a missed pickup window.
Loyalty processing fails the quietest. Point calculations and offer distribution run as scheduled jobs across customer relationship management (CRM) and transaction systems. Late runs mean points that don’t appear and offers that expire before they apply. No single failure is dramatic, but the cumulative erosion of customer satisfaction is.
Peak season: A stress test the infrastructure wasn’t built for
Black Friday and Cyber Monday are when fragmented retail automation becomes a genuine operational crisis. Promotional batches, inventory syncs and order routing all spike simultaneously across tools configured for average load, not peak load.
The response is almost always manual intervention. IT teams staffing war rooms during holiday events aren’t a sign of operational maturity. They’re a sign that the automation layer can’t hold without human backup.
Holiday 2025 made that visible at scale. Retail Insider’s post-mortem on the season described how peak volumes broke legacy systems lacking real-time data capabilities. Inventory inaccuracies and overwhelmed warehouses created cascading operational failures across retailers that had no unified view of whether end-to-end processes were on track.
Peak is no longer seasonal, either. A major loyalty event or flash promotion can produce holiday-level processing demand on a random Tuesday. With no unified view across tools, teams are watching multiple monitoring consoles and making judgment calls about whether a delayed batch will recover in time — while the sale is already live. Customer data flowing between POS systems, CRM platforms and eCommerce touchpoints depends on those processes completing reliably, not approximately.
What changes with orchestration
Retailers consolidating onto RunMyJobs by Redwood aren’t just replacing schedulers. They’re replacing a fragmented and siloed operating model with something built for how retail works today.
The foundation is a unified application and data pipeline orchestration plane connecting commerce, POS, ERP and data workflows into a single execution layer. Pricing updates, inventory signals and fulfillment jobs stop running across disconnected tools and move through one platform, which is meaningfully cheaper than maintaining the parallel infrastructure most large retailers are currently running.
From there, the order-to-fulfillment lifecycle stops breaking at system boundaries. BOPIS, ship-from-store, CRM-triggered promotions and logistics coordination are automated end-to-end across every channel and handoff. If something changes upstream, the response propagates downstream automatically.
A cloud-native, globally scalable architecture means price changes, promotional activations and replenishment triggers execute on time even when event-driven demand spikes without warning. The platform handles peak load by design, not by adding infrastructure or staffing a war room. Governance is built into execution rather than added afterward. Compliance, auditability and security controls are enforced consistently across every workflow, including loyalty and customer data platforms where regulatory exposure is highest.
And AI runs across the full automation lifecycle, embedded into development, monitoring and optimization. Potential failures get flagged before they cascade. Issues that previously required manual investigation surface and can be remediated automatically before the customer notices.
The foundation your next initiative depends on
Demand forecasting, dynamic pricing, real-time inventory visibility — these are where retail is investing, and the pace is picking up. According to a recent Revionics survey, 67% of retailers plan to increase investment in AI-powered pricing over the next two years. Every one of those initiatives depends on reliable, connected application and data pipeline workflows underneath them. You can’t deliver dynamic pricing on a scheduler that drops jobs under peak load.
When the orchestration layer is fragmented, every initiative built on top of it inherits that fragility. Personalized recommendations, demand forecasting and real-time inventory can’t work consistently if the underlying processes don’t.
The automation layer is invisible when it works. When it doesn’t, the customer pays for it first. If a legacy scheduling tool renewal is approaching for your organization, it’s worth asking honestly whether your current foundation can support what you’re promising customers and whether another cycle of maintenance is really the answer.
At Redwood Software, we’ve had the privilege of working closely with some of the largest SAP landscapes in the world — across industries, continents and decades of transformation. Today, many of those same enterprises are entering a new chapter: RISE with SAP.
With our leadership in workload automation (WLA) through RunMyJobs by Redwood, we see firsthand the opportunities RISE unlocks — and the architectural considerations that follow.
One of the most critical, yet often overlooked, shifts? How file movement is handled in RISE.
The cloud transformation brings new rules for file exchange
Most enterprises adopting RISE are modernizing from highly customized, often decades-old SAP environments. These landscapes typically include:
Multiple ERPs, CRM and legacy systems of record
OS-level scripts, direct database writes and mounted network shares
Hundreds of file-based integrations with internal teams and external partners
These legacy approaches depend heavily on infrastructure-level access. But in a RISE architecture, those access models change. SAP clearly defines this shift:
“In the SAP S/4HANA Private Cloud environment, direct server access is unavailable.” — SAP Community Blog: Proposed Architecture for File Transfer
In short, file transfers must now align with strict ingress and egress controls, with no OS-level jobs or mounted file systems permitted.
This shift creates architectural friction that legacy models can’t easily resolve. What worked for file movement in the past may not translate to a clean core, cloud-first model — especially in hybrid enterprise environments.
The 2027 end-of-mainstream maintenance for SAP PI/PO
As organizations map out their RISE with SAP transformation or Cloud ERP transition, a critical deadline is approaching: SAP PI/PO’s 2027 end-of-mainstream maintenance and 2030 end-of-extended maintenance. For years, PI/PO has served as the workhorse for file-based integrations, yet many enterprises underestimate the impact of its end of support and looming retirement.
The risk is not just the deadline, but rather that SAP Integration Suite is not a full feature-parity replacement for dedicated file transfer. Moving B2B integrations from PI/PO often requires new licensing and trading partner components. Additionally, missing protocols like AS2 client, OFTP2 and SFTP server capabilities may force re-architecture of processes and trading partner connections.
Failing to plan for these differences can force your organization into two undesirable choices:
Building fragile, custom workarounds: Dedicating significant resources to maintaining complex solutions that don’t scale
Paying for extended maintenance: Settling for temporary support through 2030, which adds cost and delays your transformation without solving the underlying architectural gap
While SAP offers dedicated migration tooling to assist PI/PO customers in their transition, the recommended destination, SAP Integration Suite, falls short of the robust file transfer and data movement requirements mandated by modern, high-volume enterprise organizations. This creates a functional gap, particularly when handling the scale and complexity of data that defines today’s hybrid landscapes.
SAP BTP and high-volume file transfers
While SAP’s Integration Suite (part of SAP Business Technology Platform (BTP)) can manage file transfers through Cloud Integration flows, it was not designed as a dedicated, large-scale MFT hub capable of supporting any file size or file volume.
SAP experts acknowledge that files larger than ~40 MB frequently see performance degradation. Streaming, while supported, may still lead to timeouts, memory strain or complex workaround flows in real-world conditions, according to the SAP Community.
Routing thousands of files daily through a multi-tenant integration service can also introduce:
Latency due to multi-tenant queueing
High processing costs tied to data volume
Limits in protocol diversity (e.g., no native AS2, SFTP server, on-demand or OFTP2 support)
Challenges with file-level automation, error handling or audit logging
Additionally, for organizations in highly regulated sectors, data governance and long-term visibility present another layer of complexity. While SAP Integration Suite offers robust logging, its 30-day retention limit can inadvertently lead to a compliance gap for enterprises governed by mandates like SOX, PCI DSS or GDPR that require significantly longer look-back periods. Without a dedicated, long-term audit trail for every file exchange between trading partners and SAP applications, organizations may find themselves unintentionally non-compliant with strict regulatory requirements — even after a successful technical migration.
The bottom line? SAP Integration Suite wasn’t built to be a full-featured MFT platform. For organizations exchanging financial payloads, batch files or high-throughput transactional data, these constraints become increasingly apparent during RISE migration.
RunMyJobs + JSCAPE: Redefining the hybrid automation layer
This is where our customer conversations tend to deepen. File transfers aren’t isolated events; they’re tightly woven into broader enterprise process automation. That’s why RunMyJobs is so critical. It stands alone as the only SAP Endorsed App that combines agentic orchestration with its status as the leading cloud-native WLA platform.Redwood’s customers are using RunMyJobs and JSCAPE by Redwood together to address the demands of modern SAP workloads.
RunMyJobs orchestrates end-to-end processes across SAP and non-SAP systems, offering a wide range of connectors and templates for the latest SAP technologies and cloud solutions. These include SAP Cloud ERP, SAP Cloud ALM, SAP Integration Suite, SAP Datasphere, SAP Analytics Cloud and more, in addition to non-SAP and partner solutions like Databricks, Snowflake and many others. For SAP customers moving their ERP to the cloud via RISE, RunMyJobs is the only agentic orchestration platform that’s a part of the RISE with SAP reference architecture.
JSCAPE handles the secure, scalable movement of files across protocols, partners, clouds and compliance boundaries.
JSCAPE capabilities that matter in a RISE world
Multi-protocol Gateway: Support SFTP, AS2, OFTP2, HTTPS, REST APIs, SharePoint, on-demand, S3, Azure Blob, Google Storage, SMB and more
Automation integration: Trigger RunMyJobs or REST APIs based on file events
Security and compliance: Ensure encryption, integrity checks, SIEM streaming and SSO/LDAP
Scalability: Enable high availability (HA) clusters and horizontal scaling to support global 24/7 operations
Cloud-ready: Deploy MFT to be containerized OR hybrid-aligned with zero-trust principles
These two platforms are fully integrated and supported by a single vendor with over 30 years of experience in automation: Redwood Software.
Trusted by SAP, engineered for what’s next
RISE with SAP customers already trust RunMyJobs as the only orchestration platform that’s an Endorsed App and part of the RISE with SAP reference architecture, with many extending that trust by integrating file transfers through JSCAPE.
RunMyJobs’ Secure Gateway is a fully supported, SAP-compliant method for enabling secure, outbound automation from a RISE landscape, avoiding inbound firewall rules or non-compliant access patterns.
Together, RunMyJobs and JSCAPE provide a unified, secure framework for automating file transfers and workflows across hybrid SAP environments while respecting clean core principles and future-proofing your architecture.
Where to go from here
If your enterprise is moving to RISE or you’re simply re-evaluating file movement in a modern SAP architecture, Redwood’s experts would welcome the opportunity to talk about your file transfer plans to help ensure a successful transformation
We’ll share what we’ve learned through years of customer partnerships and how other organizations (like yours) are rethinking hybrid file flows, automation triggers and compliance boundaries during their cloud transformations.
Let’s define a file movement strategy that supports your business — and your future state. Find out more about JSCAPE.
SAP Sapphire 2026 will be underway starting next week, and as in past years, Joule has been central to nearly every conversation about the future of enterprise AI. That’s no surprise. Since its official announcement in September 2023, Joule has evolved from a conversational copilot into a genuinely agentic system that can reason through multi-step workflows, coordinate across SAP applications and initiate action rather than simply respond to prompts.
The industry trajectory behind this shift is well-documented. The November 2022 launch of ChatGPT accelerated enterprise AI adoption faster than most anticipated, moving organizations from isolated experimentation to embedding AI directly into daily business operations. Analysts at Gartner and Forrester now converge on the same conclusion: the near-term future of enterprise AI is defined by the transition from passive, prompt-based assistants to autonomous AI agents capable of goal-driven execution.
But the capability to act and the infrastructure to execute and scale reliably are two different things.
When Joule acts, something has to execute
The maintenance window is a solid use case to examine that gap, because it exposes exactly where agentic intent meets operational complexity.
Consider an unplanned SAP system maintenance window. Traditionally, this requires multiple manual steps and cross-team coordination: pausing background jobs, stopping dependent integrations, managing approvals and verifying that dependencies are resolved before maintenance can proceed. The SAP Business Technology Platform (BTP) team handles iFlows. The Basis team manages job suspension separately. Each manual handoff introduces risk, and as SAP landscapes become more interconnected, that complexity only increases.
With RunMyJobs by Redwood integrated into Joule, a Basis administrator can take a goal-oriented approach instead. They express intent — preparing systems for a maintenance window — and Joule handles the conversational layer, understanding the request and applying business context. RunMyJobs handles execution: orchestrating the required actions across SAP and connected systems using predefined workflows, policies and controls that have already been defined, approved and governed.
In other words, Joule is responsible for understanding and interacting while RunMyJobs is responsible for deterministic, auditable execution. Every step that runs has been scoped in advance. What changes is how teams interact with automation, but not the rigor with which it operates.
Conversational and agentic AI alone aren’t sufficient for enterprise automation. Without a reliable orchestration layer, AI initiatives introduce risk into mission-critical processes. RunMyJobs acts as the control plane between conversational intent and system execution. It’s cloud-native, an SAP Endorsed App and the only workload automation and orchestration platform that’s part of the RISE with SAP reference architecture. It provides centralized scheduling, dependency management, execution and observability across complex SAP and non-SAP landscapes, with role-based access control (RBAC), enforced approvals and a complete audit trail for every action taken.
Unlocking business value from Joule with RunMyJobs
Building Joule integrations with RunMyJobs just became significantly more accessible.
RunMyJobs’ REST API and pre-built SAP Build Actions are now published in the SAP Business Accelerator Hub, which has a few practical implications for teams building on SAP BTP. Development teams building Joule skills and agents can invoke RunMyJobs’ orchestration capabilities directly as no-code components within Joule Studio — no custom integration work required — with the full REST API accessible as low-code components for more advanced scenarios.
Inclusion in the Accelerator Hub also reflects a deeper level of alignment with SAP, as these integrations are designed within SAP’s extension framework and consistent with clean core principles and SAP BTP development standards. Furthermore, for customers with high security requirements, RunMyJobs now supports OAuth from SAP BTP, including Joule, to its REST API.
The integration is genuinely bi-directional: RunMyJobs can trigger and orchestrate SAP Build Process Automation workflows as part of larger end-to-end business processes, while SAP Build applications and workflows can call RunMyJobs capabilities — raising and clearing events, responding to alerts, managing queues — directly from within the SAP BTP ecosystem. And Joule can incorporate RunMyJobs as part of AI-driven automation scenarios, using it as the governed execution layer for Agents and Skills that need to operate reliably across SAP and non-SAP systems.
Two paths to governed agentic execution
Joule Agents can now connect to RunMyJobs in two ways: via Joule Skills using the pre-built SAP Build Actions in the SAP Business Accelerator Hub or through the Model Context Protocol (MCP) server.
MCP is an open standard that gives AI systems a shared way to connect with external tools without custom integrations, and its addition to RunMyJobs means Joule Agents can trigger workflows, check job status and interact with your automation landscape through a protocol already adopted across every major AI platform.
Whenever AI is introduced into enterprise systems, the first concern is control. That’s why governance is foundational to this approach.
In RunMyJobs, every action is governed, logged and auditable. RBAC ensures that only authorized users can trigger specific workflows. So, a new interface doesn’t expand permissions. It simply provides a different way to interact with existing, approved automation.
Policies are enforced automatically. If an approval or validation is required, the workflow will not proceed without it. Every step executed by RunMyJobs is logged, including what was triggered, when it ran, who approved it and how it executed across systems. That audit trail is always available.
This matters not just in regulated environments, but because compliance, traceability and accountability are always critical. AI automation must operate within those controls.
Maintenance is a powerful starting point, but it’s only one example. The same conversational orchestration pattern applies across SAP-driven business processes and functions:
Finance teams can trigger period close and reconciliation activities that depend on correct sequencing and validation
Supply chain operations, where timing and cross-system coordination are critical, benefit from AI orchestration that reduces manual handoffs and delays
Retail, utilities and HR teams can apply the same approach to order-to-cash, meter-to-cash and employee lifecycle workflows, respectively
