A Solution Manager to Cloud ALM migration can look straightforward on paper until teams start sorting through the systems, ChaRM cycles, monitoring scenarios, test assets, and integrations tied to the existing environment. What appears to be a technical migration quickly becomes an inventory and decision-making exercise, especially when nobody can clearly determine what should move, what should be retired, and what needs redesigning.
With the December 31, 2027 mainstream-maintenance deadline approaching for SAP Solution Manager 7.2, delaying those decisions can turn a controlled transition into a rushed cutover. The key is not simply moving from one ALM platform to another; it is establishing what the current landscape depends on and defining measurable readiness criteria. This guide outlines 9 practical steps to assess the existing environment, build a reliable migration inventory, and prepare for a controlled move to SAP Cloud ALM.
Implement the current version of SAP Note 3236443 before collecting Readiness Check data, and reserve a coexistence window for side-by-side validation. SAP’s official Readiness Check guidance requires the note and its collector in Solution Manager.
For ECC 6.0 and SAP S/4HANA managed systems, check support per Cloud ALM operations use case rather than assuming every Solution Manager monitor has a direct equivalent. SAP’s supported-solutions list includes Business Suite 7 and SAP S/4HANA, but capability coverage differs across monitoring areas.
Step 1—Build an Evidence-Based Solution Manager Inventory
Start the Solution Manager to Cloud ALM migration by proving what teams use. List Solution Documentation branches, test plans, test packages, ChaRM cycles, ITSM queues, monitoring scenarios, EarlyWatch Alert dependencies, Focused Build objects, external repositories, interfaces, RFC destinations, background jobs, reports, and audit-retention obligations.
Use SM37, which displays scheduled and completed background jobs, to find recurring collectors, interface jobs, notification jobs, and custom reports tied to Solution Manager. Use SM59, which maintains RFC destinations, to identify connections that another platform or process must replace.
Record the owner, frequency, consumer, source system, target system, retention period, and business effect of failure for each item. Mark the capability as active, partially used, dormant, or unknown.
The following read-only ABAP report helps you list background jobs by name pattern. Run it in a customer namespace after normal code review; it reads the job-header table TBTCO and changes no data.
Step 2 — Run SAP Readiness Check for Solution Manager to Cloud ALM
For a Solution Manager to Cloud ALM project, SAP Readiness Check examines the current Solution Manager footprint, shows capability usage, compares available target functions, and highlights possible blockers for Selective Data Transfer and ChaRM. SAP recommends running the collector where usage is most representative, normally the productive Solution Manager system.
SA38 runs an ABAP report by program name. Implement the current version of SAP Note 3236443, open SA38, and execute the collector supplied by SAP:
/SDF/RC_ALM_COLLECT_DATA ” Enter this report name in transaction SA38
Upload the collector archive to the SAP Readiness Check application in SAP for Me, or create the analysis from SAP Cloud ALM. Review every dashboard with the capability owner; do not let the Basis team approve business-process decisions alone.
Convert findings into actions, owners, due dates, and evidence. The analysis should show current ALM usage, equivalent capability guidance, Selective Data Transfer preparation, and possible roadblocks.
If the collector returns incomplete sections, update the note, rerun it, and confirm that the source system reflects productive usage. SAP updates capability availability in existing analyses quarterly, although new collector requirements may still require another data upload.
Step 3 — Classify Every Capability: Transfer, Rebuild, Replace, Retain, or Retire
The biggest solution manager to Cloud ALM mistake is calling every activity “migration.” Use five target actions and force the steering team to approve one for each capability.
| Target action | Choose it when | Typical example |
| Transfer | SAP supports the selected object through SDT or an approved import | Process hierarchies, selected Solution Documentation, test cases |
| Rebuild | Cloud ALM supports the outcome but not the old configuration or history | Health Monitoring, Integration Monitoring, alert subscriptions |
| Replace | Cloud ALM does not provide the required process | ITSM, advanced custom ChaRM workflows, unsupported reporting |
| Retain temporarily | Open work, linked files, audit evidence, or dependencies remain | Active change cycles, historical documents, signed test evidence |
| Retire | No current owner or measurable business use exists | Obsolete dashboards, duplicate templates, unused branches |
This classification matters because SAP does not plan to transfer Change Control Management data. SAP recommends closing open change cycles in Solution Manager and then activating Cloud ALM deployment functions.
SAP Cloud ALM also excludes ITSM. Teams using Solution Manager service desk functions need an approved third-party ticketing target and a clear integration design.
Create a decision register with the current capability, target action, target product, owner, deadline, dependency, risk, and acceptance test. Reject entries such as “move later” because they hide unresolved scope.
Solution Manager to Cloud ALM—Capability Decision Register
| Capability | Target Action | Target Product | Owner | Deadline | Dependency | Risk | Acceptance Test |
| Health Monitoring — ECC system | Rebuild | Cloud ALM | Basis Lead | Q1 | New thresholds configured | Alert gap during cutover | Alert fires and reaches on-call team |
| Change cycle (ChaRM) | Retain temporarily | Solution Manager (read-only) | Change Manager | Before cutover | All linked transports released | Audit evidence lost | Cycle closed, evidence archived |
| Process hierarchy — S/4HANA branch | Transfer | Cloud ALM (via SDT) | ALM Consultant | Q2 | Target project structure exists | Broken document links | Branch imported, links tested by business user |
| Service desk (ITSM) | Replace | Third-party ticketing tool | Functional Lead | Q2 | Integration design approved | No fallback for incidents | Ticket created, routed, and closed end-to-end |
| Focused Build test steps | Transfer | Cloud ALM (via SDT) | Test Lead | Q2 | Test scope validated | Incomplete test coverage | Sample test case executed post-import |
| Obsolete Solution Documentation branch | Retire | — | Documentation Owner | Immediate | None | Confusion over active vs. dead content | Branch archived, no active references remain |
Step 4—Provision the Solution Manager to Cloud ALM Target
Request the tenant before planning a production transfer. In SAP for Me, open Systems & Provisioning, locate the SAP Cloud ALM entitlement, and start provisioning. SAP’s provisioning guide uses this path for requesting the tenant.
Confirm the customer number, region, subdomain, selected Identity Authentication tenant, and Main IT Contact before submission. Record the provisioning decision because changing identity or tenant arrangements after productive adoption can affect user access.
After provisioning, onboard users in SAP Cloud Identity Services – Identity Authentication and create or import the same users in SAP Cloud ALM. SAP states that users must exist in both the Identity Authentication tenant and Cloud ALM before they can sign in.
Assign roles through the User Management application according to job responsibility. Test access with real workstream users, not only the global administrator.
Ask an implementation lead to open Projects and Setup, a monitoring lead to open Landscape Management and Operations, and an auditor to confirm read-only evidence access. A solution manager to the cloud alm schedule will slip if SDT starts while project administrators, landscape administrators, and testers still lack the correct applications.
Step 5 — Design a Phased Coexistence Plan
Do not move monitoring, test management, process documentation, ChaRM, and ITSM during one cutover. SAP recommends using its transition roadmap and Readiness Check findings to plan the move, while the December 31, 2027 maintenance date makes uncontrolled delay equally risky.
Choose a pilot with measurable output and limited business impact. Good examples include health monitoring for one ABAP system, integration monitoring for one interface flow, or manual test management for one project.
Keep Solution Manager active long enough to compare coverage, alerts, responsibilities, and response times. Record differences in thresholds, data collection, notification routes, operating hours, ownership, and escalation.
Define one system of record for every process during coexistence. Parallel technical monitoring may support comparison, but two active change-control processes create conflicting transport ownership.
State which platform creates the requirement, controls the deployment, records the defect, and holds the approved evidence. Do not leave these decisions inside meeting notes.
For SAP S/4HANA programs already running in Solution Manager, SAP recommends finishing active projects there where practical and starting new projects in Cloud ALM. Build the solution manager to cloud alm roadmap around project boundaries rather than arbitrary calendar dates.
Step 6 — Prepare Data for Solution Manager to Cloud ALM
In a solution manager to cloud alm migration, Selective Data Transfer moves selected content; it does not clean poor source data. Remove obsolete branches, duplicate process nodes, abandoned test assets, broken document links, old owners, inconsistent naming, and content with no approved retention purpose.
Prepare the target project before export. Create the project structure, scope, landscape entries, system groups, users, roles, releases, tags, and ownership rules needed to receive transferred objects.
Confirm that names and identifiers match the mapping decisions used during SDT. Correct users and ownership before export instead of importing content that nobody can manage.
Document storage needs special attention. Current SAP guidance says external files associated with Cloud ALM documents use the SAP BTP Document Management service; other content repositories are not directly supported in the same way.
Some transition arrangements may keep Solution Manager as an intermediary for file authorization and access. An early shutdown can therefore break document links even when the document metadata appears correctly in Cloud ALM.
Build a document register with file location, link target, owner, retention rule, access test, and shutdown dependency. The earlier research also identified document-location dependencies and one-time upload behaviour as two major gaps in competing guides.
Step 7 — Execute Selective Data Transfer in the Required Sequence
SAP defines five SDT activities: scope, export, optional adjustment, import, and validation. Use the current SDT availability chart because SAP releases capabilities in iterations; a planned relation or object type may not be available when your project starts.
Select only approved solutions, branches, processes, libraries, documents, and test assets. Export the scoped package, keep the original file unchanged, and create a controlled working copy for permitted adjustments.
Record the export date, source system, solution, branch, scope, responsible user, file checksum, and approval. This gives the solution manager to cloud alm team a reproducible audit trail.
Follow SAP’s upload sequence. Later entities can depend on process hierarchies, applications, interfaces, configurations, or libraries created earlier.
Stop when the tool reports unresolved relationships instead of importing an incomplete package and fixing it informally afterward. Validate mappings, users, tags, and target objects before approving the import.
Treat the productive import as a controlled one-time event for its selected scope. The prior research notes that another upload cannot simply update content already imported, so simulation, cleanup, mapping, and user validation must happen before production upload.
Archive the approved export, adjusted file, logs, screenshots, mapping register, and business validation. Do not use SDT as an ongoing synchronization tool.
Step 8 — Rebuild Solution Manager to Cloud ALM Processes
A solution manager to cloud alm transition requires fresh Cloud ALM configuration for most operations scenarios rather than transfer of Solution Manager monitoring history. Register supported services and systems in Landscape Management, set up data collection, define thresholds, subscribe responsible teams to alerts, configure notification routes, and write operating procedures.
Validate equivalent outcomes, not identical screens. Cloud ALM Health Monitoring does not copy the Solution Manager MAI template model, and several operations functions follow a different structure.
For ECC 6.0 or Business Suite 7, verify each operations capability against SAP’s supported-solutions documentation before retiring the old monitor. Business Suite 7 support exists for capabilities including Health Monitoring, Job and Automation Monitoring, Business Process Monitoring, Integration and Exception Monitoring, and Configuration and Security Analysis, subject to their documented prerequisites.
SAP also identifies operations gaps and alternatives. Examples include SAPGUI-based synthetic monitoring, simulated RFC or HTTP interface calls, and cross-use-case analytics.
For testing, SAP supports transfer of test cases and Focused Build test steps through SDT. BPCA content, TBOMs, and Scope and Effort Analyzer content are not planned for transition.
Decide whether to rebuild test-scope logic, use Cloud ALM manual testing, or connect an approved automation product. Do not describe unsupported content as a future transfer unless the current SAP roadmap confirms it.
For change management, close open ChaRM cycles where practical and redesign release and deployment control around Cloud ALM Features, transports, and the chosen deployment tooling. SAP does not plan direct transfer of ChaRM-related data.
For ITSM, configure the external ticketing platform and integration flow. Do not expect incidents, service requests, custom status profiles, or ticket history to appear automatically in Cloud ALM.
Step 9—Validate, Cut Over, and Decommission Without Breaking Evidence
Approve the final solution manager to cloud alm cutover only when every workstream passes measurable exit criteria. Freeze relevant source changes, complete the approved transfer, activate target monitoring, publish support procedures, and place transitioned Solution Manager areas into read-only mode.
At the content level, compare counts and sample process nodes, test assets, relations, owners, tags, diagrams, and document links. Do not validate only the number of imported objects.
At the operations level, trigger known events and confirm collection, threshold evaluation, alert creation, notification delivery, ownership, and closure. Run these checks with the actual support team.
At the process level, execute one complete requirement-to-deployment or incident-to-resolution scenario through the future toolchain. Include transport control, testing evidence, approvals, failure handling, and reporting.
At the governance level, confirm role separation, audit access, retention, backup, support ownership, and fallback procedures. Use signed evidence such as “all 42 in-scope test cases imported and sampled” rather than “upload successful.”
Do not shut down Solution Manager while legal records, external file links, open work, RFC dependencies, background jobs, interfaces, service delivery, or audit reports still depend on it. Create a dated decommission plan with the backup policy, read-only duration, access restrictions, dependency-removal tasks, and final business approval.
Common Solution Manager to Cloud ALM Issues
Readiness Check sections are empty. Update SAP Note 3236443, rerun the collector in the representative Solution Manager system, and replace the analysis data when new collector fields are required.
Users see no Cloud ALM applications. Confirm that the user exists in Identity Authentication and Cloud ALM, then verify role assignment, project access, and capability-specific authorization.
A second SDT package does not repair imported content. Stop treating SDT as synchronization. Correct scope, mappings, users, tags, and document handling before the controlled production import.
Document URLs fail after shutdown. Identify where each physical file resides, move it to an approved repository when required, update links, and test with non-administrator accounts before decommissioning Solution Manager.
Teams expect ChaRM or ITSM history to appear. Keep required source records read-only, close open cycles where possible, and implement the new Cloud ALM or third-party process before removing access.
Conclusion
A successful solution manager to cloud alm migration depends on clear scope, accurate usage data, and realistic capability decisions. Start with SAP Readiness Check, identify what can be transferred, and separate the functions that must be rebuilt, replaced, retained, or retired. This approach reduces cutover risks and prevents teams from assuming that SAP Cloud ALM is a direct technical copy of Solution Manager.
Keep Solution Manager available during coexistence until monitoring, documents, testing, ChaRM, ITSM, and audit dependencies have approved target processes. Validate each workstream with measurable evidence before decommissioning the source platform. When treated as a phased ALM transformation, the solution manager to cloud alm transition becomes easier to control, test, and support.
Frequently Asked Questions
1. Can every SAP Solution Manager capability move to SAP Cloud ALM?
No. A SAP Cloud ALM migration cannot transfer or replace every Solution Manager function. Run Readiness Check, review KBA 3427582, and classify each capability as transfer, rebuild, replace, temporary retention, or retirement before approving the target scope.
2. How should ChaRM change types be mapped to SAP Cloud ALM?
Do not map ChaRM transaction types one by one. The SAP Solution Manager transition requires process redesign because SAP does not plan to transfer Change Control Management data. Close open cycles where practical, retain required history, and configure Cloud ALM deployment functions for future work.
3. Can Solution Documentation and attached documents be migrated?
Selected process and document content can move through Selective Data Transfer SAP, but file handling depends on storage and supported SDT entities. Test document links, permissions, and retention before shutdown because metadata may transfer while physical files still depend on Solution Manager or BTP Document Management.
4. Can SAP Cloud ALM manage ECC before an S/4HANA migration?
Yes, several SAP Cloud ALM implementation and operations capabilities support SAP Business Suite 7 and ABAP-based on-premise systems. Coverage varies by use case, so check the current supported-solutions list for Health Monitoring, jobs, integrations, real-user monitoring, and business-process monitoring before onboarding ECC.
5. Is SAP Cloud ALM a full replacement for SAP Solution Manager?
No. The SAP Cloud ALM vs Solution Manager comparison shows different architectures, processes, and capability coverage. Cloud ALM supports strategic implementation and operations use cases, but it does not include Solution Manager ITSM or direct migration of every ChaRM, reporting, testing, and monitoring asset.
6. How long does a Solution Manager to Cloud ALM migration take?
There is no reliable fixed duration. A SAP Solution Manager 2027 transition depends on active capabilities, document volume, ChaRM and ITSM usage, connected systems, SDT scope, regulated requirements, and coexistence testing. Estimate each workstream after Readiness Check instead of accepting an unsupported three-, six-, or twelve-month figure.
7. Is SAP Cloud ALM free for existing SAP customers?
Eligible customers can request a tenant without an additional subscription charge when their support agreement includes the required usage rights. Confirm entitlement before planning the SAP Cloud ALM Readiness Check, because SAP Standard Support alone does not provide Cloud ALM usage rights unless another eligible cloud subscription exists.
8. Can I automate Solution Manager test-plan creation with ABAP before migration?
Yes, ABAP can automate SolMan test-plan creation, but do not build an SAP Cloud ALM migration around direct updates to internal tables. Use supported APIs and SDT for target transfer, and reserve custom ABAP for read-only inventory, validated extraction, or controlled preprocessing.
