Lesson 4 of 5
Aligning customer releases with SAP's upgrades
9 min
In private edition, Contoso decides when to upgrade. In the public edition, SAP decides. There are two major releases a year, in February and August, named by year and month: 2602 is February 2026, 2608 is August 2026. Between them come smaller feature deliveries, numbered after the release they follow (2602.1, 2602.2), and SAP applies corrections in hotfix collections, which SAP has described as arriving in roughly two-week blocks, plus emergency patches when needed. A customer release calendar that ignores this rhythm will collide with it.
- About 6 weeks beforeNotificationEmail with the upgrade dates; Luis books testers and reviews What's New
- A few days beforeUpgrade preparationExport, import and forwarding of key-user content are disabled
- Upgrade weekendTest system upgradedTest now runs the new release; development and production do not
- Next three weeksRegression windowRegression of key processes, extensions and integrations in test
- Three weeks after testDevelopment and production upgradedProduction now runs the release that was regression tested
- After the software upgradeContent upgradeNew SAP content reaches development automatically; test and production when the customer imports it
What the upgrade does to your transports
SAP's learning material notes three effects that matter to a release manager. First, export, import and forwarding of key-user content are disabled during the upgrade preparation phase, which typically starts a few days before the upgrade weekend. Second, collections that were not imported before a major upgrade can end up marked outdated or discarded, and key-user extensions created in a previous release may not be importable into an upgraded system. Third, for the three weeks of the regression window, the landscape is split: test runs the new release while development and production still run the old one.
The split is the subtle one. A change built in development during the window was built on the old release but is tested on the new one. If it fails, is the change wrong or did the upgrade change something underneath it? Mixing customer change with SAP's upgrade makes root cause hard to find. That is the reason to plan a customer change freeze around each upgrade, not because SAP forbids all imports (SAP's material says development and customizing transports can still be released and imported into test during the window), but because clean diagnosis is worth more than a few extra days of throughput.
| Week relative to test upgrade | Customer release activity in the working example |
|---|---|
| -6 to -3 | Last regular customer release imported into production; regression pack updated with new extensions |
| -2 to 0 | Freeze on new extensions; only hotfix exports for production defects |
| 0 to +3 | Regression window: no customer releases; fixes for upgrade findings only, each tested on the new release |
| +3 | Production upgraded; smoke test on day one |
| +4 onward | Next customer release resumes, now built and tested on the same release everywhere |
An illustrative freeze plan around an upgrade. Adjust to SAP's actual dates for your landscape.
Tools that help you plan
- What's New Viewer on the SAP Help Portal: filter the changes in the coming release by your scope and check which features need newer reference content.
- Release Assessment and Scope Dependency tool: shows the expected impact of a release on your deployed content and can create upgrade-related tasks in SAP Cloud ALM.
- Test Automation Tool: SAP's test automation for the public edition, with standard test processes you adapt to your configuration; SAP recommends it to speed up regression.
- SAP's upgrade and maintenance schedule: the published dates for your landscape type. Use it, not a remembered pattern.
Content upgrades deserve a note. After a software upgrade, new SAP business content reaches the development system automatically, and goes to test and production when the customer imports it, manually or on a schedule in Import Collection. SAP recommends moving new content to production promptly and using an automation schedule so software and content versions stay aligned. For the release manager, that is another item on the calendar with its own test checkpoint.
What would you do?
In the working example, Grace wants to move a large pricing extension to production in the week before SAP upgrades the test system, "to get it out before the freeze". What should Luis recommend?
- Public edition releases come in February and August, with feature deliveries and hotfix collections in between.
- SAP upgrades test first; development and production follow about three weeks later, after a notification about six weeks ahead.
- Key-user content cannot be exported, imported or forwarded during upgrade preparation; old collections can become outdated.
- Plan a customer change freeze around each upgrade so upgrade findings and customer changes are not mixed.
- Use What's New, the Release Assessment and Scope Dependency tool and SAP's published schedule to plan.
Check your understanding · not graded
Lesson check
1. In which months are major public edition releases delivered?
2. Which system does SAP upgrade first?
3. Why plan a customer change freeze around an upgrade?
4. What does release 2608.1 mean?