About the upgrade advisor
An upgrade conversation usually starts from somebody's summary of what changed. This starts from the change list itself: pick the release you run today and the one you are considering, and see what moved in between — cited, so each line can be checked rather than taken on trust.
How it works
- 1Pick the two releasesThe one you run today and the one you are considering. The pair decides everything below it.
- 2Read what changedEvery affected capability, its fate and its successor — new, changed, deprecated, removed, or newly mandatory — cited to SAP's simplification catalog rather than paraphrased.
- 3Scope it to your footprintUntick anything you do not run today. The list stops being everything that changed and becomes the part that touches you.
- 4Take the detailEach remaining change keeps its source, so the ones that matter can be verified against the release's own documentation.
What you get
- What changed between your two releases, line by line, each with a citation
- The subset that touches the capabilities you actually run
- Which items are deprecated or removed, and what succeeds them
- What becomes mandatory on the target release
Who it's for
Programme leads and architects deciding whether to upgrade, and what the upgrade would cost them — before a system integrator frames the answer.
Common questions
- Where do the changes come from?
- The release's own documentation, including SAP's simplification catalog. Each line keeps its source so you can check it.
- Why ask what we run today?
- Most of what changes in a release will not touch you. Scoping to your footprint is what turns a long change list into a short one you have to act on.
- Which release pairs are covered?
- The pairs with differences recorded. If a pair has none yet, the page says so rather than showing an empty result as if it meant no changes.
Related