Getting started with SAP Cloud ALM: the practical guide for S/4HANA programs and test leaders

If you are starting an S/4HANA program in 2026, someone has already asked you which tool will hold the requirements, the test cases and the defects. For most SAP customers the answer is now SAP Cloud ALM. The harder question is what happens to everything you already run: a Solution Manager system full of ECC documentation, an ALM/Quality Center instance with years of test history, and an automation suite nobody has maintained since the last upgrade. This guide is written for that person. It walks through Cloud ALM from tenant request to go-live, with the most depth where testing leaders need it, and it treats the two-tool transition as the main event rather than a footnote.

The motion: S/4HANA in Cloud ALM, ECC where it is

Here is the pattern I see in almost every large ECC customer that has started its S/4HANA move. The legacy estate keeps its legacy ALM tools. Solution Manager keeps the ECC process documentation, change control and, often, technical monitoring. Quality Center keeps the ECC test library, test sets, run history and defects. The new S/4HANA program starts clean in SAP Cloud ALM, and the old tools are retired when ECC is.

SAP’s own transition guidance points the same way. For implementation work, it recommends finishing running projects in Solution Manager and starting new projects in Cloud ALM^[5]. Its example scenarios include one where a new S/4HANA project runs in Cloud ALM while other parts of the company stay on Solution Manager, and another for customers who use non-SAP ALM tools, where the advice is to evaluate Cloud ALM and check the published APIs and migration options^[4].

Organizations choose this split for four practical reasons:

• The content model changed. S/4HANA projects in Cloud ALM start from SAP Best Practices solution processes and SAP Activate tasks^[24]. Your ECC blueprint was built around custom transactions and a design that S/4HANA will replace. Pushing it into the new tool brings the old design with it.
• The calendar forces it. Solution Manager 7.2 leaves mainstream maintenance at the end of 2027, and SAP recommends finishing the move to Cloud ALM before then^[3]. A multi-year S/4HANA program that starts in Solution Manager will finish in a tool on borrowed time.
• Migration tools are selective by design.SAP’s Selective Data Transfer (SDT) moves solution documentation from Solution Manager one time; it is not a synchronization^[57]. There is no SAP tool that turns a Quality Center project into a Cloud ALM project.
• ECC still needs care. Until cutover, ECC gets fixes, legal changes and regression testing. The team doing that already knows Quality Center and Solution Manager, and retraining them for a system they will switch off rarely pays back.

The rest of this guide sets up Cloud ALM for the S/4HANA side, then returns to the hard part in running the two worlds side by side: what moves, what stays, how to govern both, and how to switch the old tools off.

What SAP Cloud ALM is (and isn’t)

SAP describes Cloud ALM as a cloud-native solution and the central entry point for managing an SAP landscape^[1]. The application help groups it into four areas: Implementation, Operations, Service, and SAP Business Transformation Center for data transformation projects, plus a RISE with SAP methodology area for clean core^[6]. For a testing leader, Implementation is where you will live. That area covers projects and tasks, process scope, requirements, user stories, features, documents, quality gates, test preparation, test plans, test execution, defects and analytics^[24].

What Cloud ALM is not matters just as much:

• Not a like-for-like Solution Manager.SAP’s terminology mapping between the two products states plainly that it doesn’t indicate feature parity^[7].
• Not a test automation engine. Automated test cases are created and executed in a connected automation provider; Cloud ALM triggers them and stores the results^[53].
• Not a transport system.Cloud ALM orchestrates transports through CTS, Cloud Transport Management or the Adaptation Transport Organizer; it doesn’t talk to the SAP systems directly for deployments^[55].

You can see the real screens before you have a tenant. SAP runs a free Cloud ALM demo tenant with sample data for implementation and operations^[60], and the Help Portal documents every app with screenshots. The illustrations in this guide are redrawn from that documentation so you know what to look for.

Cloud ALM vs Solution Manager vs Quality Center

Most comparison pages stop at Cloud ALM versus Solution Manager. If your testing team lives in Quality Center, that is only half the picture. The table below puts all three side by side for the things a program and test leader decides on.

