Für SAP Identity Management gibt es keine neue Version mehr

Organisationen, die SAP Identity Management einsetzen, stehen vor einer ungewöhnlichen Entscheidung. Wenn Unternehmenssoftware in die Jahre kommt, plant man normalerweise ein Upgrade. Diese Option gibt es hier nicht. SAP Identity Management 8.0 ist das letzte Release mit neuen Funktionen, SAP hat das Ende der Wartung angekündigt, und der unterstützte Weg führt in eine andere Architektur. Ihr Programm muss deshalb als Migration von Identitätsdiensten und Governance-Kontrollen behandelt werden und nicht als technischer Versionswechsel.

Das nächste maßgebliche Datum für die Planung ist der 31. Dezember 2027. SAP beschreibt außerdem Optionen für eine erweiterte Wartung bis 2030. Diese zusätzliche Zeit sollte jedoch genutzt werden, um das Migrationsrisiko zu senken, und nicht, um die Bestandsaufnahme aufzuschieben. Der genaue vertragliche Umfang, der Preis und die Voraussetzungen der erweiterten Wartung müssen für Ihre SAP-Landschaft bestätigt werden. Die erweiterte Wartung schafft keine neue Produktgeneration von SAP IdM und macht die Wahl eines Zielmodells nicht überflüssig.

Dieser Leitfaden erklärt, was diese Unterscheidung in der Praxis bedeutet. Er zeigt Programmverantwortlichen, Verantwortlichen für die IAM-Architektur, Sicherheitsverantwortlichen und Anwendungsverantwortlichen konkret, wie sie SAP IdM inventarisieren, eine Zielarchitektur auswählen, in kontrollierten Wellen migrieren und die Nachweise sichern, die Prüfende erwarten.

Die Kurzantwort für die Geschäftsleitung: Beginnen Sie nicht damit, SAP IdM Aufgabe für Aufgabe in einem neuen Werkzeug nachzubauen. Ermitteln Sie zuerst die fachlichen Ergebnisse und Kontrollen, die erhalten bleiben müssen. Entscheiden Sie, welche Funktionen in SAP Cloud Identity Services, eine Identity-Governance-Plattform für Unternehmen, Microsoft Entra oder ein anderes führendes System gehören. Migrieren Sie dann einen vollständigen Identitätsablauf nach dem anderen und belegen Sie jeweils Abgleich und Rollback.

Wichtige Termine und Entscheidungen

Die von SAP veröffentlichten Hinweise geben die Richtung klar vor. Im Februar 2024 erklärte SAP, dass die Wartung für SAP Identity Management 2027 endet und Optionen für eine erweiterte Wartung bis 2030 verfügbar sind. SAP stellte außerdem SAP Cloud Identity Services als zentralen Baustein seiner Cloud-Identitätsstrategie dar und beschrieb die Integration mit Identitätssystemen von Partnern. Spätere Hinweise von SAP und Microsoft dokumentierten eine gemeinsame Initiative, Kunden dabei zu unterstützen, SAP-IdM-Szenarien auf Microsoft Entra und SAP Cloud Identity Services zu überführen.

Den genauen Wartungsstatus für Ihren Vertrag finden Sie in SAP Note 3268799 im Portal SAP for Me; bestätigen Sie ihn mit Ihrem SAP-Account-Team. Öffentliche Artikel sind nützliche Planungsgrundlagen, maßgeblich für vertragliche Supportleistungen sind jedoch die nur nach Anmeldung zugängliche Note und Ihr Vertrag.

Warum „keine neue Version“ die Arbeit verändert

Ein Upgrade lässt die grundlegende Aufgabe des Produkts unverändert. Datenmodelle können sich ändern und Konnektoren müssen unter Umständen getestet werden, doch die aktualisierte Plattform übernimmt im Wesentlichen weiterhin dieselben Aufgaben. Bei einer Ablösung ist das anders, weil sich diese Aufgaben auf mehrere Dienste verteilen können.

Eine typische SAP-IdM-Landschaft umfasst unter Umständen den Datenimport aus Quellen, Identitätskorrelation, Lebenszyklusregeln, Rollenzuweisung, Genehmigungs-Workflows, SAP-Provisionierung, Nicht-SAP-Provisionierung, passwortbezogene Prozesse, Abgleich, Reporting und individuelle Orchestrierung. Durch jahrelange lokale Erweiterungen kann die Plattform zugleich ein Identitätssystem und ein Katalog undokumentierter Geschäftsentscheidungen werden.

