SAP Upgrade Checklist: Before, During, and After

Decision context

An upgrade has four cost centers: the technical run, modification adjustment, testing, and the defects found afterwards. Only the first is predictable from documentation. The other three are functions of how much the system was modified and how much of the business is covered by tests.

So the planning question is not how long the tool takes. It is how many modified objects will appear in the adjustment work lists, how much of the affected functionality has tests, and how long the business needs to accept the result.

The checklist below is by phase. Nothing in it is exotic, and the items that get skipped are consistently the same ones: the add-on and third-party compatibility question, the modification inventory, and the post-upgrade generation run.

Planning, weeks before

This is the phase where the answers are cheap. Every question deferred from here gets answered during the window instead.

• Target release and stack defined through the maintenance planner, with the stack file produced and validated rather than assembled by hand.
• Add-on and third-party product compatibility confirmed with each vendor for the target release. This is the item most likely to stop the upgrade and the item most likely to be assumed.
• Modification inventory produced: which SAP objects are modified, and how many were modified without the Modification Assistant, since those dominate the adjustment effort.
• Custom code checked against the target release with the appropriate check variant, and the findings scoped against usage evidence.
• Interface inventory reviewed for anything the target release changes, including partner-facing structures.
• Downtime requirement estimated, and the downtime-optimized options for your upgrade path evaluated against the business's tolerance.
• Test scope derived from the affected objects rather than from the previous cycle, with the coverage gaps named.
• Backup and restore strategy agreed and a restore actually verified.
• Kernel, database, and operating system prerequisites checked and scheduled, since these frequently need their own windows.

Preparation, in the sandbox and development systems

Run the whole thing at least twice before production. The first run finds the surprises, the second measures the window.

• Run the upgrade end to end in a sandbox built from a production copy, and record every error and every manual step.
• Complete the dictionary and repository modification adjustments properly in the first system, since later systems reuse that work.
• Free the required disk space and check the transport directory, both of which stop an upgrade at an inconvenient point.
• Clear the transport queue or record exactly what is in it, because in-flight changes and an upgrade interact badly.
• Confirm the correct service tool and content versions are in place for the checks the upgrade depends on.
• Measure the runtime of each phase, particularly the downtime-relevant ones, and use the measurement rather than the documentation.

The window itself

The upgrade tool drives most of this. The parts that need people are the adjustment prompts and the decisions when a phase fails.

• Users locked, background jobs suspended, interfaces stopped and queues drained before the tool starts.
• Backup taken at the agreed checkpoint, with the restore path understood by the person who would have to run it.
• The dictionary modification adjustment done when prompted, with the owner present, because the upgrade waits at that point.
• Errors read from the tool's own logs and the phase logs rather than from the summary, and escalated against a written decision rule.
• The point of no return identified in the plan, and the abort decision made before it rather than after.

After the upgrade, before release

These are the items most frequently skipped, and each one has a recognisable symptom in the first week.

• Repository modification adjustment completed, including enhancement implementations, which are adjusted separately.
• Generation run executed so the first business users are not paying compilation time, which otherwise presents as a mysteriously slow Monday.
• Background jobs released, and the schedule checked against what it was before rather than against what someone remembers.
• Interfaces restarted in sequence, with duplicate protection verified and the queues watched for the first business day.
• Kernel, SPAM, SAINT, and support tool levels confirmed at the intended versions.
• Regression executed against the affected objects, with the always-on critical set included.
• Performance compared against the pre-upgrade baseline, which is why capturing the baseline beforehand matters.
• Custom code that failed to activate identified and resolved, rather than left inactive and rediscovered by a user.

What the workflow must cover

• Affected object scope. Derive the test and remediation scope from the objects the target release changes rather than from the previous cycle.
• Modification visibility. Inventory modified SAP objects before the upgrade so the adjustment effort is estimated rather than discovered.
• Coverage gaps. Name the affected functionality with no test coverage, so a reduced regression scope is an argued decision.
• Package-bound results. Bind test results to the exact stack and package, so a late note or a re-run invalidates the earlier approval.

Implementation workflow

Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.

1. Define the stack, confirm add-on compatibility, and inventory modifications.
2. Run the upgrade end to end in a sandbox from a production copy and measure the phases.
3. Complete the adjustments properly in the first system so later systems reuse them.
4. Execute the window with the adjustment owner available and a written escalation rule.
5. Complete the post-upgrade tasks, then run the derived regression scope before release.

Evidence to require

A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:

• Stack definition and validation
• Add-on compatibility confirmations
• Modification inventory
• Custom code findings with usage evidence
• Measured phase runtimes
• Adjustment decisions and transports
• Post-upgrade task completion
• Regression results against the final stack

Boundaries and non-claims

Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.

• Modification adjustment effort cannot be estimated reliably from object counts alone.
• Downtime-optimized options differ by upgrade path, source release, and database, and availability has to be confirmed for your specific case.
• An upgrade does not improve custom code. It reveals which of it no longer fits.

Buyer checklist

• Has every add-on and third-party vendor confirmed compatibility?
• How many objects were modified without the Modification Assistant?
• Were the phase runtimes measured or taken from documentation?
• Was a generation run executed before release?
• Which affected functionality has no test coverage?