Sources for the SAP columns: the terminology mapping^[7], the FAQ on Solution Manager maintenance^[2], and SAP’s description of Cloud ALM as a cloud-native service^[1]. The vocabulary shift trips people up in the first month, so learn it early: a Solution Manager test step becomes a test activity and test action; a test package becomes a test plan; the Test Suite maps to four apps (Test Preparation, Test Plans, Test Execution and Defects); a ChaRM change becomes a feature; a logical component group becomes a system group^[7].

Who gets it and what it costs

There is no separate license for Cloud ALM^[1]. Customers with SAP Enterprise Support, Product Support for Large Enterprises, or Enterprise Support cloud editions can request their own tenant at no charge, and RISE with SAP customers can use their tenant without an additional license or subscription fee^[2]. Standard Support customers are excluded unless they also hold a cloud subscription with Enterprise Support^[2]. The entitlement is one tenant per customer number^[8].

The included resources are 24 GB of SAP HANA memory and 24 GB of outbound API data transfer per month^[9]. If you need more, SAP sells a tenant extension. Each extension adds another 24 GB of memory and 24 GB of monthly API transfer, which you can use for a second tenant or to enlarge the first^[10]. A second tenant is a reasonable buy if you want a sandbox for training or for testing your own Cloud ALM configuration before it reaches the productive tenant^[10].

One usage-rights detail matters for the hybrid motion: Cloud ALM may be used for lifecycle management of your on-premise SAP solutions when they are covered by an SAP support agreement^[8]. Your ECC systems can be registered in Cloud ALM for monitoring even while their test assets stay in Quality Center.

Provisioning your tenant, step by step

Provisioning takes an afternoon of decisions and very little clicking. Get the decisions right, because two of them can’t be undone. Track them in the Cloud ALM onboarding checklist.

1. Confirm the person who requests it

You need an S-user with the SAP for Me authorization Edit Cloud Data, assigned to the right customer number^[12]. Choose this person carefully. The S-user who requests Cloud ALM becomes the Main IT Contact and receives the authorizations for initial setup and administration, so SAP advises that only someone who will actually do the setup should submit the request^[11]. If the Provisioning dashboard shows nothing even though you have the authorization, SAP points to an entitlement problem and the usage-rights page^[12].

2. Request the tenant

From the Cloud ALM page on the SAP Support Portal choose Request, which opens the Provisioning dashboard in SAP for Me. Find Cloud ALM under Systems to be Provisioned and choose Start Provisioning^[11]. If Cloud ALM appears under Provisioning Status instead, someone at your company has already requested it^[12]. Find that tenant before you request anything, because the entitlement is one per customer number.

3. Make the three permanent choices

• Region. The region is the data center that will host the tenant; SAP recommends one close to your main business applications^[11]. US customers can choose US East (Virginia) or US West (Quincy, Washington), among others^[13]. You can’t move a tenant to another data center later without dismantling it and losing data^[13].
• Subdomain. It must be unique, should contain your company name, ends with -cloudalm, becomes part of the tenant URL, and can’t be changed after provisioning^[11].
• Identity Authentication tenant. If you already have a productive SAP Cloud Identity Services Identity Authentication (IAS) tenant, select it; if not, a new one is created in or near your region^[11]. Most enterprises should reuse the IAS tenant their other SAP cloud services already trust.

4. Activate and secure the administrator access

If a new IAS tenant was created, the Main IT Contact receives an email titled Activate Your Account for Identity Authentication Service and becomes its administrator^[15]. SAP lists the authorizations needed for the remaining setup: IAS Administrator, Global Account Administrator and Subaccount Administrator in the SAP BTP cockpit, and Global Administrator or User Administrator in Cloud ALM. It also recommends assigning them to at least one more person^[14]. Do that on day one. A single administrator who changes jobs is the most common reason I see programs locked out of their own tenant.

Users, roles and Identity Authentication