Ein direkter Nachbau Objekt für Objekt würde diese historischen Entscheidungen ins Zielsystem übertragen, bevor jemand gefragt hat, ob sie noch sinnvoll sind. Zudem kann er ein neues Produkt zwingen, jede Funktion des alten nachzuahmen, selbst wenn eine Fähigkeit inzwischen in einen besser geeigneten führenden Dienst gehört.

Die richtige Migrationseinheit ist deshalb ein gesteuertes Identitätsergebnis. Beispiele dafür sind:

• neu eingestellte Mitarbeitende erhalten die Standard-Zugriffsrechte für eine Gesellschaft und eine Abteilung;
• ein Wechsel der Führungskraft entzieht geerbte Befugnisse und weist den neuen Genehmigungsweg zu;
• die Zugriffsrechte externer Mitarbeitender enden zum vereinbarten Datum;
• eine privilegierte SAP-Rolle erfordert eine verantwortliche Person, eine Risikoprüfung und eine zeitlich befristete Genehmigung;
• eine austretende Person verliert den Zugriff in jedem angebundenen Zielsystem, und das Ergebnis wird abgeglichen;
• eine für die Überprüfung zuständige Person sieht, warum ein Zugriff besteht, und dokumentiert eine belastbare Entscheidung.

Jedes Ergebnis berührt Daten, Richtlinien, Workflow, Provisionierung und Nachweise. Wer das gesamte Ergebnis migriert, erhält etwas, das sich testen und abnehmen lässt. Werden einzelne technische Aufgaben isoliert migriert, entsteht Aktivität, ohne dass nachgewiesen ist, dass die geschäftliche Kontrolle noch funktioniert.

Das aktuelle Verhalten aus Konfiguration und Protokollen ermitteln

Erstellen Sie vor der Auswahl einer Plattform eine auf Belegen gestützte Übersicht der aktuellen Landschaft. Workshops allein reichen nicht aus. Menschen erinnern sich an die wichtigen Prozesse, aber selten an jeden geplanten Job, jede Ausnahme, jedes Skript, jede Rollenhierarchie oder jede nachgelagerte Abhängigkeit.

Nutzen Sie Konfigurationsexporte, Job-Zeitpläne, Protokolle, Konnektordefinitionen, Rollendaten, Abgleichsergebnisse und Serviceunterlagen. Gleichen Sie die technische Bestandsaufnahme mit Interviews aus den Bereichen HR, Anwendungsverantwortung, Sicherheit, Audit und Betrieb ab. Wo Dokumentation und Produktion voneinander abweichen, halten Sie das Verhalten in der Produktion und die verantwortliche Person fest, die über das künftige Verhalten entscheidet.

Erfassen Sie mindestens Folgendes:

Diese Bestandsaufnahme hat zwei Ergebnisse. Das erste ist eine Ausgangsbasis für den Umfang: was vorhanden ist, wer dafür verantwortlich ist und wie kritisch es ist. Das zweite ist eine Entscheidung zum weiteren Umgang für jedes Element: beibehalten, neu gestalten, ersetzen, zusammenführen oder stilllegen. Ein Objekt ohne verantwortliche Person und ohne nachgewiesene Nutzung sollte nicht automatisch in den Migrationsumfang fallen.

Die Datenbereinigung gehört in diese Phase. Die Migrationshinweise von Microsoft empfehlen ausdrücklich, veraltete Integrationen, Zugriffsrechte und Rollen vor der Migration zu entfernen. Schlechte Daten schneller zu verschieben, verbessert die Governance nicht. Damit wird die neue Plattform nur für alte Unklarheiten verantwortlich.

Das Ziel-Betriebsmodell vor dem Zielprodukt wählen

Die Zielarchitektur sollte festlegen, welches System welche Entscheidung trifft, welches sie ausführt und wo die Nachweise gespeichert werden. Die Produktauswahl ist Teil dieses Designs, aber nicht das Design selbst.

