SAP IDM zu midPoint Migration
SAP Identity Management erreicht das Ende des Supports am December 31, 2027. SAP bietet keinen direkten On-Premise-Nachfolger für komplexe, Multi-System-Identitätsumgebungen. We Know Identity migriert SAP IDM-Bereitstellungen zu midPoint — unter Beibehaltung Ihrer SAP-Integrationen und Beseitigung der Abhängigkeit von proprietären Plattformen.
Die Situation: SAP IDM Ende des Supports
SAP hat bestätigt, dass SAP Identity Management (SAP IDM) 8.0 das Ende des Mainstream-Supports am December 31, 2027. Es gibt eine einmalige Option für erweiterten Support bis zum 31. Dezember 2030, jedoch zu erheblichen Zusatzkosten und ohne weitere Funktionsentwicklung.
Was noch wichtiger ist, SAP wird keinen direkten On-Premise-Nachfolger liefern für komplexe Identitätsverwaltung in gemischten SAP- und Nicht-SAP-Umgebungen. SAPs eigenes Cloud-Portfolio — Identity Authentication Service (IAS), Identity Provisioning Service (IPS), Identity Access Governance (IAG) und Identity Directory Service (IDS) — deckt SAP-Cloud-Anwendungsauthentifizierung und grundlegende Bereitstellung ab. Es ersetzt SAP IDM nicht als zentrale Identitätsverwaltungsplattform für Organisationen mit Active Directory, LDAP, HR-Systemen, benutzerdefinierten Anwendungen und komplexer Lebenszyklusautomation.
Kritische Risiken beim Verbleib auf SAP IDM
- Keine Sicherheits-Patches nach 2027 — oder 2030, wenn erweiterte Unterstützung erworben wird
- Keine Unterstützung für moderne SAP-Cloud-Produkte — IAS-, BTP- und S/4HANA-Cloud-Integrationen erfordern aktualisierte Connector-Muster, die SAP IDM nicht bieten kann
- SAP-proprietäre Architektur — SAP IDMs UME-basierter Store, Workflow-Engine und Connector-Framework sind einzigartig für das Produkt und können nicht schrittweise migriert werden
- Mangel an Fachleuten — SAP IDM-Administratoren und -Entwickler sind selten geworden, da die Plattform veraltet ist
- Wachsendes Compliance-Risiko — Zugriffsprüfungen, SoD-Durchsetzung und Lebenszyklusautomation werden schwerer nachzuvollziehen, je älter die Plattform wird
- Kosten für erweiterte Unterstützung — die Erweiterung bis 2030 erfordert eine einmalige Gebühr, die die Kosten der Migration selbst übersteigen kann
Warum jetzt migrieren und nicht 2026 oder 2027
Branchenleitfäden schätzen konsistent 24 bis 36 Monate für eine strukturierte SAP IDM-Migration in einer komplexen Umgebung. Das bedeutet, dass Organisationen, die nicht 2025 oder Anfang 2026 mit der Planung begonnen haben, bereits Risiken eines verdichteten, unter hohem Druck stehenden Cutover-Fensters haben.
Organisationen, die jetzt migrieren – anstatt zu warten – erhalten:
- Raum für ordnungsgemäße Architektur: eine stufenweise Migration ermöglicht einen Connector-für-Connector-Übergang ohne Serviceunterbrechung
- Zeit für ordnungsgemäße Zuordnung von IDM-Workflows: Das aufgabenbasierte Workflow-Modell von SAP IDM unterscheidet sich von midPoints richtlinienbasierter Bereitstellung; eine Neugestaltung erfordert strukturierte Analysetime
- Stabilität des SAP R/3-Konnektors: RFC-basierte SAP-Konnektoren erfordern sorgfältiges Testen in Ihrer gesamten ABAP-Landschaft vor dem vollständigen Cutover
- Kostenkontrolle: überstürzte Migrationen sind immer teurer; schrittweise Bereitstellung verteilt Kosten und reduziert Risiken
- Team-Schulung: Ihr Operations-Team benötigt Zeit, um midPoints Architektur zu erlernen, bevor es diese verwaltet
SAPs Alternativen – und ihre Einschränkungen
SAP empfiehlt sein Cloud Identity-Portfolio und hat sich mit Microsoft zusammengetan, um Microsoft Entra ID als Migrationspfad zu positionieren. Beide haben echte Anwendungsfälle, aber keines ist ein vollständiger SAP IDM-Ersatz für Organisationen, die komplexe On-Premise-Identitätsumgebungen verwalten.
SAP Cloud Identity (IAS / IPS / IAG)
- Konzipiert für SAP-Cloud-Anwendungsidentität, nicht für Multi-System-Verwaltung
- IPS handhabt grundlegende Bereitstellung für SAP-Ziele; komplexe Lebenszykluslogik erfordert benutzerdefinierte Scripting
- Keine integrierte Zugriffszertifizierung oder SoD außerhalb des engen Umfangs von SAP IAG
- Kann nicht für Active Directory, LDAP oder Nicht-SAP-Geschäftsanwendungen bereitstellen
- Sperrt die Identitätsverwaltung in SAPs Cloud-Plattform-Geschäftsmodell
Microsoft Entra ID (von SAP empfohlener Pfad)
- Stark für Microsoft-Ökosystem und SSO; schwächer für komplexe IGA-Verwaltungs-Workflows
- SAP-Bereitstellung über Entra beruht auf SAP IPS als Middleware-Ebene — Komplexität bleibt bestehen
- Pro-Benutzer-Lizenzierung im Unternehmensmaßstab führt zu erheblichen laufenden Kosten
- Verwaltungsfunktionen (Zugriffsprüfungen, SoD, Rollen-Engineering) erfordern zusätzliche Microsoft IGA-Lizenzierung
- Ersetzt SAP-Herstellerabhängigkeit durch Microsoft-Herstellerabhängigkeit
Warum midPoint für SAP IDM-Migration
midPoint wurde speziell für die Art von Problem entwickelt, das SAP IDM gelöst hat: komplexe Identitätslebenszyklusverwaltung über heterogene Unternehmensysteme. Es deckt SAP- und Nicht-SAP-Ziele auf einer einzigen Plattform ab, ohne Pro-Benutzer-Lizenzierung und ohne Abhängigkeit vom Geschäftsplan eines einzelnen Herstellers.
1. Native SAP-Konnektoren
Evolveum bietet einen produktionsreifen SAP R/3-Konnektor mit RFC/BAPI-Aufrufen für Benutzerkonten- und Rollen-Bereitstellung. SuccessFactors wird über SCIM- und OData-basierte Konnektoren unterstützt. Beide integrieren sich direkt in midPoints Provisioning-Engine.
2. Vollständige IGA-Verwaltungssuite
midPoint umfasst Rollen-Engineering, SoD-Konflikterkennung, Zugriffszertifizierungskampagnen, Genehmigungsworkflows und audit-bereite Berichterstattung – die Verwaltungsfunktionen, auf die SAP IDM-Kunden angewiesen waren und die SAPs Cloud-Portfolio nicht vollständig ersetzt.
3. Keine Pro-Benutzer-Lizenzierung
midPoint wird pro Bereitstellung lizenziert, nicht pro verwaltete Identität. Für Organisationen, die Tausende oder Hunderttausende von Konten verwalten, ist dies ein grundlegender Kostenvorteil gegenüber sowohl Microsoft Entra IGA als auch SaaS-basierten IGA-Plattformen.
4. HR-gesteuerte Lebenszyklusautomation
SAP HCM und SuccessFactors sind häufige Joiner/Mover/Leaver-Ereignisquellen in SAP IDM-Umgebungen. midPoints HR-Integrations-Framework handhabt diese Quellen nativ, wobei feingranulare Lebenszyklusregeln SAP IDMs aufgabenbasierte Provisioning-Logik ersetzen.
5. On-Premise- und Hybrid-Bereitstellung
midPoint wird On-Premise, auf Kubernetes oder in einem Hybrid-Modell bereitgestellt. Für Organisationen mit Datenspeicherungsanforderungen, regulatorischen Einschränkungen oder On-Premise-SAP-Infrastruktur ist diese Flexibilität wichtig – und ist nicht in SAPs Cloud IGA-Portfolio verfügbar.
6. Herstellerunabhängigkeit
Open-Source-Kern mit kommerziellem Support von Evolveum. Ihre Identitätsplattform unterliegt nicht den Preisscheidungen von SAP oder Microsoft. Konfiguration, Konnektoren und Verwaltungsregeln gehören Ihrer Organisation – nicht in einer proprietären Plattform eingesperrt.
Was WKI bei einer SAP IDM-zu-midPoint-Migration handhabt
SAP IDM-Migrationen beinhalten mehr als die Installation von midPoint. Die Migration erfordert Analyse bestehender IDM-Rollen, Task-Flows, Connector-Konfigurationen und Organisationsdatenstrukturen, gefolgt von sorgfältiger Neuimplementierung in midPoints Architektur.
SAP-Konnektor-Engineering
Konfiguration und Testen von SAP R/3 (RFC/BAPI)-, SAP SuccessFactors (SCIM/OData)- und SAP HCM-Konnektoren in midPoint. Attributzuordnung, Schema-Erweiterung, Kontokorrelation und Rechteverwaltung, abgestimmt auf Ihre SAP-Landschaft.
Workflow- und Richtlinien-Neugestaltung
SAP IDM verwendet aufgabenbasierte Provisioning-Workflows. midPoint verwendet richtlinienbasierte Bereitstellung mit rollengesteuerten Zuordnungen. Wir übersetzen Ihre bestehenden IDM-Task-Flows in midPoints Rollenmodell, Lebenszyklusstatus und Genehmigungsworkflows – wobei wir Logik bewahren, ohne Legacy-Designmuster zu kopieren.
Identitätsdaten-Migration
Extraktion von Identitätsdaten aus SAP IDMs UME-basiertem Identitätsspeicher, Korrelation mit maßgeblichen HR- und Verzeichnisquellen und Import in midPoint mit ordnungsgemäßer Kontoverknüpfung, Schattenkontozuordnung und Beziehungsdatenintegrität.
Nicht-SAP-System-Konnektoren
Die meisten SAP IDM-Umgebungen verwalten auch Active Directory, LDAP-Verzeichnisse, Datenbanken und benutzerdefinierte Anwendungen. Wir erstellen oder konfigurieren midPoint-Konnektoren für Ihre vollständige Systemlandschaft – nicht nur für SAP-Ziele.
Verwaltungs-Setup
Rollenmodell-Design, SoD-Regelimplementierung, Zugriffszertifizierungskonfiguration und Audit-Berichterstattung, abgestimmt auf Ihre Compliance-Anforderungen – Wiederaufbau der Verwaltungsebene, auf die Ihre Organisation angewiesen ist, aber in einer wartbaren modernen Plattform.
Parallelablauf und Cutover
Stufenweiser Cutover mit parallelem Betrieb von SAP IDM und midPoint während der Transition. Abstimmungsprüfungen, Datenvalidierung und Genehmigungstore, bevor jedes System aus dem IDM-Umfang abgelöst wird.
Migrationsansatz
Wir strukturieren SAP IDM-Migrationen in vier Phasen, um Risiken zu reduzieren, Governance-Kontinuität zu bewahren und Ihrem Team Zeit zu geben, operative Sicherheit aufzubauen, bevor SAP IDM abgelöst wird.
Phase 1 – Erkennung und Architektur-Design
4–6 Wochen
Inventar aller SAP IDM-Konnektoren, Provisioning-Tasks und Datenflüsse. Dokumentation des bestehenden Rollenmodells, der Workflow-Logik und der Organisationsregeln. Architektur-Design für midPoint, das Ihre aktuelle IDM-Logik auf midPoints natives Provisioning- und Governance-Modell abbildet. Konnektor-Strategie: Welche Systeme verwenden bestehende midPoint-Konnektoren im Vergleich zu benutzerdefinierten Entwicklungen.
Phase 2 – midPoint-Aufbau und SAP-Konnektor-Konfiguration
8–14 Wochen
midPoint-Bereitstellung in Ihrer Zielinfrastruktur. SAP R/3-Konnektor-Konfiguration: Benutzer-Provisioning, Rollenzuweisung und Kontolebenszykl. SuccessFactors- oder SAP HCM-Konnektor-Konfiguration für HR-gesteuerte Joiner/Mover/Leaver-Automatisierung. Erste Rollenmodell-Implementierung basierend auf dem Architektur-Design. Kern-Lebenszyklusregeln: Onboarding, Offboarding, Positronenwechsel und Zugriffsanfragen.
Phase 3 – Nicht-SAP-Konnektoren, Verwaltung und Tests
6–10 Wochen
Erstellen und Testen von Konnektoren für Active Directory, LDAP, Datenbanken und alle benutzerdefinierten Systeme, die derzeit von SAP IDM verwaltet werden. Verwaltungsebene-Konfiguration: SoD-Regeln, Zugriffszertifizierung, Genehmigungsworkflows. Funktionale und Integrationstests über die gesamte verbundene Systemlandschaft. Abstimmungstests: Datenausrichtung zwischen midPoint-Schattenkonten und Zielsystemen.
Phase 4 – Parallelablauf, Cutover und Handover
4–8 Wochen
Paralleler Betrieb von SAP IDM und midPoint auf systemweiser Basis. Validierung, dass Provisioning-Ereignisse in midPoint identische Ergebnisse wie das Legacy IDM-System erzeugen. Cutover jedes Systembereichs, wenn die Abstimmung Genauigkeit bestätigt. SAP IDM-Abschaltungsplanung. Operationen-Handover: Runbooks, Konfigurationsdokumentation, Überwachungs-Setup und Team-Schulung.
Häufig gestellte Fragen
+ Wie lange dauert eine typische SAP IDM-zu-midPoint-Migration?
Die meisten komplexen SAP IDM-Umgebungen erfordern 6 bis 18 Monate für eine vollständige Migration, abhängig von der Anzahl der verbundenen Systeme, der Komplexität bestehender Provisioning-Logik und des Umfangs der Governance-Anforderungen. Branchenleitfäden von Evolveum und SAP-Partnern empfehlen konsistent, 24 bis 36 Monate für Planung und Ausführung in großen Unternehmen einzuplanen. Kleinere Bereitstellungen mit weniger Konnektoren können schneller voranschreiten.
+ Kann midPoint unsere SAP R/3- und SuccessFactors-Integration handhaben?
Ja. Evolveum pflegt einen produktionsreifen SAP R/3-Konnektor, der RFC/BAPI-Aufrufe verwendet, um Benutzer und Rollen in SAP R/3, ECC und S/4HANA bereitzustellen. SuccessFactors-Integration ist über SCIM- und OData-basierte Konnektoren verfügbar. Beide Konnektoren handhaben Kontoerstellung, Attributverwaltung, Rollenzuweisung und Kontolebenszyklusvorgänge. WKI hat praktische Erfahrung in der Konfiguration dieser Konnektoren in komplexen SAP-Landschaften.
+ Warum nicht stattdessen zu SAP Cloud Identity Services migrieren?
SAP Cloud Identity Services (IAS, IPS, IAG) deckt Authentifizierung und grundlegende Bereitstellung für SAP-Cloud-Anwendungen ab. Es kann SAP IDMs Funktion als zentrale Identitätsverwaltungsplattform für gemischte SAP- und Nicht-SAP-Umgebungen nicht ersetzen. Organisationen mit Active Directory, LDAP, benutzerdefinierten Anwendungen und komplexer Joiner/Mover/Leaver-Automatisierung werden SAPs Cloud-Portfolio für ihren vollständigen Identitätsverwaltungsumfang unzureichend befinden. midPoint wurde speziell für dieses Multi-System-Governance-Problem entwickelt.
+ Warum nicht stattdessen zu Microsoft Entra migrieren?
Microsoft Entra ist SAPs empfohlener Partner für IDM-Migration und eine starke Plattform für Microsoft-zentrische Umgebungen. Allerdings beruht der SAP-Bereitstellungspfad über Entra immer noch auf SAP IPS als Middleware-Ebene, daher wird die Komplexität nicht beseitigt. Entra IGA-Lizenzierung fügt Pro-Benutzer-Kosten in großem Maßstab hinzu. Organisationen, die eine herstellerneutrale, On-Premise-fähige, vollständig offene Governance-Plattform suchen – ohne SAP- oder Microsoft-Lock-in – finden midPoint eine geeignetere architektonische Lösung. Die richtige Antwort hängt von Ihrer bestehenden Umgebung und strategischen Richtung ab.
+ Was passiert mit unseren bestehenden SAP IDM-Rollen und Provisioning-Tasks?
SAP IDM verwendet ein aufgabenbasiertes Provisioning-Modell mit MX-Skripten und UME-basierter Identitätsspeicherung, das spezifisch für die Plattform ist. Diese können nicht direkt in midPoint importiert werden. Die Migration beinhaltet die Analyse Ihrer bestehenden Tasks und Workflows, das Extrahieren der zugrunde liegenden Geschäftslogik und die Neuimplementierung in midPoints richtlinienbasiertem Provisioning-Modell. Dies ist Designarbeit, keine bloße Datenmigration. WKI führt eine strukturierte Erkennungsphase durch, um Ihre aktuelle IDM-Logik zu dokumentieren, bevor die Implementierung beginnt.
+ Können wir in Phasen statt vollständig migrieren?
Ja, und dies ist der Ansatz, den WKI empfiehlt. Die Phasenweise Migration bewegt einen Systembereich nach dem anderen von SAP IDM zu midPoint, wobei beide Plattformen während jedes Übergangsfensters parallel laufen. Dies reduziert das Cutover-Risiko, ermöglicht die Validierung jedes Konnektors vor dem Fortschreiten und hält die Identitätsoperationen während des gesamten Projekts stabil. Der vollständige Cutover von SAP IDM ist die letzte Phase, nicht der Ausgangspunkt.
+ Was ist mit der Option für erweiterte Unterstützung bis 2030?
SAP bietet erweiterte Unterstützung bis zum 31. Dezember 2030 für eine zusätzliche einmalige Gebühr. Dies kauft Zeit, ändert aber nicht die grundlegende Situation: SAP IDM erhält keine neuen Funktionen, moderne SAP-Cloud-Integrationen bleiben nicht unterstützt und die Plattform erfordert weiterhin seltene Spezialistenfähigkeiten. Erweiterte Unterstützung ist eine Risikomanagement-Option, keine strategische Lösung. Wenn Ihre Organisation 12 bis 18 zusätzliche Monate benötigt, um eine ordnungsgemäße Migration durchzuführen, kann dies angemessen sein – sollte aber als Migrations-Laufbahn geplant werden, nicht als permanente Strategie.
+ Was benötigt WKI von unserer Seite, um eine Migration zu starten?
Ein Discovery-Engagement beginnt mit Zugriff auf Ihre SAP IDM-Konfigurationsdokumentation, einen Systemlandschaftsüberblick und Interviews mit Ihren IAM- und SAP-Technikteams. Wir benötigen nicht sofort vollständigen Systemzugriff — die erste Phase ist hauptsächlich eine Dokumentations- und Architektur-Review. Wir bieten einen strukturierten Fragebogen vor dem ersten Engagement, damit Ihr Team sich effizient vorbereiten kann.
Starten Sie Ihre SAP IDM-Migrationsplanung
Eine strukturierte Bewertung wird Ihre aktuelle SAP IDM-Umgebung abbilden, die richtige midPoint-Architektur identifizieren und eine realistische Migrations-Roadmap mit Zeitplan und Kostenschätzungen erstellen.
Für Entscheidungsträger
SAP Identity Management erreicht das Wartungsende im Dezember 2027, ohne direkten On-Premise-Nachfolger für komplexe Multi-System-Umgebungen. Erweiterte Wartung bis 2030 kostet mehr als viele Migrationen. Organisationen, die jetzt beginnen, gewinnen den 24–36 Monate Vorlauf für einen ordnungsgemäßen phasenweisen Übergang — und vermeiden die komprimierte, risikoreiche Umstellung, die durch Warten entsteht. Wir migrieren SAP IDM-Deployments zu midPoint unter Beibehaltung Ihrer SAP-Integrationen, Eliminierung der Per-User-Lizenzkosten und Beseitigung der Abhängigkeit von einem einzelnen Anbieter.