SAP Solution Manager 7.2 end of maintenance: 2027 Is Closer Than You Think
SAP Solution Manager 7.2 reaches end of mainstream maintenance in December 2027. Extended maintenance is available through 2030 for customers who opt into SAP Business Suite 7 extended maintenance, which carries a support fee premium. No new feature development for Solution Manager in either period. For the thousands of enterprises that have built their application lifecycle management around Solution Manager over the past two decades, this is not a distant concern. It is a program that should already be in planning.
And yet the most common reaction is a version of the same mistake: treating this as a tool migration. Solution Manager out, Cloud ALM in, six months, done.
It is not that simple. SAP Cloud ALM is not a direct successor to Solution Manager. It is a different platform, built on different technology, with a different philosophy. Some Solution Manager capabilities have direct equivalents in Cloud ALM. Others do not exist in Cloud ALM at all. And several require a fundamental rethinking of how your organization manages change, tests software, and operates its SAP landscape.
That said, the market is moving. Cloud ALM adoption has been accelerating — SAP’s ALM leadership projected reaching 5,000 customers by end of 2023, up from 1,500 in late 2022, with the daily adoption rate expected to increase beyond the initial pace. This is not a speculative platform. It is the strategic direction, and the organizations that plan early will have their pick of implementation resources. The organizations that wait will compete for a shrinking pool.
This article covers what you need to assess, how to classify your migration effort, the decisions that matter most, and the mistakes that cost the most time when made late.
Start with What You Actually Use
The first step is not evaluating Cloud ALM. It is understanding what you have in Solution Manager today. Most organizations significantly underestimate this.
Solution Manager is not a single tool. It is a collection of capabilities that have accumulated over years of configuration, customization, and integration. A typical mid-to-large enterprise uses some combination of: solution documentation and business blueprinting, test management (manual and automated), Change Request Management (ChaRM), IT Service Management (incident, problem, service request), technical and business process monitoring, custom code management, landscape management, and a web of integrations connecting Solution Manager to Jira, ServiceNow, Azure DevOps, and dozens of managed SAP systems via RFC.
Organizations running SAP Focused Build add another layer: agile requirements management, work packages, and sprint planning, all configured within Solution Manager and tightly coupled with ChaRM transport control. This is its own migration dimension that is frequently overlooked in early planning.
Before you can plan a migration, you need a current-state inventory that captures every active capability, the number of objects or configurations behind it, its complexity, its integration points, and its business criticality. This is not a checkbox exercise. It is the foundation of every effort estimate, timeline, and budget that follows.
Four Migration Paths, Not One
Not everything in Solution Manager goes to Cloud ALM. This is the single most important thing to understand early. Each component in your inventory will follow one of four migration paths, determined by what Cloud ALM offers and what it does not.
Direct Migrate
These are capabilities where Cloud ALM has a functional equivalent and migration is relatively straightforward. Project management, requirements management, solution documentation, and basic operational monitoring fall into this category. Cloud ALM organizes its implementation capabilities around project and task management, test management, process design using SAP Best Practice content, and deployment and release management — with integrated analytics and traceability across all four. The effort is real but bounded: you are recreating configurations and content in a new platform, not redesigning processes.
Rebuild
These are capabilities where Cloud ALM has a corresponding feature but the data model, workflow, or approach is fundamentally different. This is the largest and most dangerous category. Test management is the most common example: SAP has introduced a selective data transfer tool for migrating test cases and Focused Build test steps, and Cloud ALM now supports spreadsheet-based import. But the transfer is not seamless: test case metadata, custom attributes, and execution history do not carry over cleanly, and every migrated case still needs validation against the new platform’s data model. Change Request Management is another: ChaRM workflows in Solution Manager are deeply customized in most organizations. Cloud ALM’s Deployment Management takes a more standardized approach. The redesign is not optional.
Third-Party Replace
Cloud ALM does not include IT Service Management. If you run incident management, problem management, or service request fulfillment through Solution Manager today, you need a dedicated ITSM platform. ServiceNow and Jira Service Management are the most common choices. This is a separate project with its own budget, timeline, and organizational impact.
Retire
Some Solution Manager capabilities are no longer needed in their current form. Custom code management, for example, is increasingly handled by SAP’s standard S/4HANA tooling (Custom Code Migration Worklist). Z-reports built inside Solution Manager should be evaluated individually: some can be retired, others need to be redeveloped outside the Solution Manager context. The key decision is whether each custom object still serves a business need, not whether it can be migrated.
Migration Path Summary
| Migration Path | Typical Capabilities | Effort Profile | Cloud ALM Role |
|---|---|---|---|
| Direct Migrate | Solution docs, requirements, monitoring, landscape mgmt | Low to moderate; bounded by object count | Direct equivalent exists |
| Rebuild | Test management, ChaRM, BPMon, analytics, integrations | High; process redesign required | Functional equivalent, different model |
| Third-Party Replace | Incident mgmt, service requests, problem mgmt | Moderate; separate platform selection | No ITSM in Cloud ALM |
| Retire | Custom code mgmt, Z-reports, legacy add-ons | Low; assessment and decommission | Handled by S/4HANA standard tooling |
Where the Effort Actually Lives
In our experience, three areas consistently account for 70% or more of total migration effort. If you plan for these correctly, the rest of the program is manageable.
1. Test Management
Manual test cases are the single largest effort driver in most migrations. The selective data transfer tool and spreadsheet import help, but they are not a one-click migration. Metadata, custom attributes, and execution history do not transfer cleanly. Every migrated case needs validation against Cloud ALM’s data model. Organizations with 500+ manual test cases should expect this cleanup and validation work to be a significant workstream.
If you also run automated test scripts through Solution Manager, those must be re-engineered for Cloud ALM’s integrated test automation framework. Tricentis Test Automation is SAP’s strategic partner for automated testing in Cloud ALM, directly integrated at the platform level and extensible to enterprise-grade regression suites. The migration path for automated scripts is clear, but the re-engineering work is real. Test scripts written for the Solution Manager test suite do not port to Tricentis without rework.
2. Change Request Management (ChaRM)
ChaRM is where Solution Manager’s depth is hardest to replace. Most enterprises have spent years configuring approval workflows, quality gates, and transport management rules that reflect their specific governance requirements. Cloud ALM’s Deployment Management is deliberately more standardized. The migration is not a technical lift-and-shift; it is a governance redesign.
Organizations that skip this work and try to replicate ChaRM logic in Cloud ALM will fail, because Cloud ALM does not support the same level of customization. The right approach is to treat the transition as an opportunity to simplify, but that simplification requires careful analysis of which governance controls are essential and which are organizational habit.
For organizations also running Focused Build, the complexity compounds. Focused Build’s three-level hierarchy — Requirements, Work Packages, and Work Items — is tightly coupled with ChaRM transport control. The transition to Cloud ALM means redesigning not just the change approval workflow but also the agile requirements and sprint planning structure that feeds into it. These two migrations must be planned together; treating them as independent workstreams creates governance gaps during the transition.
3. Third-Party Integrations
Solution Manager connects to managed systems via RFC. Cloud ALM uses REST APIs and SAP BTP. Every integration point needs to be re-architected: Jira, ServiceNow, Azure DevOps, and all 30 to 50 RFC connections to your managed SAP landscape. The effort scales with the number of integration points, not the number of integration objects. A single Jira connector with a complex bidirectional sync is more effort than ten simple RFC registrations.
The Parallel Run Reality
Most categories require a period where both Solution Manager and Cloud ALM run simultaneously. This is not optional for testing, change management, operations monitoring, service management, or integrations. You cannot switch off ChaRM on a Friday and turn on Cloud ALM Deployment Management on a Monday. There will be weeks or months where your teams operate in both systems.
This has real cost implications. Parallel run adds overhead to every affected workstream, typically 10 to 20% of the base effort for those components. It also has organizational implications: your teams need training on the new platform while still operating the old one, and your governance model needs to account for the transition period without creating gaps in change control.
Five Mistakes That Cost the Most When Made Late
1. Treating it as a technical migration
This is a program governance and process redesign initiative. The technical platform swap is the easy part. The hard part is redesigning how your organization manages change, tests software, and monitors operations. If your project plan does not include process workshops and organizational change management, it is incomplete.
2. Starting with Cloud ALM evaluation before completing the current-state inventory
You cannot build a credible migration plan until you know what you have. We have seen organizations spend months evaluating Cloud ALM features before realizing they have 1,500 manual test cases, 67 custom ABAP reports, and a ChaRM configuration that touches 8 downstream systems. The inventory comes first. Always.
3. Underestimating the ITSM gap
Cloud ALM does not do IT Service Management. If your organization runs incident management through Solution Manager, you need a separate ITSM platform. This is not a configuration change; it is a tool selection, procurement, and implementation project that runs in parallel with the Cloud ALM migration. Start it early.
4. Assuming Cloud ALM will replicate ChaRM
It will not. Cloud ALM’s Deployment Management is simpler and more standardized by design. Organizations with heavily customized ChaRM workflows need to accept that the migration will involve governance simplification, not feature replication.
5. Ignoring the integration re-architecture
RFC connections do not migrate. Every managed system registration and every third-party tool connector must be re-established through Cloud ALM APIs and SAP BTP. If you have 40+ integration points, this is a significant workstream that requires SAP BTP architecture expertise.
How to Sequence the Migration
Based on our experience, the most effective sequencing follows the risk-and-dependency logic of the migration paths themselves.
Phase 1: Direct Migrate (months 1 to 6)
Start with the capabilities that have direct Cloud ALM equivalents and the lowest redesign risk. Solution documentation, requirements management, and operational monitoring establish Cloud ALM as your working platform. This builds organizational familiarity before the harder phases.
Phase 2: Rebuild (months 4 to 14)
The Rebuild path is the heaviest workstream and should start overlapping with Phase 1 once the team has Cloud ALM proficiency. Within Rebuild, prioritize Change Management (ChaRM and Focused Build redesign) and Testing (test case migration and Tricentis integration) first, because these are the most complex and have the longest parallel run requirements.
Phase 3: Third-Party Replace (parallel workstream)
ITSM platform selection and deployment should run as an independent parallel workstream from month 1. It has no dependency on Cloud ALM and involves different stakeholders. Do not wait for the Cloud ALM migration to finish before starting this.
Phase 4: Retire and Decommission (months 12 to 16)
Custom code management objects and Z-reports are assessed and either retired or migrated to their new homes outside Solution Manager. This happens last because some objects may only become clearly disposable once Cloud ALM is operational.
How to Approach This Well
The organizations that navigate this transition successfully tend to share three characteristics.
They treat the migration as a program, not a project
An ALM migration touches every workstream that relies on Solution Manager — which, in most organizations, means every active SAP program and every ongoing operations process. It deserves its own governance structure: a dedicated program lead, a steering cadence, a RAID register, and scope management discipline. The organizations that assign this to someone’s desk as a side project alongside their day job are the ones that discover the real complexity in month eight, not month two.
They preserve institutional knowledge explicitly
Solution Manager contains years of accumulated decisions: why specific ChaRM workflows were designed a certain way, which business process monitoring rules reflect real operational pain, which integrations carry undocumented dependencies. That knowledge is at risk of being lost during the migration — not because the data disappears, but because nobody extracts the rationale behind the configuration before rebuilding it in a new platform.
The most effective approach is to treat knowledge capture as a formal workstream. Before decommissioning any Solution Manager capability, document not just what it does but why it was built that way. Who made the decision. What trade-off it reflected. What business process it was designed to protect. This context is invisible in the technical configuration but essential for anyone who needs to operate, maintain, or troubleshoot the system after the migration team has moved on.
Organizations that skip this step save a few weeks during the migration and spend the next two years rediscovering what the project already knew — one support ticket at a time, at $250 to $1,000 per investigation.
They invest in governance intelligence, not just governance process
An ALM migration is itself a complex program running alongside the S/4HANA transformation that is almost certainly in flight at the same time. It generates scope drift (requirements evolve as you learn what Cloud ALM can and cannot do), schedule risk (parallel runs take longer than planned), and decision backlogs (the ChaRM simplification alone can produce dozens of governance decisions that need steering committee attention).
The traditional response is to staff a PMO and build a status reporting cadence. That works, but it is expensive and slow. The intelligence/judgement distinction applies here as directly as it does in any ERP program: maintaining a RAID register, tracking scope drift, assembling a steering pack — this is intelligence work. Verifiable, repeatable, structured. Deciding which governance controls to simplify vs. preserve, how to phase the parallel run to minimize organizational burden, when to escalate a ChaRM redesign decision to the steering committee — that is judgement work.
The organizations that separate these two types of work, automating the intelligence layer and protecting time for the judgement work, deliver faster and cheaper than the ones that ask the same senior practitioners to do both.
When to Start
If you are reading this in 2026 and have not begun planning, you are not too late, but you are later than you should be. The market data is unambiguous: of SAP’s 35,000 original ECC customers, only about 28% were live on S/4HANA by end of 2023. Projections suggest only 57% will have completed their transformations by the time mainstream maintenance ends in December 2027. Full completion of the installed base is not expected until the mid-2030s.
This matters for your ALM migration because the same resource pool that delivers S/4HANA transformations also delivers Cloud ALM transitions. The resource peak for SAP transformations is projected for 2028–2029, with 75% more resources required than current levels and over 10,000 concurrent in-flight projects projected at peak. The organizations that start their ALM migration now will secure experienced practitioners. The organizations that start in 2027 will be competing for the same scarce resources alongside every other company that waited.
A typical mid-to-large enterprise should expect the full migration to take 12 to 18 months from assessment to Solution Manager decommission. That puts the latest responsible start date somewhere around mid-2026 for a December 2027 target.
The extended maintenance option (through 2030) provides a buffer, but it should be treated as a contingency, not a strategy. SAP has been clear that Cloud ALM is the strategic direction. No new features are coming to Solution Manager. The longer you wait, the less organizational capacity you have to manage this alongside the S/4HANA migration that is almost certainly running in parallel.
The conversation usually starts with a specific question about one part of the migration. It rarely stays there.