Bei Cloud-Identitäten stellt SAP in seiner aktuellen Ausrichtung SAP Cloud Identity Services in den Mittelpunkt. Identity Provisioning unterstützt Lebenszyklusoperationen für Benutzer und Gruppen über Quell- und Zielsysteme hinweg, während Identity Directory und die SCIM-Schnittstellen standardisierte Wege zur Verwaltung von Identitätsdaten bieten. Das von Microsoft veröffentlichte Migrationsszenario kombiniert SAP Cloud Identity Services mit Funktionen von Microsoft Entra. Dieses Muster kann passen, wenn Entra bereits die Grundlage der Organisation für Identitäten, Zugriff und Governance bildet.

Es ist nicht das einzig mögliche Unternehmensmodell. Eine selbst gehostete Plattform für Identity Governance kann erforderlich sein, wenn die Organisation direkte Kontrolle über die Infrastruktur, eine breite Anbindung von Nicht-SAP-Systemen, komplexe Identitätskorrelation, portable Konfiguration oder eine Governance-Ebene über mehrere Identitätsanbieter hinweg benötigt. Die Architektur muss sich nach Anforderungen richten, die Sie überprüfen können, statt nach einem Schlagwort wie „Cloud first“ oder „eins zu eins“.

Bewerten Sie Designvarianten anhand ausdrücklich festgelegter Zuständigkeiten:

Ein Design ist unvollständig, wenn zwei Systeme unabhängig voneinander dieselbe Berechtigung ändern können und es keine Vorrangregel gibt. Es ist ebenfalls unvollständig, wenn ein Workflow „genehmigt“ erfasst, aber niemand nachweisen kann, dass die Zielanwendung die Änderung umgesetzt hat.

Eine Migrationsfabrik in fünf kontrollierten Phasen aufbauen

Eine erfolgreiche Migration von SAP Identity Management ist wiederholbar. Mit der ersten Welle entsteht die Methode; spätere Wellen nutzen dieselben Prüfpunkte, dieselben Nachweise und dasselbe Verantwortungsmodell.

1. Erfassen und klassifizieren

Vervollständigen Sie die Bestandsaufnahme, ordnen Sie jedem Element eine verantwortliche Person zu und gliedern Sie die Landschaft in Migrationsdomänen. Eine Domäne kann eine Identitätsgruppe, eine Anwendungsfamilie oder ein vollständiger Lebenszyklusablauf sein. Bewerten Sie jede Domäne nach geschäftlicher Kritikalität, Datenqualität, Anpassungsgrad, Auswirkung auf Kontrollen, Integrationskomplexität und verfügbarer Testabdeckung.

Wählen Sie ein Pilotprojekt mit genug Substanz, um die Methode zu testen, aber machen Sie nicht den kritischsten und am stärksten angepassten SAP-Prozess zu Ihrem ersten Versuch. Für ein gutes Pilotprojekt brauchen Sie eine kooperationsbereite verantwortliche Person auf Anwendungsseite, repräsentative Identitätsdaten, messbare Provisionierungsergebnisse und einen realistischen Genehmigungsweg.

2. Die Zielkontrollen festlegen

Beschreiben Sie das künftige Verhalten in fachlicher Sprache, bevor Sie es konfigurieren. Legen Sie für einen Eintritt den Auslöser, die Mindestdaten, den Standardzugriff, Ausnahmen, die Genehmigungsverantwortung, die erwartete Bearbeitungszeit und die Nachweise fest. Legen Sie für einen Austritt das führende Endsignal, die Reihenfolge der Deaktivierung, beibehaltene Konten, den Ablauf bei sofortiger Beendigung und den Schwellenwert für den Abgleich fest.

Übersetzen Sie diese Aussagen in Abnahmetests. So verhindern Sie, dass das Projekt einen Erfolg meldet, weil ein Konnektor HTTP 200 zurückgegeben hat, während eine kritische Rolle in der Anwendung weiterhin zugewiesen war.

3. Das Pilotprojekt aufbauen und validieren

Erstellen Sie die Zielintegration in einer Staging-Umgebung mit einem Datenschutzniveau wie in der Produktion. Testen Sie normale Abläufe und Fehlerpfade: fehlende Führungskraft, doppelte Identität, verzögerte Quelle, abgelehnte Genehmigung, Timeout im Zielsystem, teilweise Provisionierung und Rollback.

