Navigating SAP ERP modernization with orchestration continuity
SAP ERP modernization is often described as a move toward a destination: leave SAP ECC, adopt SAP S/4HANA, move to SAP Cloud ERP Private through RISE with SAP or start with SAP Cloud ERP through GROW with SAP.
SAP’s maintenance timeline can add urgency. Mainstream maintenance for SAP Business Suite 7 core applications, including SAP ERP 6.0, runs through the end of 2027, with optional extended maintenance available through 2030. SAP has also committed to maintaining at least one SAP S/4HANA release through 2040. Those dates don’t create one universal migration strategy.
Large SAP estates evolve over years, with legacy systems and newer cloud deployments running side by side. One business unit may move to cloud ERP while another continues running SAP ERP 6.0. A regional operation may stay on SAP S/4HANA on-premises. An acquisition may introduce another ERP instance. At the same time, the business processes that keep the organization running still depend on data platforms, file transfers, SaaS applications, analytics tools and other non-SAP technology.
For SAP operations teams, that creates a practical problem: how to keep critical finance, supply chain and operational processes running reliably while the ERP landscape changes underneath them. The answer must include orchestration continuity.
Job execution changes with the ERP
ERP coexistence also means job execution coexistence.
For decades, SAP Basis and operations teams have relied on traditional ABAP background jobs. Transactions such as SM36 and SM37 are familiar territory for scheduling and monitoring these jobs. They remain essential across SAP ERP and SAP S/4HANA environments and will continue running throughout long migration programs.
Newer SAP environments also use the standardized Application Jobs framework. Depending on the application, these workloads can include billing runs, material requirements planning (MRP) and foreign currency valuation. Application Jobs provide a model better suited to cloud application architecture and API-based interaction. But there’s still a difference between executing a job and orchestrating the larger process around it.
Scheduling answers a local question: When should this task run? Orchestration has to answer the rest:
- Is upstream data ready?
- Which event should trigger processing?
- What happens if a dependency fails?
- Which step runs next?
- Has the complete process met its SLA?
Those questions apply whether the SAP step is a traditional background job or an Application Job.
Keep orchestration separate from SAP execution
A central orchestration layer separates business process control from the way an individual SAP system executes work. SAP still runs the workload, and the orchestration layer manages the dependencies across environments that may use different scheduling interfaces, monitoring tools, security models and job semantics. That gives operations teams a consistent way to handle execution, alerting, recovery and audit history across on-premises systems, private cloud environments, SaaS applications and the rest of the enterprise stack.
It also supports clean core principles. Cross-system orchestration can stay outside the ERP core and use supported interfaces instead of custom code, embedded scheduling logic or point-to-point scripts. This reduces technical debt as the SAP estate changes.
In a migration, if an end-to-end process is tightly coupled to the way one SAP version executes a job, changing that system can turn the ERP project into an automation redesign project, too. Keeping the orchestration logic separate makes more of that process reusable as workloads move between SAP environments.
Support both SAP job models from one place
As a separate orchestration control plane, RunMyJobs by Redwood supports both sides of this transition.
For established SAP workloads, the built-in SAP ERP / SAP ECC / SAP S/4HANA connector integrates with traditional SAP background processing. You can run, intercept and monitor ABAP programs, apply variants and respond to SAP events.
For modern SAP workloads, the SAP S/4HANA Application Jobs connector brings Application Jobs into the same RunMyJobs orchestration environment. Teams can import job templates, submit and monitor runs, abort jobs when needed and track steps in multi-step jobs across SAP Cloud ERP, SAP Cloud ERP Private and SAP Integrated Business Planning (IBP).
| SAP workload | RunMyJobs integration | What it enables |
|---|---|---|
| Traditional SAP background jobs | Built-in SAP connector | Run, intercept and monitor ABAP programs; apply variants; respond to SAP events |
| SAP S/4HANA Application Jobs | SAP S/4HANA Application Jobs connector | Import job templates; schedule and submit jobs; monitor or abort runs; track steps in multi-step jobs |
| Cross-application processes | RunMyJobs orchestration | Coordinate SAP jobs with files, data platforms, cloud services and other enterprise applications |
The advantage is continuity. Traditional background jobs and Application Jobs can participate in the same end-to-end process. An underlying step can change without forcing the whole workflow to change with it.
What continuity looks like for a supply chain process
- Data arrives from an external system. RunMyJobs validates that the prerequisite is complete and starts the appropriate SAP workload. Today, that might be an ABAP background job in an existing SAP ERP system. When it finishes, downstream steps update a data platform, initiate reporting and notify another application.
- Now, one business unit moves to SAP Cloud ERP.
- The SAP step for that unit becomes an Application Job. The way SAP executes that portion of the process has changed, but the entire chain doesn’t need to be rebuilt around it. The new Application Job can occupy the appropriate place in the existing orchestration flow while downstream reporting, warehouse processing and notifications continue as before.
- Operations keeps a common view of the process instead of checking each participating application separately.
Build orchestration into your ERP roadmap now
The end of mainstream maintenance for SAP Business Suite 7 core applications makes ERP planning urgent, but mixed SAP landscapes won’t disappear in 2027.
As you plan your ERP roadmap, inventory the SAP background jobs you run today, then look beyond the jobs themselves:
- Which upstream systems determine when they can start?
- Which downstream applications depend on their results?
- Which workloads are candidates to move into the Application Jobs framework?
- Which workflows cross ERP instances, SAP BTP services or non-SAP platforms?
- Where are scripts or local schedules holding a larger business process together?
Those dependencies tell you more about migration impact than a job list alone. They also show where orchestration belongs in the transformation plan rather than as a cleanup project after the migration.
Redwood Software has been a trusted SAP partner for more than 20 years, and RunMyJobs is the only workload automation and orchestration platform that’s an SAP Endorsed App and part of the RISE with SAP reference architecture. As SAP architectures change, your orchestration layer shouldn’t also have to change every time an underlying workload does.
Your SAP ERP destination may still be evolving. The critical processes running across that estate still need one reliable way to operate.
Explore RunMyJobs connectors for SAP to see how you can build orchestration continuity into your SAP ERP roadmap.
About The Author
Sven Kohlhaas
Sven Kohlhaas is Vice President – SAP Product Lead at Redwood Software. He is responsible for the global success and evolution of Redwood’s SAP-related product portfolio, helping organizations orchestrate complex business processes across their SAP and non-SAP systems. His vision is to drive operational excellence by empowering enterprises to maximize the value of their technology investments.
With almost 20 years of experience in the IT industry, most of which at SAP in high-impact product and engineering roles, Sven is a seasoned leader with unique subject-matter expertise. His background spans enterprise software, service orchestration and automation, SaaS and PaaS cloud platforms, GenAI and ERP systems. This deep technical foundation allows him to bridge the gap between legacy environments and next-generation cloud architectures.