SAP Upgrade

An upgrade updates the SAP software (release and/or support packages) using the Software Update Manager (SUM). It may include database and kernel updates, and it can affect custom code and configuration, which must be adjusted and re-tested. Upgrades run through the landscape (DEV first, then QAS, then PRD) like any change.

The distinction that matters before anything else: a support package applies corrections within the release you are on, an upgrade moves you to a higher release, and a conversion moves you to a different product. They are described together because the tool is the same one, and they carry very different amounts of risk. A support package stack is routine maintenance. A conversion to S/4HANA changes data structures your custom code reads. See the migration path.

The Maintenance Planner determines the target stack and generates the correct, compatible files. It ensures the components you upgrade to actually work together, a prerequisite for a clean SUM run.

What it produces is a stack XML: the exact list of packages, at the exact versions, in the order they must be applied. SUM reads that file and will not proceed without it. It is not a convenience. It is the thing that stops you applying a combination SAP has never tested.

The step people skip is telling the planner the truth about what is installed. Add-ons, industry solutions and third-party certified components all constrain the target, and one that is not registered correctly produces a plan that fails partway through the run rather than at planning time, which is the expensive place to find out.

Two inputs decide the target and both come from outside the technical team. The business reason tells you how far to move: a legal requirement usually needs one specific package, while a functional gap may need a release. And the support position of what you run today tells you how much choice you have, because a release approaching the end of mainstream maintenance turns a discretionary upgrade into a scheduled one. Establishing both before opening the planner stops the plan being built around a target nobody has agreed.

SUM runs in phases, and knowing which are online matters because it decides what you can tell the business.

1. Preparation. Checks, space, the stack file, extraction. System fully available.
2. Shadow build. A parallel set of repository objects is built alongside the running system. This is the long phase, it runs online, and it is why modern upgrades have far less downtime than they used to.
3. Downtime. The switch to the shadow, table conversions that cannot happen online, and the after-import steps.
4. Post-processing. Back online, with follow-up activities outstanding.

So the downtime window is not the run time. Estimating it from how long the whole thing takes will make you quote a number several times too large, and quoting the shadow phase as free will make you quote one too small, because it consumes real resources on a system users are working on.

The biggest upgrade risk is usually custom code and modifications. SPAU/SPDD handle adjusting modified SAP objects during the upgrade, and thorough regression testing in QAS confirms nothing broke. Plan time for both.

Two adjustment transactions do different jobs and both appear. SPDD handles dictionary objects and runs during the upgrade, because getting it wrong means data loss. SPAU handles repository objects and runs after. Both list every place somebody modified standard SAP, and the size of that list is a direct measure of how much the previous team customised.

For each entry the decision is: keep the modification, or return to standard. Returning to standard is almost always right when the modification exists because a note had not yet been applied, because SAP has since fixed it properly. See kernel upgrades for the smaller sibling of this job.

Half a day on a sandbox, and it is the difference between running SUM and understanding it.

1. In the Maintenance Planner, define the target stack for a sandbox at a lower support level.
2. Download the stack XML and open it. Read the component list and the versions.
3. Run the SUM preparation phases only. Stop before downtime.
4. Read the check results: space, obsolete objects, open transports, inconsistent tables.
5. Look at the SPDD/SPAU worklist sizes. That number is your testing scope.
6. Estimate the downtime from the phase plan rather than the total duration.

Everything up to step six is reversible, and it is where the real planning lives.

An upgrade is not one event, it is the same event repeated through the landscape, and the value of the early runs is entirely in what they teach you about the later ones.

Sandbox. The purpose is to find out how long it takes and what breaks, not to test the business. Throw it away afterwards. The output is a timing profile and a list of surprises.

Development. The first run that keeps its result. This is where SPDD and SPAU are worked properly, and those decisions are recorded in transports so the later systems can reuse them rather than repeating the analysis.

Quality. The rehearsal that matters, because it should be a recent copy of production. Time it carefully: this is the number you commit to. Business testing happens here.

Production. Ideally uneventful, because everything has been met already.

The mistake that undoes this sequence is a quality system that has drifted from production. If it holds old data, a different set of transports, or a smaller hardware profile, then its timings and its errors are not evidence about production. A system copy before the rehearsal costs a day and is what makes the rehearsal mean something.

One more scheduling point. Business calendars beat technical convenience: month end, quarter end, statutory reporting and payroll runs are all periods where an unavailable system is expensive out of proportion to the hours. Ask for those dates before proposing a window.

• Read the release/upgrade notes and compatibility matrix.
• Upgrade DEV → QAS → PRD, testing at each stage.
• Back up before upgrading production, with a rollback plan.

One point worth being blunt about: the backup is only useful if it has been restored. A backup nobody has ever restored is a belief, not a control, and an upgrade is the wrong moment to test it. See restore.

A short list is worth keeping for the run itself. Confirm the backup and its restore. Confirm no transports are open. Confirm the space in the database and in the file system where SUM extracts. Confirm who is authorised to make a stop decision, and at which phase stopping is still possible, because after the point of no return the only way is forward.

• Underestimating custom-code adjustment (SPAU/SPDD).
• Skipping regression testing in QAS.
• No backup/rollback before the production upgrade.

• Quoting the run time as the downtime. The shadow phase is online.
• Open transports at the start. They will not survive, and finding out mid-run is worse.
• Keeping modifications reflexively in SPAU. Many exist only because a note was not applied. See transports and system monitoring.

Version note: the tool has consolidated. Older material names several separate utilities for upgrades, support packages and conversions, and current work uses the Software Update Manager for all three, driven by a plan from the Maintenance Planner. Instructions written for the older tools are usually still correct about the concepts and wrong about the screens.

Reading a plan is the part you can practise on a sandbox, and running one against a real business calendar is the part you do in the course.