Lesson 3 of 5
Capability mapping
10 min
Listen to this lesson
With the inventory in hand, each used capability needs a target: a Cloud ALM function, another SAP product, an external tool, or nothing. SAP's learning content is frank that there is no one-to-one functional parity. Some functions are equivalent, some differ, some are missing and some are still evolving. Mapping is where those differences become visible early, while there is time to design around them.
Vocabulary first
The same idea often has a different name in Cloud ALM, and a mapped name does not mean identical behavior. The term mappings below are taught in the Cloud ALM overview course in this track; repeat them in the transition plan so both teams speak the same language.
| Solution Manager | SAP Cloud ALM | What changes |
|---|---|---|
| Solution documentation, process hierarchy | Process management: solution processes, process hierarchy, documents | SAP Best Practices content is the starting point; customer content is added |
| Test step, test package | Test case with activities and actions; test plan | Tests are built around solution processes |
| Test Suite automation (CBTA, eCATT) | Automated test cases from a connected tool that implements SAP's Test Automation API | Scripts are not migrated; the automation tool holds them and Cloud ALM orchestrates runs and results |
| ChaRM change document | Feature | The feature carries transports and orchestrates deployment |
| Continuous cycle, logical component group | Deployment plan and system group | SAP's ChaRM transition lesson maps the cycle to deployment plans and system groups |
| Technical, job and interface monitoring | Health, Job & Automation, Integration & Exception Monitoring | Rebuilt, not migrated; data collection is set up per use case |
| Focused Build governance | Constraints for a Focused Build-like way of working | Optional constraints on requirements, features and quality gates |
Where there is no direct equivalent
SAP's transition lesson names examples where Cloud ALM does not offer what Solution Manager did. These are the rows that need decisions, not configuration.
| Solution Manager function | SAP's position | Typical decision |
|---|---|---|
| IT service management | Not provided in Cloud ALM | Use an existing service desk; Cloud ALM can create tickets in an external ITSM tool from monitoring events |
| Custom code management | Not yet in Cloud ALM | Use the custom code tools in S/4HANA and the conversion's analysis; watch the roadmap |
| Data volume management | Out of scope for Cloud ALM | Plan with the Basis team using database and archiving tools |
| System Landscape Directory, License Administration Workbench | Need relocation planning | Move to another host before Solution Manager is retired |
| Advanced hybrid monitoring | SAP recommends Focused Run for advanced hybrid and service-provider scenarios | Cloud ALM for cloud-centric needs; evaluate Focused Run where scale demands it |
Gaps called out in SAP's transition guidance. Check the current roadmap before deciding.
Two of these touch quality work directly. Without ITSM in Cloud ALM, hypercare incidents live in the corporate service desk, so Priya needs a rule for linking an incident to a Cloud ALM defect and test case. And without custom code management, Kenji's team relies on the S/4HANA custom code tools for usage and quality checks after the conversion.
Change control: the hardest mapping
SAP's guidance singles out change control. ChaRM workflows and change documents are not migrated; the transition is a redesign of the change process around features, deployment plans and system groups. SAP's ChaRM transition lesson recommends planning with the Readiness Check and the roadmap, prioritizing landscapes by criticality, complexity and volume, starting with simple low-risk landscapes, validating feature-based transport flows for three- and four-tier landscapes, enforcing transport restrictions and approvals, and running a pilot before cutover.
- Is the capability used, and needed after ECC retires?Yes → map it · No → retire or archive
- Does Cloud ALM offer an equivalent today?Yes → configure the target · No → next
- Is it on SAP's published roadmap within the transition window?Yes → plan an interim workaround and a switch date · No → next
- Does another SAP product or an existing company tool cover it?Yes → integrate or relocate · No → accept the gap with a business owner's sign-off
Record each mapping decision in the transition project in Cloud ALM, with the reason and the owner. When the roadmap changes, the team can revisit exactly the rows affected instead of reopening the whole analysis. Grace reviews the open rows at each program gate.
What would you do?
During mapping, the internal auditor asks where Contoso's urgent-change approval evidence will live after the move, since "Cloud ALM has no ChaRM". What should the release manager answer?
- There is no one-to-one parity: map each used capability to a target, a workaround or an accepted gap.
- Key mappings: test package to test plan, ChaRM change to feature, continuous cycle to deployment plan and system group.
- SAP names gaps: ITSM not provided, custom code management not yet available, data volume management out of scope.
- ChaRM workflows and change documents are not migrated; change control is redesigned and piloted.
Check your understanding · not graded
Lesson check
1. What does a ChaRM change document map to in Cloud ALM?
2. Which Solution Manager function does SAP say Cloud ALM does not provide?
3. What happens to ChaRM workflows and change documents in the transition?
4. Which landscapes does SAP suggest moving first in a ChaRM transition?