Führen Sie vor und nach jedem Szenario einen Abgleich durch. Das Nachweispaket sollte das auslösende Ereignis, die Richtlinienentscheidung, die menschliche Entscheidung (soweit erforderlich), die angeforderte technische Änderung, das Ergebnis im Zielsystem und den abgeglichenen Zustand zeigen. Sicherheits- und Anwendungsverantwortliche sollten das Ergebnis gemeinsam abnehmen.

4. Den Parallelbetrieb kontrolliert führen

Eine gestufte Migration bedeutet in der Regel, dass SAP IdM und die Zieldienste parallel betrieben werden. Der Parallelbetrieb ist nur sicher, wenn die Schreibbefugnis eindeutig geregelt ist. Dokumentieren Sie für jede Anwendung und jede Berechtigungsklasse, welche Plattform anlegen, ändern und löschen darf. Deaktivieren Sie doppelte Zeitpläne und verhindern Sie, dass zwei Plattformen konkurrierend unterschiedliche Sollzustände durchsetzen.

Nutzen Sie im Beobachtungszeitraum Vergleichsberichte. Abweichungen müssen klassifiziert werden: erwartete Designänderung, zeitliche Verzögerung der Daten, Konfigurationsfehler, Problem der Quelldatenqualität oder Fehler im Zielsystem. Verstecken Sie ungeklärte Abweichungen nicht hinter einer prozentualen Toleranz.

5. In Wellen migrieren und bewusst stilllegen

Führen Sie nachfolgende Domänen durch dieselben Eingangs- und Ausgangsprüfpunkte. Das Programmgremium sollte ergebnisorientierte Kennzahlen sehen: abgeglichene Identitäten, abgenommene Kontrollen, geklärte Ausnahmen, geprobter Rollback und vollständige Nachweise.

Die Stilllegung ist ein eigener Arbeitsstrang. Stoppen Sie eingehende Datenflüsse und geplante Jobs in einer kontrollierten Reihenfolge, archivieren Sie Konfiguration und Audit-Aufzeichnungen gemäß der Aufbewahrungsrichtlinie, widerrufen Sie Servicekonten, entfernen Sie Netzwerkpfade, schließen Sie betriebliche Warteschlangen und weisen Sie die Verantwortung für verbleibende historische Nachweise zu. Ein Server, der lediglich ausgeschaltet wird, ist keine abgeschlossene Stilllegung.

Die Kontrollen, die am ehesten verloren gehen

Migrationsteams konzentrieren sich naturgemäß auf die Provisionierung, weil sie sichtbar und technisch testbar ist. Die Governance kann dagegen unbemerkt schwächer werden, wenn das Programm nicht auch den Grund für eine Änderung testet.

Achten Sie besonders auf diese Bereiche:

• Direkte Zuweisungen: Zugriffsrechte außerhalb des Rollenmodells können legitim sein, einem Notfallzugriff dienen oder eine angesammelte Altlast darstellen. Klassifizieren Sie sie, bevor Sie sie übernehmen.
• Rollenverantwortung: Eine importierte Rolle ohne verantwortliche Person kann keinen verlässlichen Anfrage- oder Überprüfungsprozess tragen.
• Genehmigungskontext: Einen Genehmigungsschritt nachzubilden reicht nicht aus, wenn die genehmigende Person die betroffene Person, den geschäftlichen Zweck, das Risiko, die Dauer und kollidierende Zugriffsrechte nicht mehr sieht.
• Funktionstrennung: Übernehmen Sie die Regel, den Geltungsbereich, die Befugnis für Ausnahmen, die kompensierende Kontrolle und den Nachweis der Entscheidung.
• Verhalten bei Wechseln: Abteilungs- und Führungskraftwechsel decken oft verborgene Abhängigkeiten auf, die Eintrittstests übersehen.
• Nicht-menschliche Identitäten: Servicekonten benötigen verantwortliche Personen, einen Zweck, Regeln für den Umgang mit Zugangsdaten und Ablaufregeln, auch wenn sie keinen HR-Ereignissen folgen.
• Ausführungsnachweise: Unterscheiden Sie zwischen beantragt, genehmigt, gesendet, angewendet, verifiziert, fehlgeschlagen und unbekannt. Das sind unterschiedliche Zustände.
• Historische Aufzeichnungen: Vereinbaren Sie, was nach der Stilllegung von SAP IdM durchsuchbar bleiben muss und wie die Integrität dieser Aufzeichnungen geschützt wird.

