Everyone in the SAP world knows the 2027 deadline for ECC. Far fewer teams have internalized that the same date retires the tool they would use to manage the migration: mainstream maintenance for SAP Solution Manager 7.2 ends on December 31, 2027, aligned with Business Suite 7 — and unlike the ERP deadline, this one applies to you *even if your S/4HANA conversion is already done*.
That matters because SolMan is not one product. In most landscapes it is quietly load-bearing for half a dozen operational processes at once. The end of maintenance is less like retiring an application and more like retiring a utility.
What actually dies with Solution Manager
Run the inventory before you form an opinion about the successor. In a typical established landscape, SolMan is carrying some mix of:
| Capability | What it does in SolMan | How much it hurts to lose |
|---|---|---|
| EarlyWatch Alert (EWA) | Weekly automated health reports per system | High — it's often the only proactive check that exists |
| System monitoring | Metrics, thresholds, alerting across the landscape | High — going dark here is how 2 AM outages happen |
| ChaRM | Change Request Management: approvals, transport control, cutover discipline | Very high if used — it *is* the change process |
| ITSM | Incident/service desk, often integrated with ChaRM | High where used — ticket history has audit value |
| Test Suite | Test plans, test packages, sign-off evidence | Medium — but auditors care about the evidence trail |
| Focused Build | Requirements-to-deploy project delivery | High mid-project, zero otherwise |
| Interface & business process monitoring | Watches IDocs, qRFC, critical business flows | Medium to high, landscape-dependent |
| Custom code analysis (CCLM/usage data) | Feeds S/4HANA custom-code cleanup decisions | Medium — and needed *before* conversion, not after |
Two observations from doing this inventory with real customers. First, nobody uses all of it — the average is three or four capabilities used seriously. Second, almost everybody is surprised by at least one thing on the list they *are* depending on, usually EWA delivery or an interface monitor someone configured in 2019.
The successor options, honestly
SAP Cloud ALM — the default answer
Cloud ALM is SAP's designated successor and the right starting assumption for most landscapes: it covers implementation projects and tasks, deployment management, real-time monitoring and alerting, and health analysis that replaces the EWA habit. It is cloud-native, SAP-operated, and — the part that removes most procurement friction — included in most SAP support agreements at no additional license cost.
We maintain a full breakdown of what it covers and where it falls short in our SAP Cloud ALM guide, so the short version here: monitoring and implementation are genuinely good and improving quarterly; ITSM is not there and is not trying to be; and heavily customized ChaRM processes will not survive the move unchanged. Cloud ALM rewards teams willing to adopt its standard processes and punishes attempts to rebuild SolMan inside it.
SAP Focused Run — the big-landscape option
Focused Run is on-premise, separately licensed, and built for scale: hundreds of systems, service providers running other people's landscapes, and regulated environments that cannot ship operational telemetry to a cloud service. If that description isn't obviously you, it probably isn't you — the license cost is real and Cloud ALM's trajectory keeps eating into the middle of the market.
Third-party tools — legitimate for two slices
For ITSM, the honest answer is that many organizations already moved their service desk to ServiceNow, Jira Service Management, or similar years ago, and SolMan's retirement just formalizes it. For monitoring, dedicated tools can outdo Cloud ALM on depth — but be careful about assembling a replacement out of three products when one included product covers 80% of the need. Every extra tool is an integration you now own.
Why the timing is a trap
Here is the sequencing problem we keep seeing. The typical plan says: *finish the S/4HANA program first (2026–2027), then deal with Solution Manager*. That plan has the dependency backwards.
Your S/4HANA program runs on SolMan capabilities: ChaRM controls its transports, the test suite holds its sign-off evidence, custom-code analysis feeds its cleanup scope, monitoring covers its cutover weekends. If SolMan's replacement happens *after* the program, you spend the highest-risk months of the decade on a dying platform — and then have to migrate change-control history and re-baseline monitoring immediately after go-live, when the team is exhausted and the appetite for platform work is zero.
The workable sequence is the opposite: stand up Cloud ALM early, in parallel, and move capabilities incrementally — monitoring and EWA first (lowest coupling, immediate value), project/deployment management next, ChaRM-equivalent change control last, once you trust the new pipeline. Run both in parallel during the transition; the license cost of doing so is typically zero, which removes the usual argument against parallel running.
Working backwards from December 2027: a comfortable migration is 6–12 months of elapsed time depending on ChaRM complexity. Starting in 2026 is comfortable. Starting mid-2027 is not, and you will be doing it at the same time as everyone else who waited, competing for the same scarce consultants.
A decision framework in four questions
- Do you use ChaRM in anger — customized workflows, retrofit, cutover orchestration? If yes, this is your critical path; prototype the Cloud ALM deployment-management equivalent now and find the gaps while there's time to close them. If no, your migration just got dramatically simpler.
- Is your service desk already outside SolMan? If yes, ITSM is a non-issue. If SolMan *is* your service desk, decide the ITSM destination first — it constrains everything else, and ticket history export is the long-lead item.
- Are you over ~50 productive systems, a service provider, or telemetry-restricted? If yes, evaluate Focused Run seriously. If no, don't pay for scale you don't have.
- What is silently consuming SolMan today? Run the inventory from the table above against reality — check what EWA reports are actually delivered, which monitors actually alert, which interface monitoring actually runs. The gap between configured and used is usually large, and everything unused is migration scope you get to delete.
What good looks like by end of 2026
- Cloud ALM tenant live, connected to every productive system, monitoring and health analysis running in parallel with SolMan
- EWA habit replaced — someone reads the Cloud ALM health findings the way they (hopefully) read EWAs
- ITSM destination decided, ticket history export tested
- ChaRM successor prototyped on a real change, gaps documented, closure plan owned
- SolMan decommission date on the calendar, with the audit-evidence retention question answered in writing
Monitoring continuity is the piece with no forgiveness for gaps — an unmonitored quarter is an incident lottery. It is also, not coincidentally, the piece where an external team adds the most leverage: our SAP monitoring and support service runs exactly this transition — standing up Cloud ALM monitoring alongside SolMan, tuning the alerting until it's trustworthy, and covering the landscape 24/7 while your team focuses on the migration itself. If you want the whole SolMan exit planned and executed as a project, that's Basis consulting territory, and we've done it before.
Related reading
- SAP Cloud ALM: Your Solution Manager Replacement Guide — the destination platform in detail
- What Is SAP Cloud ALM? — the two-minute version
- What Is SAP Basis? — where ALM tooling sits in the operational picture