Lesson 2 of 5
Maintenance Planner
11 min
Listen to this lesson
Maintenance Planner is mandatory in a conversion. SAP's guide calls it the first step of the process: it checks whether the system's components, add-ons and business functions are compatible with SAP S/4HANA and creates the stack file that SUM needs. It replaced the older Maintenance Optimizer, which SAP S/4HANA does not support. It runs in SAP's support portal, using the system data you send to SAP.
Getting the system into Maintenance Planner
- Source systemEP1 needs SPAM/SAINT patch 71 or higher
- SAP Solution ManagerLandscape data in LMDB; the guide asks for SAP Note 2186164 and a read RFC (SM_EP1CLNT000_READ) to client 000
- SAP Support PortalSystem data reaches Contoso's customer profile; without a connection, a system information XML from SPAM can be uploaded
- Maintenance PlannerSam selects EP1 and plans the conversion to SAP S/4HANA 2025
Most Maintenance Planner problems are data problems: a system missing from the customer profile, an add-on not recognized, or a stale picture of support packages. Check the system's view in Maintenance Planner against what is really installed (the component list in the system status) before trusting the plan.
Contoso still runs SAP Solution Manager 7.2 for the ECC support team, so Sam uses the landscape data path the conversion guide describes. Solution Manager 7.2 leaves mainstream maintenance at the end of 2027, and the S/4HANA program already runs in SAP Cloud ALM. For a site without Solution Manager, the fallback is a system information XML generated in SPAM and uploaded to Maintenance Planner; check SAP's current notes for the exact steps on your release.
What it checks
| Item | What Maintenance Planner does | What it means for you |
|---|---|---|
| Add-ons | Checks each add-on for a conversion path; add-ons are merged into SAP S/4HANA or removed if no successor exists | An add-on without a path blocks the conversion until the vendor releases one or you uninstall it |
| Business functions | Compares states in the source with always_on, always_off and customer_switchable in the target | A function switched on in the source but always_off in the target blocks conversion to that release |
| Industry solutions | Checks support in the target release | See the release's restriction note |
| Target stack | Lets you choose the target release and feature package stack, plus related front-end components | Pick the stack the whole program will use; changing it later means re-planning every conversion |
Maintenance Planner checks, following SAP's conversion guide.
- Is every add-on released for the conversion?Yes → next question · No → get a release from the vendor or uninstall the add-on (SAP describes uninstalling in its notes)
- Is any active business function always_off in the target?Yes → that target release cannot be used for conversion · No → next question
- Are local Fiori apps compatible?Yes → next question · No → uninstall the incompatible apps first
- Is an SAP S/4HANA license assigned?Yes → generate stack.xml and download files · No → checks are possible, the stack file is not
The output: stack.xml and downloads
When the checks pass, Maintenance Planner generates the stack configuration file (stack.xml) and the list of download files: software packages, add-ons and database-dependent files. SUM reads stack.xml as its input, so the plan and the run must match. You need an SAP S/4HANA license to generate the stack file; without one you can run the checks but not create it.
Step by step: Sam's plan for EP1
- Compare Maintenance Planner's view of EP1 with System > Status > Component information in EP1. Every component, support package and add-on must match.
- Plan a change for EP1 and choose the conversion to SAP S/4HANA, then the target release (2025) and the feature package stack the program agreed.
- Read the check results: each add-on, active business function and industry solution with a valid path or a blocker. SAP Note 2214409 lists supported add-ons; SAP Note 2011192 describes uninstalling ABAP add-ons.
- Select the target kernel and the operating system and database dependent files for SAP HANA.
- Confirm the plan to generate
stack.xml, push the files to the download basket and download them. - Save the stack file in the program's change record with its feature package stack, so every later conversion uses the same file.
| Finding (illustrative) | Check result | Decision |
|---|---|---|
| Third-party tax add-on | No conversion path for 2025 yet | Program risk: vendor date or uninstall with replacement |
| SAP add-on merged into SAP S/4HANA | Valid path | Regression test its functions after conversion |
| Active business functions | None always_off in 2025 | No action; always_on functions activated by SUM noted for testers |
| Local Fiori apps not released for SAP_UI 7.50 | Would block the plan | Uninstalled with SAINT before planning |
| Industry solutions | None active | No action |
What Contoso's first Maintenance Planner run found for EP1, and the decision on each line.
Plan the target once for the whole program. Contoso's plan targets SAP S/4HANA 2025 with one named feature package stack. Sam reuses the same plan for the sandbox, CMD, CMQ and CMP conversions, and re-plans only by decision of the change board, because a different stack in production than in the mocks would invalidate every test result.
What would you do?
Maintenance Planner refuses to plan Contoso's conversion because a third-party tax add-on in EP1 has no conversion path for SAP S/4HANA 2025. The vendor says a compatible version is 'coming soon'. What should Sam do?
- Maintenance Planner is mandatory: it checks add-ons, business functions and industry solutions.
- Correct system data from the source, via Solution Manager, is the foundation of a correct plan.
- Output: stack.xml and download files; generating stack.xml needs an SAP S/4HANA license.
- Plan one target stack for the whole program and re-plan only by decision.
Check your understanding · not graded
Lesson check
1. What does SUM need from Maintenance Planner?
2. An active business function is always_off in the target release. What follows?
3. Which statement about the SAP S/4HANA license and Maintenance Planner is correct?
4. Why should the same target stack be used for all conversions in a program?
5. How should Sam verify the system data before trusting a Maintenance Planner plan?