Cloud ALM signs users in through IAS. A user has to exist in both the IAS tenant and Cloud ALM before they can log on^[15]. If your company signs in through a corporate identity provider, IAS acts as a proxy in front of it. SAP warns that switching to a corporate identity provider after Cloud ALM is in productive use can invalidate user IDs and deactivate users^[15], so make that decision before you onboard the project team, not after.

Once users exist in IAS, add them in Cloud ALM’s User Management app (SAP’s recommended route) or as role collections in the BTP cockpit^[16]. Cloud ALM ships its roles predefined; most map one-to-one to a BTP role collection, and most are business roles that bundle the authorizations for several apps^[17]. These are the ones an implementation program uses:

Role descriptions above are paraphrased from SAP’s role list^[17]. Note the combination rules: Change Manager and Deployment Manager must be combined with Project Member or Project Lead, and Developer with Project Viewer^[17]. Map every person on the program to a row in the Cloud ALM roles and user access matrix before you invite anyone.

Authorization roles are only half of access. Each project also has an access level. Public gives read and write access to anyone with the project roles; Restricted gives non-members read-only access; and Private limits read and write to project members. New projects default to Restricted^[18]. Inside the project you also assign project roles taken from SAP Activate, such as test coordinator or deployment manager, which you use to route tasks; users added to project teams need approval by a Global Administrator or User Administrator^[18].

Connecting your landscape

The third required setup step is Landscape Management, which holds your services (subscribed cloud services) and systems (on-premise and private cloud). Everything else in Cloud ALM builds on that information^[19]. Subscribed cloud services and private cloud systems assigned to the same customer number are imported automatically; on-premise systems have to be registered or created manually^[19]. Registering a system does not start collecting monitoring data. You switch data collection on explicitly, use case by use case^[19].

For an S/4HANA program, register at least:

• The S/4HANA development, quality and production systems (and any sandbox you test in).
• The transport tooling you will orchestrate from Cloud ALM: CTS for S/4HANA Private Edition and on-premise systems, or Cloud Transport Management for supported BTP content^[55].
• Your test automation provider, registered as a service of type Test Automation (covered below).
• Optionally, the ECC systems, if you plan to monitor them from Cloud ALM before they are switched off.

Group the S/4HANA systems into system groups and a deployment plan once the transport landscape is stable; that replaces Solution Manager’s logical component groups^[7].

Setting up your first implementation project

Projects are created in the Projects and Setup app. The single most important field is the SAP Activate roadmap: selecting the product roadmap generates the Activate task list for your project. You can change the roadmap later, but doing so deletes the previous roadmap tasks^[20]. If the program has several projects (one per wave or region), create a program first; projects added to it inherit the program teams^[20]. Capture these choices in the Cloud ALM project setup workbook.

Timeboxes structure the plan. Cloud ALM predefines the five SAP Activate phases (Prepare, Explore, Realize, Deploy and Run). You can add custom phases and deactivate predefined ones, except Prepare. Sprints carry task due dates and can be locked, and milestones include Kickoff, Planned Go-Live and Actual Go-Live^[22]. Every new project gets a default PMO team that can’t be deleted; larger programs add teams by line of business, region or workstream^[18].

Two more pieces belong in setup. First, quality gates: phase-end checkpoints with checklists, predefined from SAP Activate or created from your own templates^[23]. Put your test entry and exit criteria into them so the gate is the same conversation every time. Second, the Activate task list itself. SAP’s comparison is useful here: use the public Roadmap Viewer to explore Activate before you sign, and use Cloud ALM once you have a contract, because Cloud ALM shows only content relevant to your scope and lets you assign, track and complete tasks^[21].

Scope, processes and Fit-to-Standard

Process content is the foundation of a Cloud ALM project. SAP Best Practices content gives you predefined solution processes to start from, and SAP Activate tasks cover the Fit-to-Standard workshops for the processes in scope^[24]. In the Processes app you manage scopes (for example, one scope per site or country) and open each solution process to see its solution value flow, flow diagrams, accelerators, owner, and the requirements, test cases and documents attached to it^[25]. For the customer-specific parts of your business, you build custom solution processes in Process Authoring.