Eine praktische Abnahmeregel: Für jede risikoreiche Zugriffsänderung sollte eine unabhängige prüfende Person beantworten können, wer sie beantragt hat, welche Richtlinie ausgewertet wurde, wer sie genehmigt hat, was im Zielsystem tatsächlich geändert wurde, ob dieser Zustand abgeglichen wurde und wann die Änderung erneut überprüft wird.

Was ein belastbarer Plan enthält

Ein Programm kann umsetzungsbereit sein, bevor jedes Produktdetail feststeht. Ohne Verantwortlichkeiten, Nachweise und Entscheidungstermine ist es das nicht.

Nutzen Sie diese Mindest-Checkliste:

• Eine verantwortliche Person auf Leitungsebene akzeptiert, dass dies ein Ablösungsprogramm ist und kein Upgrade von SAP IdM.
• Der Plan rechnet vom 31. Dezember 2027 rückwärts und reserviert Zeit für Stabilisierung und Stilllegung.
• Die erweiterte Wartung wird als separat bestätigte Rückfalloption behandelt.
• Jede Quelle, jedes Zielsystem, jeder Workflow, jedes Rollenset, jeder individuelle Job und jeder Audit-Bericht hat eine verantwortliche Person und eine Entscheidung zum weiteren Umgang.
• Die aktuelle Datenqualität wird gemessen, bevor die Konfiguration des Zielsystems beginnt.
• Das Ziel-Betriebsmodell weist die Befugnisse für Lebenszyklus, Governance, Provisionierung, Authentifizierung, Abgleich und Nachweise zu.
• Das Pilotprojekt deckt einen vollständigen Identitätsablauf und realistische Fehlerfälle ab.
• Regeln für den Parallelbetrieb verhindern doppelte Schreibquellen.
• Die Abschlusskriterien jeder Welle verlangen einen abgeglichenen Zustand im Zielsystem und abgenommene Kontrollnachweise.
• Der Rollback wird für Änderungen getestet, die Zugriffe oder Geschäftsabläufe wesentlich unterbrechen können.
• Historische Nachweise, Aufbewahrung, Entfernung von Servicekonten und Abschaltung der Infrastruktur sind Teil der Stilllegung.
• Beschaffung, Sicherheitsprüfung und vertragliche Entscheidungen werden früh genug eingeplant, damit sie nicht zum kritischen Pfad werden.

Sind mehrere dieser Antworten noch offen, ist die nächste sinnvolle Investition die Bestandsaufnahme und das Zieldesign. Wer zuerst Lizenzen kauft, beantwortet diese Fragen nicht.

Wie easyIGA in die Entscheidung passt

Für Organisationen, die ein selbst gehostetes Governance-Modell in Betracht ziehen, bietet easyIGA eine fachliche Ebene über der Identity-Governance-Plattform midPoint. midPoint ist open source. easyIGA ist darauf ausgelegt, Zugriffsanfragen, Genehmigungen, Überprüfungen und Nachweise für die Fachbereiche verständlich zu machen, während Richtlinien und Provisionierung in midPoint bleiben. easyIGA wird standardmäßig selbst gehostet, auf Ihrer eigenen Infrastruktur und in Ihrem eigenen Rechtsraum. Für Organisationen ohne geeignete Infrastruktur ist auf Anfrage eine in der EU gehostete Bereitstellung verfügbar, die unser Team betreibt.

Damit ist easyIGA relevant, wenn die Ablösung von SAP IdM sowohl SAP- als auch Nicht-SAP-Systeme steuern, die eigene Kontrolle über Identitätsdaten und Konfiguration erhalten und menschliche Entscheidungen mit technischen Ergebnissen verbinden muss. Die in diesem Leitfaden beschriebene Bestandsaufnahme entfällt dadurch nicht. Keine Plattform kann sicher ableiten, welche individuellen Verhaltensweisen von SAP IdM erforderlich sind, welche veraltet sind und welche undokumentierte Kontrollen abbilden.

