An SAP S/4HANA migration moves more than data and custom code. It moves a job estate: thousands of background jobs, variants, event triggers and file handoffs that have accumulated over 15 or 20 years of ECC operation, most of them commissioned by people who no longer work there. The programme plan rarely has a line for this. The operational work falls into 6 stages:
- Inventorying the jobs nobody remembers commissioning
- Mapping the dependencies that exist only in operators’ heads
- Deciding what gets rebuilt rather than lifted
- Surviving the cutover freeze
- Reconciling the parallel run
- Producing the evidence an auditor will want about the first close
Together they give SAP Basis leads, AMS delivery heads and cutover managers a working structure for the part of the migration that nobody else is writing about.
Why the job estate rarely gets scoped
Migration coverage concentrates on the business case, the deployment option and the data, and almost never on what happens to the jobs. The dates are not moving, and a large share of the installed base is still in flight.
- The deadline: SAP’s maintenance strategy sets the end of mainstream maintenance for SAP Business Suite 7 core applications at the end of 2027, with optional extended maintenance to the end of 2030 at a premium of 2 percentage points on the existing maintenance basis.
- The European picture: The DSAG Investment Report 2026 found that 54% of surveyed companies still run SAP ECC or the older Business Suite somewhere in their landscape, and that among those still investing in ECC, almost half plan to complete the switch by the end of 2030 rather than 2027.
- The North American picture: ASUG research tells a similar story, with 30% of respondents planning to go live within 6 to 24 months and a further 16% more than 2 years out.
If you are reading this, you are probably already inside one of those programmes. The point of this article is not to persuade you to start. It is to describe what the job estate does to a migration that is already under way, and how to handle it without the freeze, the parallel run or the first close becoming the story your steering committee remembers.
The 6 stages of rebuilding the job landscape
Stage 1: Inventory the jobs nobody remembers commissioning
The inventory is the stage most programmes believe they have done and almost none have done completely. SM37 gives you the released and scheduled jobs in each client, but a defensible inventory for a migration needs 4 more layers.
- Job history, not just the current schedule: A job that runs once a quarter for tax reporting or once a year for depreciation will not appear in a 30-day SM37 extract. Pull at least 13 months of history so that annual and quarterly cycles surface.
- Variants and their owners: The job is the wrapper; the variant is the business logic. Variants that reference company codes, plants or document types that are being consolidated in the target design need to be flagged now, not discovered when the job aborts in the new system.
- Definitions held outside SAP: Any job driven by an external scheduling tool, a script on a file server or a middleware platform has its real definition outside SM37. Those definitions need to be harvested from every tool that touches the landscape, because the SAP side only shows the trigger.
- Technical jobs that will change anyway: In SAP S/4HANA, periodic technical jobs are generated automatically by the Technical Job Repository (transaction SJOBREPO) rather than scheduled manually through the old standard-jobs function, as SAP’s Technical Job Repository FAQ sets out. Every housekeeping job in your ECC inventory should be tagged as either superseded by the repository or a genuine customer job that must be carried across.
Output of this stage: A single register with a named owner for every job. Where no owner can be found, the job goes into a quarantine list with a decision deadline, and that list is reviewed in the weekly cutover meeting rather than left for someone to notice later.
Stage 2: Map the dependencies that live in operators’ heads
The dependency map is where the inventory becomes an operating model, and it is where the migration is most exposed. ECC landscapes accumulate implicit dependencies that no document describes, because the people who understood them expressed that understanding through timing rather than configuration. The billing run starts at 02:00 because the delivery interface from the warehouse system finishes around 01:40. Nothing links the 2; an operator 12 years ago simply knew.
Dependencies hide in predictable places, and each place needs a different discovery method.
| Where the dependency hides | What it looks like | How to surface it |
|---|---|---|
| Time-based assumptions | Job B always starts 20 minutes after job A finishes, with no event link | Correlate 13 months of start and end times; look for consistent gaps |
| Event triggers | SM64 events raised by one job and consumed by another, sometimes across clients | Extract event definitions and cross-reference against the job register |
| File handoffs | A job writes to an application server directory that a non-SAP process polls | Inventory AL11 directories and every polling process on the other side |
| Interface dependencies | IDoc processing or RFC calls that depend on a partner system being available | Map every RFC destination and partner profile referenced in job steps |
| Downstream consumers | Reports or data extracts that finance, treasury or a regulator expects by a fixed hour | Interview the consumers, not the operators; ask what they receive and when |
Do not skip the consumer interview: It is the step most often skipped, and it is the one that prevents the most damage. The people who know that a treasury file must land by 07:30 are rarely in the Basis team. A short structured conversation with each downstream function produces a list of hard deadlines that the target job design must honour, and it gives you the reconciliation criteria you will need during the parallel run.
Stage 3: Decide what gets rebuilt rather than lifted
Every job in the register gets one of 3 dispositions, and the decision should be made deliberately rather than defaulting to lift-and-shift because it feels safest. Lifting a job into a landscape where its underlying program, data model or organisational structure has changed does not preserve behaviour; it preserves the appearance of behaviour until the first time it runs against real data.
| Disposition | When it applies | What the work involves |
|---|---|---|
| Retire | No owner, no downstream consumer, or the function is superseded (technical jobs now generated by the Technical Job Repository, reports replaced by embedded analytics) | Document the retirement decision and the sign-off, so that the absence of the job is explainable to an auditor |
| Lift | Program and variant are unchanged in the target, data model is unaffected by simplification items, dependencies are unchanged | Recreate with identical parameters and verify the first 3 runs against ECC output |
| Rebuild | The program is replaced or simplified, the variant references consolidated organisational units, the dependency chain has changed, or the job was a workaround for a defect that no longer exists | Redesign against the target process, rebuild the dependency links explicitly, and test in the conversion sandbox before the dress rehearsal |
In practice, the rebuild category is larger than programmes expect, for 2 reasons.
- The simplification list: It touches functional areas whose jobs were written for the old data model, and a variant that filters on a field that no longer exists will not fail gracefully.
- Accumulated workarounds: A meaningful share of any mature job estate consists of jobs that reprocess stuck IDocs every 15 minutes because an interface was unreliable in 2014, or reports scheduled hourly because someone once needed them urgently. The migration is the only moment when retiring those is politically easy, because everything is being reviewed anyway.
The hidden decision: The disposition stage is also where the target operating model gets decided, whether or not the programme frames it that way. If the rebuilt jobs are wired together with the same implicit timing assumptions as before, the new landscape inherits the fragility of the old one on day 1. The dependencies surfaced in Stage 2 should become explicit links in the target design, so that a delayed upstream job holds its downstream rather than letting it run against incomplete data.
Stage 4: The cutover freeze and what breaks during it
The freeze is the period between the last ECC business transaction and the first productive run in the new system, and the job estate behaves differently during it than at any other time. A well-run freeze has 3 job-related phases, and each has a characteristic failure.
Ramp-down
- What must happen: Jobs are brought to a controlled stop rather than simply deleted. Long-running jobs are allowed to complete or are cancelled at a known point, and periodic jobs are set to a held state rather than descheduled, so that the register still reflects what was running.
- Characteristic failure: A job cancelled mid-flight leaves a partial update behind, which is then carried into the migration as data.
The freeze itself
- What must happen: A small set of jobs still runs: the ones that extract the final data, the ones that produce the closing balances used for reconciliation and the technical jobs that keep the source system stable while it is being read. Everything else must not run, and “must not run” is enforced rather than assumed.
- Characteristic failure: A job held in SM37 had a second trigger in an external tool, and ran anyway.
Release into the new landscape
- What must happen: The rebuilt schedule is released in the new system. This is the most dangerous single moment in the entire job migration, because everything that was held now wants to run, and in the sequence the release order dictates rather than the sequence the business needs.
- Characteristic failures: RFC destinations still point at ECC hosts, variants reference organisational units renamed in the target, time zones set at the operating system level in the old landscape were never set in the new one, and file paths assume a directory structure that no longer exists.
The release should therefore be staged, not switched, with a verification step and an explicit go-ahead between each wave:
- Technical jobs first
- The integration and interface layer second
- The business-critical chains last, in dependency order
The dress rehearsal is the place to time each wave and to learn which breakages your landscape specifically produces, because every landscape produces its own.
Stage 5: Reconciling the parallel run when both landscapes are producing output
The parallel run is the period during which the new landscape is live and the old one is still producing comparison output, and it is the stage that determines whether the migration is trusted. Two landscapes running the same jobs produce 2 sets of results, and the programme needs to prove they match, explain every case where they do not and preserve that proof.
The reconciliation has to operate at 3 levels:
- Job level: Did the same job run, complete and produce output in both systems?
- Output level: Is the output the same: the same number of billing documents, the same total posted, the same file delivered to treasury by 07:30?
- Exception level: Has every mismatch been classified as expected (the target design deliberately changed the behaviour), tolerable (a rounding or timing difference within an agreed threshold) or a defect that needs fixing before the old landscape is retired?
Two things make this hard in practice:
- Reconciliation is itself a job estate: The extracts, comparisons and reports that produce the evidence have to run reliably every day of the parallel run, across both systems, and their own failures need to be handled without a Basis engineer manually rerunning them at 06:00.
- The approvals live in the wrong place: The person who can say that a €40,000 variance in the billing run is an expected consequence of the new pricing condition is a finance lead, not an operator, and the evidence that they said so needs to be attached to the run, not to an email thread.
This is where the migration exposes whether the organisation has one execution and evidence layer or 2.
- With 2 or more layers: The old landscape’s jobs are handled one way, the new landscape’s another, and the reconciliation by a third set of scripts. The parallel run produces 3 sets of logs that someone has to stitch together for the auditor.
- With one governed layer: The same layer runs the jobs in both landscapes, runs the reconciliation, routes the exceptions to the right approver and records the outcome. The parallel run produces its own evidence as a by-product of operating.
Stage 6: What the auditor will want about the first close
The first period-end close on the new system is where the job migration is tested by someone outside the programme, and the questions are predictable. The auditor is not interested in whether the migration was hard. They want to establish that the controls which existed in ECC still exist in the new landscape, that they operated during the first period and that there is evidence of both.
- Completeness of the job estate: They will ask how you know that every job that should have been migrated was migrated. The answer is the register from Stage 1, the disposition decisions from Stage 3 and the sign-off on every retirement.
- Operation of scheduled controls: Any job that performs a control function, such as a reconciliation, an interface completeness check or a periodic access review, needs evidence that it ran on schedule during the first period and that failures were detected and resolved.
- Change control across the cutover: Every job definition that changed between ECC and the new landscape is a change, and the auditor will want to see that it was approved, tested and released through a controlled process rather than adjusted in production during the freeze.
- Segregation of duties in job execution: Step users for technical and business jobs need to be appropriate to the target role design, and the auditor will look for jobs still running under the personal user IDs of consultants who have left.
- Exception handling and approvals: For every variance identified in the parallel run and every failed job in the first close, they will want to see who approved the resolution and on what basis.
The teams that find this stage easy are the ones for whom the evidence was produced by operating rather than assembled afterwards. If the parallel run left a single record of every run, every mismatch and every approval, the first-close audit is a retrieval exercise. If it left logs in 3 systems and approvals in email, the first close becomes a reconstruction, and reconstruction is where audit findings come from.
Where Symphony fits
Symphony provides the single execution and evidence layer across both landscapes during the overlap, orchestrating the job chains in ECC and SAP S/4HANA, running the reconciliation extracts and comparisons, and routing exceptions to the finance or operations approver in Microsoft Teams through Maestro before the autonomous execution engine carries out the agreed action. For a cutover manager, that means one register of what ran, what matched, who approved each variance and what was done about it, held in the same place for both systems and retained after the old landscape is retired. In one European life-sciences carve-out, Symphony reports that 25 of the 33 cutover steps were automated through the platform (vendor-reported), and the same approach applies to modernising the job landscape after go-live and to the system refresh cycles that a conversion programme runs repeatedly; the platform itself is at runsymphony.com.
From a lifted job list to a governed job estate
The 2027 deadline is fixed, and the DSAG and ASUG figures suggest that a large proportion of the SAP installed base will be somewhere in this journey for the next 4 years. The job estate is the part of the programme that determines whether the new landscape is operable on the morning after cutover and defensible at the first close, and it deserves the same discipline as the data migration and the custom code remediation.
- Inventory completely.
- Map the dependencies that nobody wrote down.
- Decide deliberately what to retire and what to rebuild.
- Stage the release rather than switching it.
- Reconcile the parallel run with evidence that produces itself.
- Walk into the first audit with a register rather than a story.
If you are working through a conversion and want to see how a single execution and evidence layer behaves across both landscapes, book a Symphony walkthrough with our team.
Frequently Asked Questions
What happens to background jobs during an SAP S/4HANA migration?
Every ECC background job must be inventoried, its dependencies mapped, and a decision made to retire, lift or rebuild it. Jobs are then held through the cutover freeze, released in staged waves in the new landscape and reconciled against ECC output during the parallel run.
When does SAP ECC mainstream maintenance end?
SAP’s published maintenance strategy ends mainstream maintenance for SAP Business Suite 7 core applications, including ECC 6.0 on enhancement packages 6 to 8, at the end of 2027. Optional extended maintenance is available until the end of 2030 at a premium of 2 percentage points.
Should ECC jobs be lifted as they are or rebuilt for S/4HANA?
Lift a job only when its program, variant, data model and dependencies are unchanged in the target. Rebuild when the program is simplified, the variant references consolidated organisational units or the dependency chain has changed. Retire jobs with no owner, no consumer or a function now handled by the Technical Job Repository.
What breaks when jobs are released after the cutover freeze?
Typical failures include RFC destinations still pointing at ECC hosts, variants referencing renamed organisational units, missing time zone settings in the new landscape, file paths to directories that no longer exist and jobs with a second trigger in an external tool. Staged release in dependency order limits the impact.
What evidence will an auditor want about the first close after S/4HANA go-live?
Auditors typically ask for proof that the job estate was migrated completely, that scheduled controls ran during the first period, that job changes went through change control, that step users match the target role design and that every parallel-run variance and failed job has a recorded approval.