Above the processes sits the process hierarchy, which mirrors how your business is organized and can hold up to 25,000 nodes^[26]. If your enterprise architects already model in SAP Signavio, decide early which tool owns the model. SAP’s learning content describes the integration as handing to-be process models from Signavio to Cloud ALM for implementation and keeping the process information in sync^[27]. If Signavio is the modeling tool, model there and treat Cloud ALM as the place where requirements, tests and documents attach to those processes.

The Fit-to-Standardworkshop is where Cloud ALM starts earning its keep. SAP frames it as a show-and-tell: confirm scope, review the processes, capture requirements for anything the standard doesn’t cover, and capture documents for insights that don’t need tasks. Each requirement is linked to its process^[24]. For a testing leader, that link is the start of traceability. Use the Fit-to-Standard test coverage map to note, process by process, what will need a test case before the workshop ends.

Requirements, user stories and features

A requirement in Cloud ALM is a business need the standard solution doesn’t meet. Once approved, it is broken down into user stories for the build team, a feature that defines how and when the change is deployed, sub-tasks, and any extra project tasks^[24]. Requirements can be approved by any team member unless a project lead assigns the Requirement Approver role, in which case only that person (or a Project Administrator) can approve^[28]. After approval the requirement moves through statuses including In Planning, In Realization, In Testing, Successfully Tested and Confirmed, and its description locks at key points^[28]. Requirements can also be uploaded from a spreadsheet, including ones exported from a third-party system^[29].

Features matter to testers more than most realize. A feature’s status runs from In Specification through In Implementation, In Testing, Successfully Tested and Ready for Production to Deployed. Moving it to Ready for Production checks that its transports can be imported to production. There is no check on assigned defects, and SAP tells you to make sure they are closed before deploying^[30]. Only Project Administrators and Project Leads can confirm a feature as successfully tested^[30]. Write both facts into your release procedure: the test lead signs off the feature, and open defects block the production approval by rule even though the tool doesn’t enforce it.

Test management end to end

This is the part of Cloud ALM that replaces Quality Center for the S/4HANA program, and it works differently. In Quality Center you build a test library and pull tests into test sets. In Cloud ALM the testing scope is derived from the project scope, test cases are built on business processes, and they connect to requirements and user stories for traceability^[24]. Get the order right and reporting comes for free. Get it wrong and you end up with a Quality Center-shaped pile of test cases that the analytics can’t see.

Test Preparation: building test cases

Cloud ALM has two test case types. Manual test cases are made of activities, and each activity is divided into actions that carry the instructions and expected result. Automated test cases are authored in the automation provider, while their general information and relations live in Cloud ALM^[31]. You can test SAP and non-SAP systems, cloud or on-premise^[32].

To create a manual test case, open Test Preparation, choose Create, pick the type Manual, and set the project, scope and, optionally, a solution process and flow diagram. SAP recommends the process-based route: selecting a flow diagram prefills the test case with activities from the process, which you then refine^[33]. Check your entries before you save. After saving, only the title can be edited in that dialog^[33], although SAP notes that scope and process assignments can still be corrected later^[31].

Inside the test case you work across tabs: General Information for priority, owner and tags; Structure to choose and order activities; Content to add actions with instructions, expected results and an Evidence Required flag; Relations to link requirements, user stories, features, documents, process hierarchy nodes, interfaces and applications; and References for links to test data sheets or training material^[34],[31]. New test cases start In Preparation. Setting them to Prepared makes them available in Test Execution^[31].

Uploading test cases from Excel

The spreadsheet upload is how most teams load volume, and it is the main path for content coming from Solution Manager or Quality Center. SAP lists three sources: the template you download from the upload dialog, SAP Best Practices test scripts found under Accelerators on each solution process, and exports from external systems such as Solution Manager^[35]. The rules are strict:

• XLSX only, up to 5 MB, 500 test cases and 10,001 rows per file^[35].
• SAP recommends no more than 20 activities and 100 actions per test case, and splitting bigger ones^[35].
• No extra sheets or columns, no renamed or reordered columns, and no images^[35].
• You pick the scope when you upload, so prepare one file per scope^[35].

