SAP Solution Manager 7.2 mainstream maintenance ends at the end of 2027, and SAP recommends all customers transition to SAP Cloud ALM before then. That does not mean your SolMan estate stops working in January 2028. It means the basis for planning changes, so you need an inventory of what SolMan actually does today, a decision per scenario, and a sequence that survives your ECC-to-S/4HANA programme and your AMS contract. This guide gives Basis, CoE and AMS leads an inventory-first plan. It maps common SolMan scenarios to Cloud ALM, Focused Run, retirement or keep-until-2030, with the source or the check you need before you commit. We accessed all SAP page references on 4 November 2026.
The dates that define the move
First, separate three dates that people often blur together: the end of mainstream maintenance, the optional extended maintenance window, and what happens after both. The facts box below uses SAP’s own pages. We accessed the source pages, support.sap.com/en/alm/solution-manager.html and support.sap.com/en/alm/faq.html, on 2026-11-04.
| Question | What SAP states | Source |
|---|---|---|
| When does mainstream maintenance end? | SAP says: “Mainstream maintenance for SAP Solution Manager 7.2 is available until the end of 2027.” | SAP Solution Manager page |
| What is the exact end date? | SAP says: “Mainstream maintenance for SAP Solution Manager ends on December 31st, 2027.” It adds: “SAP recommends to complete the transition to SAP Cloud ALM before this date.” | Transition to SAP Cloud ALM page |
| Is there an extension? | SAP says: “Extended maintenance is an option available until end of 2030 for selected functionality”. | SAP ALM FAQ |
| Who gets extended maintenance, and at what cost? | SAP says: “Customers who choose the optional extended maintenance for SAP Business Suite 7 (until end of 2030)” will “receive extended maintenance for SAP Solution Manager 7.2 at no additional cost.” Confirm your own contract position with SAP. | SAP Solution Manager page and SAP ALM FAQ |
Covered functions, licence rights and add-on dates
| Question | What SAP states | Source |
|---|---|---|
| Which functionality is covered by extended maintenance? | SAP’s list “only includes requirements management, project management, process management, test suite, change control management, IT service management (ITSM) and landscape management.” | SAP Solution Manager page |
| What happens to other functions? | SAP says: “Other functions of SAP Solution Manager will be available with customer-specific maintenance.” | SAP ALM FAQ |
| Does Solution Manager stop working? | SAP says: “Customers with on-prem SAP maintenance agreements retain the perpetual license for SAP Solution Manager.” And: “They can continue using SAP Solution Manager after end of mainstream or extended maintenance.” SAP also states it “will be supported beyond 2027/2030 – in customer specific maintenance”. | SAP ALM FAQ |
| What is SAP’s recommended direction? | SAP says: “SAP recommends all customers to transition to SAP Cloud ALM before the end of 2027.” | SAP Solution Manager page |
| Do the add-ons follow the same dates? | SAP says: “This applies for the Focused Build and Focused Insights add on as well.” | SAP ALM FAQ |
What the dates mean for your plan
Read the function list literally. Extended maintenance to 2030 is not a general extension of SolMan 7.2. Instead, it is an option for selected functionality, and other functions move to customer-specific maintenance. Also, end of maintenance is not switch-off. Customers with on-premise SAP maintenance agreements keep a perpetual licence, and SAP’s FAQ says customers can continue using SolMan after mainstream or extended maintenance.
That is why this article treats 2027 and 2030 as planning dates, not a forced cutover date. The practical risk is not that SolMan disappears. The risk is that you enter the extended period without a decision record, without a successor process for unsupported scenarios, and without knowing who owns the tooling in your AMS contract.
Why a function-to-function map fails
SAP is explicit that there is no one-to-one replacement. The FAQ states: “There is no functional parity between SAP Cloud ALM, SAP Solution Manager, or SAP Focused Run.” That single sentence should change the shape of your programme. So do not start with a matrix that asks where ChaRM is in Cloud ALM. Start with a usage inventory that asks: what outcome does this SolMan scenario produce, who consumes it, what evidence does it leave, and what is the successor process?
The destination may be Cloud ALM, Focused Run, retirement, or keep-until-2030. Some scenarios also split. Test cases may transfer, but BPCA content and TBOMs are not planned to transfer. Process documents move only through Selective Data Transfer and BTP DMS. Business process monitoring in Cloud ALM addresses business users only. This is exactly why the Readiness Check exists.
Step 1: run SAP Readiness Check for SAP Cloud ALM
Before workshops, before a tool decision and before an AMS change request, run the Readiness Check. SAP describes it as a service that “assesses your SAP Solution Manager landscape and helps you plan your transition to SAP Cloud ALM”. It provides “recommendations for equivalent functionalities in SAP Cloud ALM.” You can “Open the SAP Readiness Check app in SAP for Me.” or “create the analysis within SAP Cloud ALM”.
Where to run the collector and what to follow
SAP’s page also tells you to implement the SAP note it references and to run the collector. Use the current page as your instruction, not a copied note number from a slide. On where to run it, SAP says “it is recommended to run the collector in the system where the usage of capabilities is more representative.” For most estates that means production, because a sandbox understates real usage. Then use the “Transition to SAP Cloud ALM roadmap as project template to build the plan for your transition.”
Treat the output as evidence, not approval
The output is evidence for your inventory, not an approval to migrate. Treat it as the first version of the usage baseline. Validate it with the people who run ChaRM, the test suite, process documentation, monitoring and ITSM. Include the AMS lead early, because the Readiness Check will expose scenarios that sit in the AMS scope. If your estate also includes Focused Build or Focused Insights, check the add-on rows. Do not assume they follow the core SolMan timeline.
SolMan usage inventory: map each scenario to a destination
The table below is a starting map, not a SAP commitment. Status words are as at 2026-11-04 and are subject to SAP change. Where the source is not specific enough for a commitment, the row says “confirm in SAP Readiness Check”. So use the table to structure decisions with named owners, not to replace the Readiness Check output.
Change, requirements and project scenarios
| SolMan scenario | Destination to test | What SAP’s pages say or what to decide | Source or check |
|---|---|---|---|
| Change control (ChaRM) | Cloud ALM Change and Deployment Management, with a new successor process | SAP states: “Transition of Change Control Management – related data from SAP Solution Manager to SAP Cloud ALM is not planned.” SAP recommends: “close open change cycles in SAP Solution Manager, then activate Deployment Management in SAP Cloud ALM.” | SAP transition to Cloud ALM implementation page |
| Focused Build methodology and Focused Build test steps | Cloud ALM, but plan on a process redesign, not a data move | SAP lists “Adoption of Focused Build methodology planned” and states “Transition of Focused Build test steps is planned.” The same page’s test suite row says test cases and Focused Build test steps can be transferred with Selective Data Transfer, so SAP’s own page is inconsistent on test steps as at 2026-11-04. Methodology adoption is planned, not available. | SAP transition to Cloud ALM implementation page; confirm in SAP Readiness Check |
| Requirements management | Cloud ALM, with manual export and import | SAP states: “Requirement Management is provided by SAP Solution Manager and SAP Cloud ALM.” And: “you can manually export requirements from SAP Solution Manager and import them into SAP Cloud ALM.” | SAP transition to Cloud ALM implementation page |
| Project management and WBS | Cloud ALM for new projects; finish running projects in SolMan | SAP states: “Project Management is provided in SAP Solution Manager and SAP Cloud ALM.” And: “SAP recommends to finish running projects in SAP Solution Manager and start new projects in SAP Cloud ALM”. | SAP transition to Cloud ALM implementation page |
Testing, documentation and business process monitoring
| SolMan scenario | Destination to test | What SAP’s pages say or what to decide | Source or check |
|---|---|---|---|
| Test suite | Cloud ALM, with selective evidence retention in SolMan | SAP states that transfer of test cases and Focused Build test steps “is possible using the selective data transfer tool.” But “Transition of BPCA content and TBOMs is not planned.” And “Transition of Scope and Effort Analyzer (SEA) content is not planned.” | SAP transition to Cloud ALM implementation page |
| Process documentation | Cloud ALM via Selective Data Transfer and BTP DMS | SAP states: “SAP Cloud ALM only supports storing external files associated with SAP Cloud ALM documents exclusively in BTP DMS.” And “The use of content servers or other document repositories is currently not supported.” The move “must be carried out exclusively using Selective Data Transfer.” | SAP transition to Cloud ALM implementation page |
| Business process monitoring | Cloud ALM for business-user monitoring; confirm coverage | SAP states: “Business Process Monitoring in SAP Cloud ALM addresses business users only.” And: “It is not our target to cover the complete scope currently available for SAP Solution Manager.” | SAP transition to Cloud ALM operations page; confirm in SAP Readiness Check |
Technical, job, integration and advanced monitoring
| SolMan scenario | Destination to test | What SAP’s pages say or what to decide | Source or check |
|---|---|---|---|
| Technical and system monitoring | Cloud ALM Health Monitoring for basic ABAP on-premise; Focused Run where depth is required | SAP states: “Transition to Health Monitoring in SAP Cloud ALM to provide basic system monitoring for ABAP-based on-premise systems.” But “The MAI infrastructure is not available in SAP Cloud ALM.” And “Only SAP HANA as database for ABAP systems is included in Health Monitoring.” | SAP transition to Cloud ALM operations page |
| Job and automation monitoring | Cloud ALM for basic cases; Focused Run or keep-until-2030 where needed | SAP maps Job Monitoring to Job and Automation Monitoring, but states “Non-ABAP on-premise systems are not covered by SAP Cloud ALM.” For BI and BusinessObjects monitoring, SAP says “This is not available in SAP Cloud ALM.” List the job types you actually monitor before committing. | SAP transition to Cloud ALM operations page; confirm in SAP Readiness Check |
| Integration monitoring | Cloud ALM with limits; Focused Run alongside where needed | SAP maps interface, PI and message flow monitoring to Integration Monitoring, and states: “Support for other non-ABAP systems is not planned.” Validate the interfaces you actually run. | SAP transition to Cloud ALM operations page; confirm in SAP Readiness Check |
| Heavy or advanced monitoring | Focused Run alongside Cloud ALM | SAP states: “For extensive on-premise or advanced monitoring needs, SAP Focused Run can be added alongside to SAP Cloud ALM.” SAP also describes Focused Run as “designed for businesses that need high-volume system and application monitoring, alerting, and analytics.” On cost, SAP says: “Only SAP Focused Run needs to be licensed separately.” | SAP transition to Cloud ALM operations page and SAP ALM FAQ |
ITSM, quality gates and local repositories
| SolMan scenario | Destination to test | What SAP’s pages say or what to decide | Source or check |
|---|---|---|---|
| ITSM and service desk | Keep until 2030 as a listed function, then a separate ITSM tool chosen by the customer | SAP states: “SAP Cloud ALM does not provide IT Service Management, therefore no transition is required.” SAP’s guidance is to plan a move to a third-party ITSM tool. ITSM is in the extended-maintenance function list, so keep-until-2030 is a valid bridge, not a destination. | SAP transition to Cloud ALM implementation and operations pages |
| Quality Gate Management | No Cloud ALM equivalent today: redesign the gate in the successor change process, or retire it | SAP lists Quality Gate Management as “currently not in scope” for SAP Cloud ALM and gives no transition guidance. Treat it as an explicit decision item with a named owner, not an automatic carry-over. | SAP transition to Cloud ALM implementation page |
| Local document repositories and bespoke SolMan reports | Retire or replace; keep the decision record | Cloud ALM stores external files only in BTP DMS. SAP says a content server you must keep “can be only integrated with SAP Cloud ALM, with SAP Solution Manager serving as an intermediary.” On reporting, SAP states: “Transfer of reporting and analytics data is not provided.” Decide what evidence must be exported before retirement. | SAP transition to Cloud ALM implementation page; confirm in SAP Readiness Check |
Where teams are most often surprised
The rows that most often surprise teams are ChaRM, ITSM and monitoring. ChaRM looks like a tool move but is a process move with no history transfer.
ITSM looks like it must go to Cloud ALM. However, SAP says Cloud ALM does not provide IT Service Management at all. The listed ITSM function is a keep-until-2030 bridge while you choose a separate ITSM tool. Monitoring looks like one bucket, but SAP separates basic Health Monitoring, business process monitoring for business users, and Focused Run for high-volume or advanced needs. Treat each as a separate decision.
ChaRM and Focused Build: design the successor process first
ChaRM is the clearest example of why a data-migration plan is the wrong plan. SAP states that transition of Change Control Management-related data from SolMan to Cloud ALM is not planned. That means open cycles, approvals and change-document history do not move as part of a standard transition. Instead, you need a successor process. SAP’s own recommendation is to close open change cycles in SolMan and then activate Deployment Management in Cloud ALM. Build the cutover around that sequence. First, freeze or close the old cycles. Then define who approves what in the new tool, and test the deployment path before you move a production change.
Check the deployment path before the first change cycle
The deployment path needs its own check. SAP’s help page for Change and Deployment Management states that it “doesn’t directly communicate with SAP solutions.” It integrates with CTS, CTMS and ATO, and “CTS+ is not supported.” So if your transport route depends on CTS+, you have a project decision, not a configuration detail. Confirm the supported deployment tool for each landscape. Then document the exception before the first Cloud ALM change cycle.
Plan Focused Build methodology and test steps
Focused Build needs the same discipline. SAP lists Focused Build methodology adoption as “planned”, not available, as at 2026-11-04 and subject to SAP change. On test steps, the same SAP page says both that transfer is possible with Selective Data Transfer and that SAP plans the transition. So test it in a non-production transfer rather than trusting either line.
Test-case transfer is not the same as Focused Build parity. Do not write a plan that assumes Focused Build practices will be available on your go-live date. Instead, decide which Focused Build practices are mandatory, which you can re-engineer, and which need a temporary SolMan keep-alive. Then record those decisions and re-check the SAP page before you publish your internal plan.
What to keep and what to migrate: a decide-and-record checklist
This is a practical checklist, not a compliance requirement. Your auditors or regulators may ask for more or less. The point is to make an explicit record of what stays in SolMan, what moves, what you export, who owns it and how long you retain it.
- Open change cycles: close or transfer them in SolMan before activating Cloud ALM Deployment Management. SAP does not plan a ChaRM-related data transition.
- Closed change history and approvals: decide whether to keep read-only access in SolMan, export the evidence, or both. Record the retention owner.
- Test cases and test evidence: transfer test cases where possible. SAP does not plan to transfer BPCA content, TBOMs and SEA content, so export the evidence you need and record the exception.
- Process documents: move only through Selective Data Transfer to BTP DMS. You can reach a content server you keep only through SolMan as an intermediary, so it ties you to SolMan. Classify documents before the move and retire what no longer has an owner.
- Requirements: use the manual export and import route. Decide whether closed requirements need to move at all.
Projects, reporting, roles and retirement
- Projects and WBS: finish running projects in SolMan and start new projects in Cloud ALM. Record the baseline for any project that crosses the cutover.
- Reports and dashboards: SAP states that it does not provide transfer of reporting and analytics data, and Cloud ALM collects new data after activation. Export the history you need for trend or audit questions.
- Roles and approvals: map who approves changes, tests and releases in the new tool. A tool move without a role map creates a control gap.
- Retirement record: for every scenario you retire, record the reason, the last owner, the retention decision and the date. This is the evidence that you made the decision, not that you met a compliance standard.
Need a second pair of eyes on your SolMan inventory?
Altivate helps Basis, CoE and AMS teams assess SolMan usage, interpret the Readiness Check output and build a scenario-by-scenario decision record.
Sequencing against ECC-to-S/4 and your AMS contract (our view)
The following sequencing is Altivate’s view and typical approach, not an SAP commitment. The date hook is SAP’s: “SAP will provide mainstream maintenance until the end of 2027 for SAP Business Suite 7 core applications,” which include SAP ERP 6.0, with optional extended maintenance “from the beginning of 2028 until the end of 2030.” SolMan 7.2 ends mainstream maintenance on the same day. Its extended maintenance comes with Business Suite 7 extended maintenance.
So the ECC decision and the SolMan decision share a deadline. If your ECC-to-S/4HANA programme is live, you have two programmes touching the same change, test and documentation backbone. Do not run a full SolMan-to-Cloud ALM transition and an S/4 conversion in the same change window unless you have deliberately separated the change and test records. If you are still deciding on the ECC-to-S/4HANA route, our guide on whether to upgrade from SAP ECC to SAP S/4HANA covers that decision separately.
Our recommended order of work
Our sequence is: inventory, Readiness Check, scenario decisions, SolMan stabilisation, Cloud ALM stand-up, selective movement, AMS contract update, then cutover. In practice that means you close open ChaRM cycles and finish running projects in SolMan before you ask teams to start new work in Cloud ALM. Stand up Cloud ALM for new projects and new change cycles first, while SolMan remains the record for historical evidence.
Move process documents through Selective Data Transfer, transfer test cases where possible, export what cannot move, and record the exceptions. Keep ITSM in SolMan until 2030 only if that is a deliberate decision with an owner and a review date. Otherwise, plan a separate ITSM tool as a customer-specific choice.
Cloud ALM, RISE and AMS ownership
Cloud ALM often appears inside a RISE with SAP or GROW conversation, but the commercial wrapper should not replace the inventory. If you are comparing the two routes, see our RISE vs GROW with SAP comparison. The ALM tool decision still needs a technical owner, a data owner and an operating model.
In an AMS deal, decide who owns the ALM tooling. SAP’s FAQ is direct here: “SAP Cloud ALM isn’t prepared from technical as well as legal perspective for AMS partner business.” And: “Our clear recommendation is SAP Focused Run as platform for AMS providers.” Our reading is that the Cloud ALM tenant should belong to the customer, with the AMS provider given access, while a provider’s own Focused Run may hold monitoring history that leaves with the provider.
Put tenant ownership, admin rights, monitoring scope and what is handed back at exit in the contract. Our white paper The SAP AMS Buyer’s Guide covers transition and exit terms in more detail. Our application managed services (AMS) page describes the operating model. For a sector view, see the companion post on the SAP managed services operating model for oil and gas.
Aligning the freeze with the S/4 programme
One more sequencing rule: align the SolMan freeze with your S/4 programme’s change freeze, not against it. If the S/4 programme is using SolMan ChaRM for its own changes, the ALM transition must not remove the change backbone mid-programme.
Either keep the relevant SolMan scenarios alive until the S/4 cutover is stable, or move the S/4 programme’s change process to Cloud ALM first and prove it in a non-production landscape. Record which system is the source of truth for change, test and documentation at each milestone.
Where Altivate fits
Altivate is an SAP Gold Partner and ISO/IEC 27001 certified. We help with assessment and planning for SolMan estates. That covers usage inventory workshops, Readiness Check interpretation, scenario decisions, sequencing against the S/4 programme and the AMS contract, and the decision record that supports an audit conversation. We do not publish a count of SolMan migrations, and we do not claim a like-for-like Cloud ALM replacement. Instead, the value is in a defensible plan that separates what moves, what retires, what stays until 2030 and who owns each outcome.
Turn the 2027 date into a decision record
Bring your SolMan inventory, Readiness Check output and AMS scope. We will help you structure the scenario decisions and the sequence.
Frequently asked questions
Does SAP Solution Manager 7.2 stop working at the end of 2027?
No. Mainstream maintenance ends on 31 December 2027, but SAP states customers can continue using Solution Manager after end of mainstream or extended maintenance. Customers with on-premise SAP maintenance agreements keep a perpetual licence, and support beyond that moves to customer-specific maintenance. Treat 2027 as the end of mainstream maintenance, not switch-off.
What does extended maintenance to 2030 cover?
It is an option for selected functionality only. SAP’s list includes requirements management, project management, process management, test suite, change control management, ITSM and landscape management. Other functions go to customer-specific maintenance. Confirm eligibility and scope with SAP; do not treat 2030 as a general SolMan extension.
Is Cloud ALM a functional replacement for Solution Manager?
No. SAP states there is no functional parity between Cloud ALM, Solution Manager and Focused Run. Use an inventory to decide per scenario: Cloud ALM, Focused Run, retire, or keep until 2030. Some scenarios split, and some have no data transition.
What should we do first?
Run SAP Readiness Check for SAP Cloud ALM. It assesses your Solution Manager landscape and helps plan the transition to Cloud ALM. Use it in SAP for Me or inside Cloud ALM, then validate the output with the owners of ChaRM, testing, process documentation, monitoring and ITSM.
How does ChaRM data move to Cloud ALM?
It does not move as a standard data transition. SAP states that transition of Change Control Management-related data is not planned. SAP recommends closing open change cycles in Solution Manager and then activating Deployment Management in Cloud ALM. Treat it as a successor process, not a data migration.
Is Focused Build available in Cloud ALM?
Not as a like-for-like product. As at 2026-11-04, SAP lists Focused Build methodology adoption as planned, not available, and subject to SAP change. SAP’s transition page is inconsistent on Focused Build test steps, calling transfer both possible and planned, so test it in a non-production transfer. Test cases can be transferred with Selective Data Transfer.
Should we keep ITSM in Solution Manager?
Only as a bridge. SAP states that Cloud ALM does not provide IT Service Management, and its guidance is to plan a move to a third-party ITSM tool. ITSM is in SAP’s extended-maintenance function list, so keeping it in SolMan until 2030 is a valid option to test while you choose and implement that tool. Decide based on your service model, not on a default tool map.
Can we run Solution Manager and Cloud ALM in parallel?
A parallel period is normal for inventory and cutover, but the end date for each scenario is your decision. Do not assume two-way synchronisation: ChaRM data transition is not planned, requirements use manual export and import, and documents use Selective Data Transfer to BTP DMS. Record which system is the source of truth at each milestone.
Sources
All accessed 2026-11-04. SAP states on its transition pages that “This is the current state of planning and may be changed by SAP at any time.”
- SAP Solution Manager (support.sap.com)
- Transition to SAP Cloud ALM (support.sap.com)
- SAP ALM FAQ (support.sap.com)
- SAP Readiness Check for SAP Cloud ALM (support.sap.com)
- Transition to SAP Cloud ALM for Implementation (support.sap.com)
- Transition to SAP Cloud ALM for Operations (support.sap.com)
- Integration of Deployment Tools, SAP Cloud ALM (help.sap.com)
- SAP maintenance strategy for SAP Business Suite 7 (support.sap.com)