Die erste Zusammenarbeit sollte deshalb eine Bestandsaufnahme des Ist-Zustands, ein Modell der Zielzuständigkeiten, priorisierte Migrationswellen und Abnahmekriterien für das Pilotprojekt liefern. Diese Ergebnisse bleiben nützlich, auch wenn die endgültige Architektur mehrere Produkte kombiniert.

Kontaktieren Sie unser Team, wenn Sie eine technische Überprüfung einer SAP-IdM-Landschaft oder einen Workshop zur Definition der ersten Migrationswelle wünschen. Bringen Sie die tatsächliche Konnektorliste, den Job-Zeitplan, den Rollenkatalog und die Kontrollnachweise mit. Eine sinnvolle Bewertung beginnt mit dem, was die Plattform tatsächlich tut.

Den Produktumfang vor der Plattformwahl bestätigen

Testen Sie für eine Ablösung von SAP IdM die erforderlichen SAP- und Nicht-SAP-Operationen mit Ihren tatsächlichen Anwendungsversionen. Die Übersicht zu den Nachweisen in easyIGA erläutert erfasste Genehmigungen, außerhalb von easyIGA vergebene Zugriffsrechte und fehlende Historie. Bewahren Sie fehlgeschlagene Änderungen im Migrationsprotokoll auf, damit offene Punkte sichtbar bleiben. Die Erfahrung unseres Teams aus mindestens 14 midPoint-Einführungen fließt in die Planung und Umsetzung dieser Arbeit ein.

Weiter mit der Umsetzung

Nutzen Sie die Checkliste zur SAP-IdM-Migration, um Verantwortliche, Nachweise und Erfolgskriterien festzuhalten. Für die Auswahl des Zielsystems lesen Sie den IGA-Leitfaden.

Quellen und Hinweise zur Prüfung

Angaben zum Produktumfang und redaktionelle Formulierungen wurden am 24. September 2026 aktualisiert. Die unten genannten Daten beziehen sich weiterhin auf die ursprüngliche Prüfung der Quellen.

Die Tatsachenaussagen in diesem Artikel wurden am 11. September 2026 anhand der folgenden Primärquellen geprüft:

1. SAP, „Preparing for SAP Identity Management’s End-of-Maintenance in 2027“, https://community.sap.com/t5/technology-blog-posts-by-sap/preparing-for-sap-identity-management-s-end-of-maintenance-in-2027/ba-p/13596101
2. SAP, „Update on the SAP Identity Management migration to Microsoft Entra“, https://community.sap.com/t5/technology-blog-posts-by-sap/update-on-the-sap-identity-management-migration-to-microsoft-entra/ba-p/13742820
3. SAP, „Advantages of Proactive SAP IDM Migration“, https://community.sap.com/t5/technology-blog-posts-by-sap/advantages-of-proactive-sap-idm-migration/ba-p/14042339
4. SAP Note 3268799, Wartungsstrategie für SAP Identity Management (SAP-Anmeldung erforderlich), https://me.sap.com/notes/3268799
5. SAP Identity Management 8.0 Upgrade Guide, https://help.sap.com/doc/c48ff06e7e76450480ef93e5357381d5/8.0/en-US/IDM_UpgradeGuide.pdf
6. Microsoft Learn, „Migrate identity management scenarios from SAP IDM to Microsoft Entra“, https://learn.microsoft.com/en-us/entra/id-governance/scenarios/migrate-from-sap-idm
7. Microsoft Cloud Adoption Framework, „Identity and access management for SAP platform“, https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/sap/eslz-identity-and-access-management
8. SAP Help, „Identity Provisioning API“, https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/identity-provisioning-api
9. SAP Help, „Onboarding and Provisioning“, https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/onboarding-and-provisioning
10. SAP Help, „User and Group Creation in Identity Directory“, https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/user-and-group-creation-in-identity-directory
11. Bild: imgix auf Unsplash, https://unsplash.com/photos/server-racks-in-data-center-klWUhr-wPJ8; Lizenz: https://unsplash.com/license

Wartungs- und Lizenzbedingungen können je nach Vertrag variieren. Klären Sie die maßgebliche SAP Note und die kaufmännischen Konditionen mit SAP, bevor Sie sie als verbindliche Programmannahme verwenden.