The template’s columns are Test Case Name, Test Case Status, Test Case Priority, Test Case References, Test Case Owner, Tag, Activity Title, Activity Target Name and URL, Action Title, Action Instructions, Action Expected Result and Action Evidence. One action goes on each row, and you repeat the activity title for each action under it^[36]. Owners are entered by email; an address not yet in Cloud ALM is saved but shows as a former member until the user is added^[36]. Our Cloud ALM test case upload template adds a mapping sheet that turns Quality Center design steps into activities and actions, plus pre-upload checks for the empty-cell errors that cause most rejected uploads.

Test Plans: organizing cycles

Test plans are optional, but you will want them. A test plan is a set of test cases executed in a defined test cycle, and the same test case can sit in several plans, each with its own execution context. That is how you reuse one test case across SIT 1, SIT 2, UAT and regression, or across plants and company codes in a template rollout^[37].

When you create a plan you set a title, responsible person, start and end dates and tags, then assign test cases, optionally add a sequence, and assign testers. Only one tester can be assigned per test case within a plan^[38]. Plans move through three statuses: In Preparation (test cases not yet visible to testers), In Testing (all Prepared test cases in the plan are released to Test Execution, and the plan can no longer be deleted), and Finished^[38]. Build plans to mirror your SIT cycle plan, one per cycle and stream, and name them consistently because they become the grouping in every report.

Test Execution: running tests and capturing evidence

Testers start a test run by choosing Execute. Each run is one executed instance of a test case; once finished it is view-only, and a new run can be started^[39]. For each action the tester sets a detailed status: Pass, Pass with Conditions, Fail, Fail - Application Issue, Fail - Test Case Correctness, or Fail - Retest Required^[39]. The overall status rolls up to Initial, In Progress, Passed, Failed or Withdrawn, and a single failed action fails the run^[39]. Where the author set Evidence Required, a screenshot is mandatory once the tester sets a status^[39].

Teach testers the difference between the two failure types on day one. Fail - Test Case Correctness means the script is wrong, not the system, and it should go to the test author, not the defect queue. Programs that skip this end up with a defect backlog full of outdated scripts.

Defects: from failure to retest

For manual tests, defects are created inside the run, for the whole run or for a single action; for automated tests, from the test case list^[39]. The defect carries the test case and run, process hierarchy nodes, priority, responsible person or team, and planned completion date, and it can be split into sub-tasks^[40]. Defects are a task type in Cloud ALM, so they share task attributes like priority, effort and due date^[41]. A defect that recurs in another run can be assigned to that run if it isn’t closed yet, and when a new run starts, open defects from the previous run carry over^[40].

SAP’s recommended workflow is short: the processor sets In Progress, fixes, sets Retest Required and makes the original reporter Responsible; the reporter retests in Test Execution and closes the defect if it passes^[42]. Notifications always go to whoever is Responsible, so keeping that field current is the whole workflow^[42]. Cloud ALM doesn’t impose your severity model, so bring your own: our defect severity and triage matrix maps cleanly onto its priority values. Defects can also be created or updated in bulk by spreadsheet^[43].

AI help is arriving, carefully

SAP documents Joule agents that propose a test scope and generate manual test cases from a custom process diagram and its linked requirements or user stories, and another that identifies the test data a manual test case needs. Both are marked as part of an Early Adopter Care program, not general availability^[48]. Treat generated test cases like any other draft: a person reviews them before they are Prepared. Our AI-generated test review checklist is built for exactly that review.

Traceability and test reporting

Traceability is where the process-first discipline pays off. Requirement Traceability shows each requirement with the status of its user stories, project tasks, test cases and test runs, and lets you drill into any of them^[44]. Its extended filters find gaps, such as requirements with no feature assigned. With indirect assignments switched on, test cases linked through a user story and defects linked through a test run are counted too^[44]. Solution Process Traceability does the same from the process side, so you can list processes whose requirements are all Confirmed and whose test executions all Passed^[45]. That filter is the closest thing Cloud ALM has to a one-click readiness answer for a steering committee.

