Lesson 3 of 6
Reading release information
8 min
Before you choose what to test, find out what changed. SAP publishes a lot of release information, and nobody reads all of it. The skill is to read it through the lens of your own scope: your processes, apps, roles and extensions.
What SAP publishes
| Source | What it tells you | Edition |
|---|---|---|
| What's new / release information on the SAP Help Portal | New and changed features by area for a release or feature pack | All |
| Simplification Item Catalog and simplification item check | Functional and technical changes that may require action, by item | On-premise and Private Edition (conversions and upgrades) |
| Upgrade guide for the target release | Technical upgrade steps and prerequisites | On-premise and Private Edition |
| SAP Notes and security notes | Individual corrections, side effects and prerequisites | All |
| Release Assessment and Scope Dependency (RASD) tool | Deleted, deprecated, new and changed apps, APIs, CDS views and scope items, filtered to your active scope | Public Edition |
| What's New Viewer | Searchable list of new features per release | Public Edition |
| SAP Road Map Explorer | Planned innovations for upcoming releases | All |
Main sources of SAP release information. Names and availability can change; check the SAP Help Portal for your release.
Filter by your scope
A release can contain hundreds of changes. Filter them to what Contoso actually uses. Your inputs are the list of business processes and scope items in production, the business roles and apps assigned, the custom developments and extensions, the interfaces, and the reports people rely on. Usage statistics help: on-premise and Private Edition systems record which transactions and reports are used (for example through workload statistics), which tells you what really runs.
- CollectRelease information for the target release or feature pack
- FilterKeep only items touching your processes, apps, roles, extensions, interfaces and reports
- ClassifyMandatory action, changed behavior, new optional feature, deprecation
- MapLink each relevant item to the regression scenarios that exercise it
- DecideTest, adopt, defer or act (for example adjust a role or custom code)
Reading an item well
For each item that survives the filter, ask four questions. What changes for the user? A new mandatory field, a different default, a moved function. What must we do? Some items require action before or after the upgrade, such as adapting custom code or adjusting roles. Which of our scenarios touch it? This links the item to tests. Is it optional? Many new features are switched off or available as new apps; you can adopt them later with their own tests.
Deprecations need special care
When SAP deprecates an app, catalog or API, it usually names a successor and a timeline. The old object may keep working for a while and then disappear. Track deprecations as tasks with owners: which roles use the app, which work instructions mention it, which interfaces call the API, and when you will switch. A deprecation discovered on the day the object vanishes becomes a production incident.
- Does the item touch a process, app, role, extension, interface or report we use?Yes → next question · No → no action; record as reviewed
- Does it require action from us?Yes → create a task with owner and due date, and test after the action · No → next question
- Does it change behavior in a scenario we run?Yes → add the scenario to targeted regression · No → next question
- Is it a new optional feature?Yes → log for evaluation; test only when adopted · No → record as reviewed
Roles and custom code
Two areas deserve their own check in every release because release information rarely spells out their impact on your system. Roles: in on-premise and Private Edition, the security team compares and adjusts role authorizations after an upgrade (transaction SU25 supports this), and launchpad catalogs may change; in Public Edition, SAP updates business catalogs and flags deprecated ones for business roles. Custom code and extensions: developers run SAP's code checks against the target release and fix findings, but only business tests show whether the custom credit check for fleet customers still behaves correctly. Ask for the list of adjusted roles and changed custom objects and map them to scenarios just like release items.
What would you do?
Release information for the next Public Edition upgrade lists a deprecated launchpad catalog. Contoso's billing clerk role still contains it. The upgrade to the test system is in three weeks. What should Maria do?
- Read release information through the lens of your scope: processes, apps, roles, extensions, interfaces, reports.
- Sources include what's-new documentation, the Simplification Item Catalog, SAP Notes, and for Public Edition the RASD tool and What's New Viewer.
- For each relevant item: what changes, what must we do, which scenarios touch it, is it optional?
- Track deprecations as owned tasks with dates.
- Split the reading by process area and record decisions in one shared list.
Check your understanding · not graded
Lesson check
1. Which Public Edition tool lists deleted, deprecated, new and changed objects filtered to your scope?
2. What is the first filter applied to release information?
3. How should a deprecation be handled?
4. How do you treat a new optional feature you do not plan to use yet?