Solution Manager läuft aus: Warum der Umstieg auf SAP Cloud ALM kein Großprojekt ist
Die Mainstream-Wartung für den SAP Solution Manager 7.2 endet Ende 2027. Der Wechsel zu SAP Cloud ALM ist deutlich kleiner als sein Ruf: Tenant in Minuten, für berechtigte Kunden ohne zusätzliche Lizenzkosten, Operations produktiv in Wochen.

Bad Soden am Taunus, 02.09.2026 (PresseBox) - Die Mainstream-Wartung für den SAP® Solution Manager 7.2 endet am 31. Dezember 2027. Viele SAP-Organisationen verschieben den Umstieg auf SAP Cloud ALM trotzdem, weil sie ein Großprojekt erwarten. Der tatsächliche Aufwand liegt darunter: Der Tenant ist in Minuten provisioniert, berechtigte Kunden zahlen keine zusätzlichen Lizenzkosten, und der Operations-Teil ist mit rund zwei Personentagen eingerichtet. Wer jetzt startet, entscheidet in Ruhe, welche Solution-Manager-Funktionen er überhaupt noch braucht.

Die Uhr läuft, aber anders als gedacht

Die Mainstream-Wartung für SAP Solution Manager 7.2 endet am 31. Dezember 2027. SAP empfiehlt allen Kunden, den Übergang zu SAP Cloud ALM vor diesem Datum abzuschließen. So weit ist die Lage bekannt.

Verbreitet ist allerdings ein Merksatz, der nicht trägt: Wir haben bis 2030 Zeit. Die Extended Maintenance bis Ende 2030 ist an die Extended Maintenance für SAP Business Suite 7 gekoppelt und steht damit nicht jedem Kunden offen. Unternehmen, die keine Extended Maintenance für SAP Business Suite 7 beziehen, wechseln nach 2027 für nicht abgedeckte SolMan-Funktionen in die Customer-Specific Maintenance.

Die Frist hängt damit am jeweiligen ECC-Status des Unternehmens, nicht an einer allgemeinen Roadmap-Angabe. Für CIO und IT-Leitung ist das eine Governance-Frage, keine Basis-Frage. Sie sollte beantwortet sein, bevor der Betrieb sie beantwortet bekommt.

Ein Nebeneffekt wird dabei selten mitgedacht. Bei vielen Mittelständlern ist der Solution Manager das letzte System mit AS-Java-Stack. Die Teams sind froh, diese Komponente loszuwerden, weil das Know-how dafür ohnehin fehlt.

Die drei Irrtümer, die den Start verzögern

Der eigentliche Grund für das Zögern liegt nicht in der Technik. Es sind drei Annahmen, die sich in Projekten regelmäßig als falsch erweisen.

Erstens die Kosten. SAP Cloud ALM steht berechtigten SAP-Kunden ohne zusätzliche Lizenzkosten zur Verfügung. Die Berechtigung lässt sich in SAP for Me in wenigen Klicks prüfen. Ein erheblicher Teil der Kunden weiß das nicht und kalkuliert im Kopf mit einem Budget, das gar nicht anfällt.

Zweitens die Speichergrenze. SAP hat die Base Memory im Rahmen der Fair-Use-Regelung auf 24 GB angehoben. In der Praxis wird dieser Rahmen kaum ausgereizt. Ein Kunde mit rund 18 angebundenen Landschaften und breitem Cloud-Service-Portfolio bewegt sich dabei bei etwa 6 GB HANA-Memory, ohne am Housekeeping gedreht zu haben. Das ist ein Viertel der Fair-Use-Grenze.

Drittens der Aufwand. Der Tenant ist in Minuten provisioniert, das Anbinden einzelner Systeme dauert Stunden. Eine Agenten-Ausrollung wie beim Solution Manager entfällt vollständig. Der bestehende Betrieb läuft parallel weiter, SAP Cloud ALM greift nicht in laufende Prozesse ein.

Wie niedrig die Hürde tatsächlich liegt, zeigt ein wiederkehrendes Muster: Es gibt Kunden, die den Tenant provisioniert und ein erstes Sandbox-System angebunden haben, dann aber stehen blieben, weil sie massiven Wissensaufbau befürchteten. Die Entscheidung fällt deshalb meist auf Teamleitungsebene, nicht im Investitionsausschuss.

Was SAP Cloud ALM kann, was der Solution Manager nie konnte

Wer den Wechsel nur als Pflichtübung betrachtet, übersieht den größeren Teil.

SAP Cloud ALM überwacht Cloud-Services und On-Premise-Systeme in einer Oberfläche, einschließlich Zertifikaten und API-Keys, etwa für den SAP Cloud Connector und die Integration Suite. Diese Cloud-Seite deckte der Solution Manager nicht ab, und genau dort wachsen die Landschaften.

Abgelaufene API-Keys eines Subaccounts sind ein klassischer stiller Ausfall. Nichts stürzt ab, nichts alarmiert, die Schnittstelle liefert einfach nicht mehr. Auffällig wird das, wenn die Fachabteilung anruft. SAP Cloud ALM warnt konfigurierbar vor, beispielsweise 90 Tage vor Ablauf, mit einer kritischen Erinnerung 30 Tage davor.

Die Alarmierung geht dorthin, wo gearbeitet wird: in den Teams-Kanal, nach Jira oder ServiceNow, statt in ein Postfach, das ohnehin überläuft. Das ist kein Komfortthema. Es gab Kunden, die genau wegen dieser Funktion auf uns zugekommen sind, weil abgelaufene Keys ihnen im Betrieb regelmäßig die Beine gebrochen haben.