For progress, the Test Execution Analysis page shows runs by status over time, executed manual actions per day against the remaining total, and distribution by scope or test plan, with a table view you can export^[46]. The Overview app adds Test Execution, Failed Manual Test Actions and Defect Distribution cards^[47]. One caution from SAP’s documentation: setting a test case back to In Preparation after testing has begun removes its executed runs from Test Execution Analysis^[31]. Lock down who can do that during a cycle. If you still need the classic matrix for auditors, our requirements traceability matrix template is laid out to be filled from a Cloud ALM export.

Test automation in Cloud ALM

Cloud ALM does not run automated tests itself. It integrates SAP and third-party automation providers that have implemented SAP’s public Test Automation API, and adds orchestration, execution monitoring and reporting^[49]. SAP’s list of supported options has three entries: the test automation tool for SAP S/4HANA Cloud Public Edition, which tests the SAP Best Practices processes for that edition; a pre-integrated automation option for browser-based SAP applications; and other providers that implement the API^[49]. The vendor is responsible for implementing the API correctly and for supporting it^[49].

If you are on S/4HANA Cloud Private Edition or on-premise, the Public Edition tool doesn’t apply, so you are choosing a provider that implements the API. The integration works the same way for any of them:

1. A Global Administrator opens Landscape Management, adds a service of type Test Automationwith role Test and the provider’s root URL, and creates an endpoint with use case Test Automation, authenticated by basic authentication or OAuth2 client credentials^[50].
2. From then on, scoping processes triggers a sync to retrieve the provider’s test cases^[50]. You can also choose Synchronize Automated Test Cases in Test Preparation for a scope and provider; each data variant in the provider becomes its own test case^[51].
3. Automated test cases go into the same test plans as manual ones. Execute sends the request to the provider; Cloud ALM polls open runs and updates status and results, and links to the provider’s execution log^[52].
4. Failed automated runs get defects from the test case list, like any other failure^[39].

SAP’s API catalog describes the Test Automation API as the interface an external tool must implement: Cloud ALM calls it to synchronize test cases, get data variants, trigger execution, check job status and retrieve history^[54]. A separate Test Cases API manages manual test cases and their activities, actions and links to requirements and user stories^[54], which is useful if you generate or maintain manual test content outside Cloud ALM.

When you evaluate any automation tool for Cloud ALM, ask for proof of these in your tenant:

Features, transports and deployments

Change and Deployment Management uses features as the vehicle for moving transports through the landscape. Cloud ALM doesn’t talk to SAP systems directly for this; it orchestrates through CTS for S/4HANA Private Edition, on-premise S/4HANA and ABAP systems, through Cloud Transport Management for supported cloud content, and through the Adaptation Transport Organizer for S/4HANA Cloud Public Edition. CTS+ is not supported^[55]. With CTS you can create, assign, release, check and deploy transports from Cloud ALM^[55].

For the test team the useful part is that a feature in In Testing tells you exactly which transports are in QA, and the feature status flow gives you a natural sign-off step^[30]. Agree with the release manager that no feature moves to Ready for Production while related test cases have failed runs or related defects are open. Our test environment and transport strategy template covers the landscape side.

Running Cloud ALM alongside Solution Manager and Quality Center

This is the section most guides skip, and the one that decides whether your program has one source of truth or three half-truths. The goal for the transition years is simple to state: every artifact has exactly one home, and the home is decided by which estate it belongs to, not by which tool someone opened first.

What lives where

Two edge cases need an explicit rule. Interface and coexistence testing between ECC and S/4HANA (for example during a phased rollout) belongs to the S/4HANA program, so it lives in Cloud ALM even when the test touches ECC screens; Cloud ALM manual tests can cover non-SAP and on-premise systems^[32]. ECC fixes required by the S/4HANA program, such as a bridge interface, are raised as a requirement in Cloud ALM and implemented through ECC’s own change process; put the Cloud ALM ID in the ChaRM change and the ChaRM number in the Cloud ALM requirement as a reference.

What moves, and what deliberately doesn’t

