What happens to your SAP batch jobs in an S/4HANA migration?
Batch jobs are the quiet backbone of your ERP. They rarely appear in a project plan, and they are often the first thing that breaks.
The short answer
Treat batch jobs as an inventory-and-validate problem, not a copy-and-hope problem. Start by extracting every scheduled and recently run job from the job tables (TBTCO for headers, TBTCP for steps, or transaction SM37), then check each step program against the simplification items and custom code findings for S/4HANA, because a job that references an obsolete transaction or report will fail silently on the first night. Group jobs by business process and dependency chain, retire the ones nobody consumes, and re-test the survivors in sequence in a non-production system. Finally, plan cutover so that jobs copied into test or sandbox systems are not released against live interfaces. Most batch-job surprises come from sequence and ownership, not from the code itself.
Why do batch jobs get missed in S/4HANA projects?
Business process workshops focus on what users do on screen. Batch jobs are what the system does when nobody is looking: billing runs, MRP, payment proposals, interface extracts, archiving, report distribution. Because they are scheduled by Basis teams and often by people who have since left, they rarely show up in a process map.
The result is a familiar pattern. The migration passes functional testing, goes live, and the first overnight cycle exposes a job that points to a removed report, a changed table, or a variant that no longer fits the data model.
How do you build a reliable batch job inventory?
Start from the system, not from documentation. The job tables record what is scheduled and what has actually run, and the second list is usually shorter and more honest than the first.
- Pull scheduled and executed jobs for at least a full business cycle, including month-end and year-end jobs where your data allows.
- Capture each step: program, variant, user, and the job that triggers it.
- Flag jobs that have not run in a year. They are retirement candidates, but confirm with the owner before removing them.
- Record the downstream consumer. A job with no known consumer is a question to ask, not an assumption to make.
What breaks when jobs move to S/4HANA?
The most common issues fall into three groups. First, obsolete objects: programs and transactions that S/4HANA has replaced or removed, which your simplification item check and ABAP Test Cockpit findings should surface. Second, data model changes, such as the finance and material document changes, which can invalidate custom reports and variants. Third, performance and sequencing: on HANA some jobs finish far faster, and a dependency that used to be protected by run time can become a race condition.
SAP also steers new scheduling toward application jobs, which you manage through Fiori apps rather than the classic job transactions. That is an option to evaluate per job, not a requirement to convert everything at once.
How should cutover treat scheduled jobs?
Two rules matter. Before the final migration, freeze job scheduling in the source system on a defined timeline so the data you move is consistent. After any system copy used for testing, make sure released jobs do not run against live interfaces; SAP provides the BTCTRNS1 and BTCTRNS2 reports to suspend and later restore job states around a copy.
Then re-release jobs deliberately, in dependency order, with someone named as owner for each chain. Treat the first full cycle after go-live as part of hypercare, not as normal operations.
Frequently asked
Do SM37 batch jobs still work in S/4HANA?
Yes, classic background processing and SM37 remain available in S/4HANA on-premise editions. What changes is whether each job's programs, variants and data dependencies are still valid, which is why every step needs to be checked against simplification items and custom code findings.
Should we convert all batch jobs to application jobs?
Not necessarily. Application jobs and the Fiori job apps are the direction SAP encourages, and they are the model in cloud editions. For an on-premise conversion, evaluate job by job and prioritize conversion where it supports your clean core goals or retires custom scheduling code.
How do we find batch jobs that nobody uses?
Compare the scheduled jobs against the jobs that actually ran over a full business cycle, then confirm candidates with the process owner. Jobs with no run history and no known consumer are good retirement candidates, but confirmation matters because month-end and year-end jobs can look idle for most of the year.
See your own Clean Core Score.
Run the free S/4 readiness scan in under a minute — no system access required.
Keep reading