Der zweite Bereich ist das zentrale Transportmanagement für On-Premise- und Cloud-Entwicklung, mit Fiori-Oberfläche und ohne manuelle Export- und Import-Schritte. Der Einstieg erfolgt in der Praxis fast immer über Operations, der Implementation-Bereich bleibt liegen. Das liegt meist am Wording der Dokumentation, nicht an der Sache: Die Techniker haben dort weniger Prozessarbeit, als sie annehmen.

Zukünftig soll Cloud ALM auch das Monitoring von SAP AI Agents übernehmen. Es bleibt also spannend, wohin sich SAP Cloud ALM entwickeln wird.  

Compliance: vom Jahresritual zum laufenden Status

SAP Cloud ALM prüft Systeme automatisiert gegen SAP Security Recommendations und Security Baselines und schreibt den Compliance-Status laufend fort, statt ihn einmal jährlich vor dem Audit zu erheben. Eigene Unternehmensrichtlinien lassen sich zunehmend über Custom Checks abbilden.

Der Unterschied ist praktischer Natur. Statt eines Kraftakts vor dem Audit lassen sich Nachweise für die Systeme im Prüfungssample gezielt ausleiten. Ein typischer Findings-Fall erledigt sich damit fast von selbst: Die Systemänderbarkeit wurde für einen berechtigten Change geöffnet und danach nicht wieder geschlossen. SAP Cloud ALM kann darauf alarmieren, bevor der Prüfer es findet.

Hinzu kommt eine Verschiebung im Prüfungskatalog. Wirtschaftsprüfer nehmen zunehmend das Identity- und Access-Management der SAP-Cloud-Dienste auf. Eine zentrale Sicht darauf gab es bisher kaum. Auch Transportprozesse werden nachvollziehbar: wer wann welches Artefakt mit welcher Begründung und mit welchem Testnachweis deployed hat.

In Gesprächen kommt Compliance meist erst spät auf den Tisch. Sobald es dort liegt, stößt es bei fast allen auf Interesse. Für die SAP-Basis bedeutet das Entlastung, für Compliance-Verantwortliche einen Status, den sie jederzeit abrufen können statt einmal im Jahr.

„Die meisten Unternehmen unterschätzen nicht die Technik, sondern überschätzen den Aufwand. Wir erleben regelmäßig, dass ein Team die ersten belastbaren Monitoring-Ergebnisse schon innerhalb weniger Stunden sieht und sich fragt, warum es damit nicht längst gestartet ist. Der Solution Manager läuft bei vielen ohnehin nur noch mit, weil SAP ihn vorausgesetzt hat, nicht weil sein Potenzial genutzt wird. Wer den Wechsel jetzt schrittweise angeht, hat die Wahl. Wer 2029 anfängt, hat sie nicht mehr.“
Carsten Linz, SAP-Technologieexperte und CEO der entplexit GmbH

Der Weg dorthin, ohne Big Bang

Der Umstieg auf SAP Cloud ALM läuft schrittweise: Readiness Check im Solution Manager, dann Entwicklungs- und Testsysteme, dann Produktion. Beide Werkzeuge lassen sich parallel betreiben und im Monitoring miteinander vergleichen.

Der Readiness Check zeigt in kurzer Zeit, welche Szenarien in den letzten zwölf Monaten tatsächlich genutzt wurden und wo funktionale Lücken bleiben. Diese Lücken sind meist kleiner als befürchtet. Ein Beispiel sind Wartungszertifikate: Der manuelle Download für eine komplette Systemlandschaft liegt im Minutenbereich und fällt bei den meisten Kunden zweimal im Jahr an. Das trägt keine Entscheidung für die Extended Maintenance.

Für den Projektrahmen liefert die SAP Transition Methodology Pläne, Accelerators und Deliverables je Phase. Zur Größenordnung: Der Operations-Teil ist technisch innerhalb von rund zwei Personentagen eingerichtet. Für die Implementation, also zentrales Transportmanagement, hängt der Aufwand stark vom Ausgangspunkt ab. Wird im Cloud ALM neu begonnen, sind es rund drei Personentage für die technische Einrichtung. Läuft bereits zentrales Transportmanagement im Solution Manager und muss migriert werden, ist der Aufwand zu individuell für eine pauschale Angabe und wird projektspezifisch bewertet.

Zwei Fallstricke lohnen die Vorarbeit. Die Identitätsverwaltung sollte von Anfang an am produktiven IAS-Tenant hängen, sonst entstehen parallele Tenants ohne Synchronisation. Und einzelne Metriken, etwa das Filesystem-Monitoring, erzeugen ohne Vorkonfiguration vor allem Fehlalarme. Beides ist nachträglich korrigierbar, aber unnötig teuer.

Wichtig für die Risikobewertung: SAP Cloud ALM ist eine Orchestrierungsschicht, kein Single Point of Failure. Fällt der Service aus, bleiben Transporte über das TMS manuell möglich, anders als bei ChaRM oder Focus Build. Der Umstieg ist damit steuerbar und jederzeit reversibel. Bislang gibt es keinen Kunden, der den Einstieg bereut hätte.

Wie viel davon das eigene Team übernimmt, entscheidet der Kunde. Das reicht von einer Enablement-Session, in der die Mannschaft selbst deployt und dabei lernt, bis zum vollständigen Aufbau von Tenant, Systemanbindung und Cloud-Services durch entplexit.

Fazit

Die Frist läuft, aber der Aufwand ist kalkulierbar. Wer wartet, verliert keine Technik, sondern Handlungsspielraum. Der teuerste Fehler beim Wechsel auf SAP Cloud ALM ist das Warten.

Wer früh beginnt, entscheidet selbst, welche Solution-Manager-Funktionen er überhaupt noch braucht, statt sie unter Zeitdruck nachzubauen. Wenn das bei Ihnen ansteht, sprechen wir gerne darüber.