Use the decision list below as the default. Change it only with a reason you can write down. Our Quality Center and Solution Manager to Cloud ALM migration planner turns it into an object-by-object inventory with migrate, archive or leave decisions and waves.

The SAP facts behind those calls:

• Solution Manager content. SDT scopes, exports, optionally adjusts, imports and validates solution documentation^[56]. It covers process hierarchies, libraries, custom solution processes and diagrams, documents and Focused Build test cases and steps, and it rebuilds relations using unique IDs. It is a one-time transfer with no synchronization and no rollback after upload, only deletion, so SAP suggests starting with small proof-of-concept packages^[57]. Run the SAP Readiness Check for SAP Cloud ALM first; it analyzes your Solution Manager usage and recommends Cloud ALM equivalents^[3].
• Requirements. SAP describes the transfer from Solution Manager as manual: export, then import^[5]. The same spreadsheet route works for a Quality Center export^[29].
• Test cases. The test case upload explicitly accepts exports from external systems such as Solution Manager^[35], and the same template handles a Quality Center export once it is reshaped into activities and actions.
• Change control and reporting.SAP doesn’t plan to transfer ChaRM data; its guidance is to close open change cycles in Solution Manager and then activate deployment management in Cloud ALM. Historical reporting data isn’t transferred either^[5].

I’d add one rule from experience: never migrate run history or closed defects. They prove what was tested on ECC, so they belong with ECC. Export them to a read-only archive your auditors can reach, and record where it is.

Avoiding double entry

Double entry happens when people aren’t sure which tool is the record. Four habits prevent it:

• One entry point per estate. Testers on the S/4HANA program never log defects in Quality Center, and ECC regression testers never use Cloud ALM. Enforce it with role assignments rather than memos.
• Cross-reference, don’t copy. When an S/4HANA requirement replaces an ECC process, put the Quality Center requirement ID or Solution Manager process ID in the Cloud ALM requirement or as a tag. Tags exist for exactly this kind of grouping^[34].
• Automate the few links you need. Cloud ALM publishes APIs for tasks (which include defects), requirements-related analytics, test cases and features, plus a webhook-based Resource Changes API that notifies external systems when objects change^[54]. If you must mirror something, such as S/4HANA defects that affect an ECC interface, build one integration, not a manual copy routine.
• Retire the template. Remove S/4HANA folders from Quality Center so nobody starts a test there by habit.

Reporting across both tools

Steering committees want one status page, not two tools. Cloud ALM’s Analytics API reads measurements across requirements, projects, tasks, tests and defects^[54]. Quality Center can export the same counts. Feed both into the reporting tool your PMO already uses, and agree on a shared vocabulary first: map Quality Center run statuses to Cloud ALM’s Passed, Failed, In Progress and Initial, and defect states to the four Cloud ALM uses in practice (open, In Progress, Retest Required, Closed). Keep the status report format identical for both estates so readers compare like with like.

Governance for two ALM tools

Write these down in the hybrid ALM transition plan, which lays out the system-of-record rules, the integration list and the retirement checklist in one place.

The retirement path

The dates match the ECC timeline: Business Suite 7 mainstream maintenance ends with 2027 and optional extended maintenance runs to 2030 (see what 2027, 2030 and 2033 really mean). Solution Manager does not stop working on those dates. Customers with on-premise maintenance keep the perpetual license, and support continues under customer-specific maintenance with restrictions^[2]. What ends is your ability to get new fixes for most of it. Sequence retirement like this: freeze new ECC test design, move monitoring to Cloud ALM if you haven’t, cut over the last ECC users, run a final ECC regression, archive, and switch off.

Operations after go-live

Cloud ALM for Operations covers full-stack monitoring and alerting, automation and anomaly prediction^[58]. Its apps include Health Monitoring, Business Process Monitoring, Integration and Exception Monitoring, Job and Automation Monitoring, Real User Monitoring, Synthetic User Monitoring, and Configuration and Security Analysis, each with its own viewer, processor, configurator and administrator roles^[17]. Remember that registering a system doesn’t start data collection; you configure it explicitly^[58]. For testing teams, two connections are worth making before go-live: business process monitoring KPIs for the processes you tested hardest, so hypercare sees real volumes, and job monitoring for the batch chains your cutover rehearsal depended on. Our hypercare defect triage log pairs with the Cloud ALM defect list during those first weeks.

A 30/60/90-day starter plan

This plan assumes you have an entitlement and an S/4HANA program in Prepare. Adjust the dates, not the order.

The proof-of-concept step comes from SAP’s own guide to a manual-testing PoC, which uses Best Practices test scripts and walks through test plans, execution, defects and analytics^[59]. It is the fastest way to get your test leads comfortable before the real cycle starts. For the broader program view, pair this plan with the ECC to S/4HANA migration testing plan.

Common mistakes

• One person requests the tenant and then leaves. The requester becomes the Main IT Contact with admin rights^[11]. Add a second administrator immediately^[14].
• Choosing the subdomain or region casually. Neither can be changed later^[11][13].
• Creating test cases without processes. Scope-only test cases are allowed^[31], but they fall out of process traceability. Use them for genuine exceptions only.
• Lifting Quality Center tests one-for-one. You get ECC steps in an S/4HANA tool. Migrate the scenario, rewrite the steps.
• Skipping test plans.Without plans you lose cycle-level reporting and can’t run the same test case for several plants or phases in parallel^[37].
• Resetting test cases mid-cycle. Setting a test case back to In Preparation removes its runs from analytics^[31].
• Trusting Ready for Production to check defects. It checks transports, not defects^[30].
• Letting both tools stay open for the same work. If Quality Center still accepts S/4HANA defects, some will land there.
• Assuming RISE covers Solution Manager. It doesn’t^[2].

Frequently asked questions

Is SAP Cloud ALM free?

For entitled customers, yes. One tenant per customer number is included with SAP Enterprise Support, Product Support for Large Enterprises, Enterprise Support cloud editions and RISE with SAP, with 24 GB of memory and 24 GB of monthly API transfer. Extra capacity or tenants are sold as tenant extensions^[2],[9],[10].

Does Cloud ALM replace Solution Manager?

SAP positions Cloud ALM as the go-to ALM platform for all SAP customers and recommends completing the transition before Solution Manager leaves mainstream maintenance at the end of 2027^[3]. It is not a feature-for-feature replacement^[7], so map your needs to Cloud ALM capabilities rather than Solution Manager functions.

Can Cloud ALM manage an ECC or on-premise S/4HANA system?

Yes. Cloud ALM may be used for lifecycle management of on-premise SAP solutions covered by an SAP support agreement^[8], and on-premise systems are registered in Landscape Management^[19].

Can I import my Quality Center test cases into Cloud ALM?

Yes, through the manual test case spreadsheet upload, after reshaping them into activities and actions. Files are limited to 5 MB, 500 test cases and 10,001 rows^[35]. Run history and closed defects should stay in an archive.

Can I use my own test automation tool with Cloud ALM?

Yes, if the tool implements SAP’s public Test Automation API. You register it as a Test Automation service in Landscape Management, and Cloud ALM syncs its test cases, triggers runs and pulls back results^[49],[50].

Does Cloud ALM support UAT with business testers?

Yes. The Tester role lets users view and execute test cases and create and edit defects^[17], test plans assign one tester per test case^[38], and evidence can be made mandatory per action^[31]. Pair it with your own UAT sign-off form.

How do I see real Cloud ALM screens before we have a tenant?

Use SAP’s free Cloud ALM demo tenant, which has sample data for implementation and operations^[60], and the app pages in the SAP Help Portal.

Where do I learn the vocabulary?

SAP publishes a terminology mapping between Solution Manager and Cloud ALM^[7]. Our SAP Cloud ALM, Cloud ALM test management and Solution Manager glossary entries cover the essentials, and the full SAP testing glossary covers the rest. For the bigger question of who owns testing once you move to RISE, read RISE with SAP: why testing is still your job, and subscribe to the newsletter for updates as SAP ships new Cloud ALM releases.