Arbeitshilfe zur Migration · Zehn Prüfpunkte # Checkliste zur SAP-IdM-Migration. Bereitschaft nachweisen, dann umstellen. Eine Checkliste für die Praxis, gedacht für Programmverantwortliche, Verantwortliche für die IAM-Architektur sowie Anwendungsteams. Darin halten Sie fest, was bereit ist, wo noch Unsicherheit besteht und welche Nachweise den nächsten Schritt freigeben. Vom easyIGA-Team · Veröffentlicht am 24. August 2026 · Aktualisiert am 12. Oktober 2026 · 12 Minuten Lesezeit Supportfristen im Detail Die Mainstream-Wartung für SAP IdM endet am 31. Dezember 2027. SAP beschreibt Optionen für eine erweiterte Wartung bis 2030. Prüfen Sie Voraussetzungen, Umfang und kaufmännische Konditionen in SAP Note 3268799 und in Ihrem Vertrag. Eine Verlängerung verschafft Zeit für die Planung, ist aber kein neues Release von SAP IdM. Mehr dazu in der [Wartungsankündigung von SAP](https://community.sap.com/t5/technology-blog-posts-by-sap/preparing-for-sap-identity-management-s-end-of-maintenance-in-2027/ba-p/13596101). [Serverschränke als Symbol für Anwendungen und Infrastruktur bei einer Identitätsmigration] Symbolfoto von [imgix / Unsplash](https://unsplash.com/photos/server-racks-in-data-center-klWUhr-wPJ8), verwendet unter der [Unsplash License](https://unsplash.com/license). Die Aufnahme zeigt weder unser Büro noch eine Kundenumgebung. ## Zur Nutzung dieser Checkliste Diese Arbeitshilfe dient der Prüfung der Bereitschaft und verspricht nicht, dass eine Migration eine bestimmte Anzahl von Wochen dauert. Die zehn Prüfpunkte sind redaktionelle Empfehlungen zur Steuerung eines Ablösungsprogramms. Sie sind kein Zertifizierungsstandard, keine gesetzliche Vorgabe und kein Bericht über ein abgeschlossenes Kundenprojekt. Der Aufwand hängt von Ihrem Umfang, Ihren Quelldaten, Integrationen, betrieblichen Rahmenbedingungen und der Verfügbarkeit Ihres Teams ab. Halten Sie für jeden Prüfpunkt einen Status, eine verantwortliche Person, den Ablageort der Nachweise, ein Entscheidungsdatum und die nächste Maßnahme fest. Setzen Sie den Status nur dann auf „bereit“, wenn die Nachweise die Bedingung belegen. Den Status „nicht bereit“ wählen Sie, wenn eine erforderliche Kontrolle nicht erfüllt ist, und „noch nicht geprüft“, wenn die Antwort auf einer Annahme beruht. Ist eine Bedingung nicht anwendbar, halten Sie die Begründung und die verantwortliche Person fest, die das genehmigt hat, statt das Feld leer zu lassen. Gehen Sie die Einträge mit den Personen durch, die die betroffenen Dienste betreiben. Die Programmleitung kann die Entscheidung koordinieren, aber nicht anstelle der fachlich verantwortlichen Person das Berechtigungs-Mapping einer Anwendung genehmigen. Ebenso ist eine erfolgreiche Rückmeldung der Provisionierung ein nützlicher Nachweis, ersetzt aber nicht die Prüfung des daraus resultierenden Kontos und seiner Berechtigungen. Die übergeordneten Architekturentscheidungen und Migrationsphasen behandelt unser Leitfaden [„Für SAP Identity Management gibt es keine neue Version mehr“](https://easyiga.com/de/blog/sap-idm-ohne-nachfolgeversion). Die vorliegende Checkliste ergänzt ihn, wenn eine konkrete Go/No-Go-Besprechung ansteht. ## Scorecard zur Bereitschaft Zehn Prüfpunkte vor der Freigabe einer Migrationswelle | Prüfpunkt | Mitzubringende Nachweise | Entscheidungsverantwortung | 1. Support und Umfang | Vertragslage, einbezogene Systeme, Ausschlüsse | Sponsor und Plattformverantwortliche | 2. Bestandsaufnahme des Ist-Zustands | Quellen, Jobs, Konnektoren, Rollen, Abhängigkeiten | IAM-Leitung und Anwendungsverantwortliche | 3. Bereinigung von Identitäten und Zugriffsrechten | Korrelationstests und genehmigte Entscheidungen zum weiteren Umgang | Daten- und Rollenverantwortliche | 4. Zuständigkeiten im Zielbild | Kontrollmatrix und Entscheidungen zur führenden Datenquelle | Architektur und Sicherheit | 5. Nachweis der Integrationen | Beobachtete Ergebnisse für unterstützte Operationen im Zielsystem | Integrations- und Anwendungsverantwortliche | 6. Lebenszyklustests | Nachweise für Eintritt, Wechsel, Austritt und Ausnahmen | Prozessverantwortliche | 7. Parallelbetrieb | Geklärte Schreibzuständigkeit und abgeglichene Abweichungen | Betriebsleitung | 8. Umstellung und Wiederherstellung | Geprobtes Runbook, Schwellenwerte und Wiederherstellungstest | Freigabestelle für Änderungen | 9. Kontinuität der Nachweise | Abrufbare historische und neue Entscheidungsnachweise | Verantwortliche für Kontrollen und Aufzeichnungen | 10. Stilllegung | Deaktivierte Altpfade und abgenommene Serviceübergabe | Serviceverantwortliche Machen Sie aus dieser Tabelle keinen Prozentwert, der einen kritischen Mangel verdeckt. Neun erfüllte Prüfpunkte gleichen keinen Austrittsprozess aus, der privilegierte Zugriffsrechte aktiv lässt. Legen Sie für jede Welle zwingende Bedingungen fest und eskalieren Sie jede Ausnahme an die Person, die befugt ist, genau dieses Risiko zu akzeptieren. 01 ## Supportsituation und tatsächlichen Umfang bestätigen Beginnen Sie mit der eingesetzten SAP-IdM-Version, ihren Abhängigkeiten und den Supportvereinbarungen, die für Ihre Organisation gelten. Dokumentieren Sie die Supportlage mit Datum: die relevanten Informationen zur Produktverfügbarkeit, Ihre Vertragsauslegung und die verantwortliche Person, die beides bestätigt hat. Ein SAP-Supporthinweis ist unter Umständen nur mit einem autorisierten SAP-Konto zugänglich; eine öffentliche Zusammenfassung kann einen individuellen Vertrag nicht klären. Legen Sie dann fest, was das Programm ablöst. Berücksichtigen Sie Identitätsgruppen, SAP- und Nicht-SAP-Systeme, Lebenszyklusprozesse, Governance-Kontrollen und betriebliche Dienste. Halten Sie Ausschlüsse ausdrücklich fest. Ein Cloud-Authentifizierungsprojekt ersetzt nicht automatisch die On-Premises-Provisionierung, die lokale Rollenverwaltung oder das historische Reporting. Bereit, wenn: Sponsor und Plattformverantwortliche sich über Umfang, Supportannahmen und das interne Abschlussziel einig sind. Für jeden Ausschluss gibt es eine verantwortliche Person und eine fortlaufende Kontrolle. Pausieren, wenn: der Business Case davon ausgeht, dass der Support 2027 für jeden Kunden wegfällt, oder annimmt, dass die erweiterte Wartung automatisch jede Komponente bis 2030 abdeckt. 02 ## Verhalten und Konfiguration der Installation erfassen Erfassen Sie Identitätsspeicher, Repositories, geplante Jobs, Provisionierungsaufgaben, Skripte, Konnektoren, Rollendefinitionen, Genehmigungswege und Servicekonten. Ermitteln Sie das tatsächliche Betriebsverhalten aus Protokollen und Zielsystemen und vergleichen Sie es anschließend mit der Dokumentation. Achten Sie besonders auf selten laufende Jobs, etwa jährliche Kampagnen oder Zertifikatserneuerungen, weil sie in einem kurzen Beobachtungszeitraum unbemerkt bleiben können. Halten Sie für jede Integration den geschäftlichen Zweck, die führende Quelle, die Version des Zielsystems, die unterstützten Operationen, den Zeitplan, das Volumen, die verantwortliche Person für die Zugangsdaten, die Fehlerwarteschlange und den Supportkontakt fest. Erfassen Sie auch Abhängigkeiten außerhalb der Plattform: Genehmigungen per E-Mail, Excel-Listen, manuelle Tätigkeiten im Service Desk, Batch-Dateien und Jobs, die ein anderer Scheduler auslöst. Bereit, wenn: die Anwendungsverantwortlichen die Bestandsaufnahme bestätigen und für jede offene Abweichung eine namentlich benannte Person die Klärung übernimmt. Bewahren Sie sensible Konfigurationen an einem zugriffsgeschützten Ort auf. Pausieren, wenn: eine Integration nur deshalb als ungenutzt gilt, weil sich niemand an sie erinnert, oder wenn niemand die geschäftliche Wirkung eines Skripts erklären kann. 03 ## Identitätszuordnungen und Bereinigung der Zugriffsrechte klären Legen Sie fest, wie das Zielsystem eine Person mit vorhandenen Konten korreliert. Testen Sie stabile Kennungen, doppelte Datensätze, Namensänderungen, Wiedereinstellungen, mehrere Beschäftigungsverhältnisse und den Wechsel externer Mitarbeitender in eine Festanstellung. Eine E-Mail-Adresse kann sich ändern oder erneut vergeben werden; gehen Sie nicht ohne Prüfung der Quellregeln davon aus, dass sie ein sicherer dauerhafter Identitätsschlüssel ist. Weisen Sie jeder Rolle, jeder Berechtigung und jedem Workflow eine Entscheidung zum weiteren Umgang zu: beibehalten, neu gestalten, zusammenführen oder stilllegen. Lassen Sie zugriffsbezogene Entscheidungen von den fachlich verantwortlichen Personen genehmigen. Dass keine Nutzung beobachtet wurde, ist ein Anlass zur Prüfung, aber kein automatischer Beweis, dass eine Berechtigung gelöscht werden kann. Saisonale Aufgaben und Notfallzugriffe brauchen Kontext. Bereit, wenn: Korrelationstests keine ungeklärten Zuordnungen ergeben und Bereinigungsentscheidungen mit wiederherstellbaren Nachweisen genehmigt sind. Pausieren, wenn: mehrdeutige Identitäten dazu führen könnten, dass das Zielsystem doppelte Konten anlegt, Privilegien der falschen Person zuordnet oder gültige Zugriffsrechte entfernt. Behandeln Sie diese Ergebnisse als konkrete Fehler und nicht als hinnehmbares Hintergrundrauschen in einem Migrationsbericht. 04 ## Jede Zuständigkeit im Zielbild zuweisen Trennen Sie Authentifizierung, Governance, Provisionierung, Abgleich und Audit-Reporting. Entscheiden Sie, welcher Dienst welche Zuständigkeit übernimmt und welches System für jedes wesentliche Attribut führend ist. SAP Cloud Identity Services, Microsoft Entra, eine IGA-Plattform und anwendungsspezifische Administration können Teile einer Zielarchitektur sein. Dass es sie gibt, sagt aber noch nichts darüber, wie sie zusammenwirken. Dokumentieren Sie Anfragen, Genehmigungen, Rollenrichtlinien, Funktionstrennung, Ablauf von Zugriffsrechten, Überprüfungen und die Behandlung von Ausnahmen. Legen Sie für jede Kontrolle Eingabe, verantwortliche Person, ausführenden Dienst, Ergebnis im Zielsystem und aufzubewahrenden Nachweis fest. Benennen Sie Zuständigkeiten, die von SAP IdM zu einem anderen Team wechseln, denn eine Übergabe verändert das Betriebsmodell und nicht nur die Technik. Bereit, wenn: jedes erforderliche Ergebnis genau eine verantwortliche Person und einen eindeutigen Umsetzungsweg hat. Pausieren, wenn: zwei Dienste davon ausgehen, für dasselbe Attribut zuständig zu sein, oder eine Kontrolle wegfällt, weil jeder Anbieter erwartet, dass das jeweils andere Produkt sie bereitstellt. Vergleichen Sie Optionen anhand nachgewiesener Abdeckung und Betriebskosten statt anhand eines bevorzugten Produktnamens. 05 ## Integrationen an den tatsächlichen Zielsystemversionen prüfen Ein Konnektorname ist kein Abnahmetest. Prüfen Sie die Operationen, die Sie benötigen: erkennen, anlegen, aktualisieren, aktivieren, deaktivieren, entfernen, Berechtigungen zuweisen und abgleichen. Testen Sie die erforderlichen Kontotypen und Berechtigungsstrukturen. Ein Konnektor, der einen einfachen Benutzer provisioniert, verwaltet nicht unbedingt die privilegierten Rollen, verschachtelten Gruppen oder benutzerdefinierten Objekte in Ihrem Umfang. Testen Sie Ratenbegrenzungen, Timeouts, ungültige Eingaben, unzureichende Berechtigungen und nicht verfügbare Zielsysteme. Prüfen Sie, ob ein wiederholter Vorgang Arbeit doppelt ausführt oder sicher den beabsichtigten Zustand erreicht. Klären Sie, wie sich die Rotation von Zugangsdaten und der Ablauf von Zertifikaten auf die Verbindung auswirken und wer bei einem Ausfall der Integration eine verwertbare Warnung erhält. Bereit, wenn: die Nachweise für jede erforderliche Operation die Eingabe, die angeforderte Änderung, den tatsächlichen Zustand im Zielsystem und den Ausnahmeweg festhalten. Pausieren, wenn: Erfolg nur bedeutet, dass eine API eine Bestätigung zurückgegeben hat. Vereinbaren Sie für Systeme außerhalb der automatisierten Abdeckung ein manuelles Ausweichverfahren und testen Sie es, bevor Sie diese Systeme als abgedeckt werten. 06 ## Lebenszyklen vollständig testen Wählen Sie repräsentative Identitäten und durchlaufen Sie vollständige Abläufe für Eintritt, Wechsel und Austritt. Berücksichtigen Sie eine Einstellung mit späterem Startdatum, einen abgesagten Arbeitsbeginn, einen Wechsel der Führungskraft, das Vertragsende externer Mitarbeitender und eine Wiedereinstellung, sofern diese Fälle in Ihrem Unternehmen vorkommen. Beobachten Sie Datenübernahme aus der Quelle, Identitätskorrelation, Richtlinie, Genehmigung, Provisionierung und Abgleich im Zusammenhang. Weisen Sie bei einem Wechsel nach, dass veraltete Zugriffsrechte entfernt und neue gewährt werden. Berücksichtigen Sie bei einem Austritt aktive Anwendungssitzungen, lokale Konten, Schlüssel und Abhängigkeiten von Objekten, für die die Person verantwortlich ist. Die Deaktivierung eines zentralen Kontos beendet nicht zwingend jede von einer Anwendung ausgestellte Sitzung; [Microsoft dokumentiert diese Unterscheidung](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access). Legen Sie eine zielsystemspezifische Prüfung fest. Bereit, wenn: Prozessverantwortliche sowohl reguläre Szenarien als auch Fehlerszenarien abnehmen und das Ergebnis aus den Nachweisen rekonstruieren können. Pausieren, wenn: nur ein Demokonto mit minimalen Berechtigungen den Test bestanden hat. Nutzen Sie das [Offboarding-Playbook](https://easyiga.com/de/blog/zugriffsentzug-beim-austritt), um den Austrittstest über die Deaktivierung im Verzeichnis hinaus zu erweitern. 07 ## Parallelbetrieb und Abgleich steuern Legen Sie für jede Phase fest, welche Plattform welches Objekt und Attribut im Zielsystem schreiben darf. Setzen das alte und das neue System jeweils unterschiedliche Sollzustände durch, können sie gegenseitig ihre Änderungen rückgängig machen oder Zugriffsrechte immer wieder neu anlegen. Ein Konzept für den Parallelbetrieb braucht ausdrückliche Zuständigkeitsgrenzen und nicht nur das Versprechen, dass sich die Teams abstimmen. Starten Sie Beobachtung oder Simulation mit Berechtigungen und einer Konfiguration, die unbeabsichtigte Schreibvorgänge verhindern. Vergleichen Sie vorhergesagte Änderungen mit dem aktuellen Zustand im Zielsystem und lassen Sie die verantwortlichen Personen die Abweichungen prüfen. Simulation hat Grenzen und kann nicht jede nachgelagerte Auswirkung nachweisen. Führen Sie deshalb anschließend kontrollierte Schreibtests in einer geeigneten Umgebung durch. Prüfen Sie das tatsächliche Simulationsverhalten der gewählten Plattform in deren versionsspezifischer Dokumentation. Bereit, wenn: alle unerklärten Abweichungen bereinigt sind und der Wechsel der Schreibzuständigkeit je Zielsystem dokumentiert ist. Pausieren, wenn: ein umfangreicher Abweichungsbericht ohne Klassifizierung als erwartet abgetan wird. Halten Sie einen genehmigten Referenzstand fest und erläutern Sie, welche Änderungen beabsichtigte Bereinigung sind, welche auf zeitliche Effekte zurückgehen und welche auf einen Fehler hinweisen. 08 ## Umstellung und Wiederherstellung proben Erstellen Sie für jede Welle ein eigenes Runbook mit Voraussetzungen, Zugriffsbeschränkungen, geordneten Schritten, Validierungsprüfungen, Kommunikation und Entscheidungsbefugnis. Legen Sie vor dem Wartungsfenster messbare Bedingungen für Pause und Wiederherstellung fest. Beispiele sind fehlgeschlagene Entzüge von Zugriffsrechten in einer kritischen Anwendung, ungeklärte Identitätskollisionen oder der Ausfall eines erforderlichen Nachweis-Feeds. Die Wiederherstellung muss geschäftliche Änderungen berücksichtigen, die während des Übergangs anfallen. Das Wiederherstellen einer alten Datenbank kann veraltete Zugriffsrechte zurückbringen oder eine gültige neue Entscheidung löschen. Halten Sie fest, welche Konfigurationsänderungen umkehrbar sind, welche Aktionen in Zielsystemen sich nicht rückgängig machen lassen und welche ausgleichenden Schritte ab dem Punkt nötig sind, an dem ein einfacher Rollback nicht mehr sicher ist. Bereit, wenn: das Team das Runbook geprobt und die Wiederherstellungsmethode für die definierte Welle nachgewiesen hat. Pausieren, wenn: der Rollback nur aus „SAP IdM wieder einschalten“ besteht. Die Freigabestelle für Änderungen sollte wissen, wer die Welle stoppen kann, wie Nutzerinnen und Nutzer Unterstützung erhalten und welche Nachweise vorliegen müssen, bevor die nächste Welle beginnt. 09 ## Nachweise über beide Plattformen hinweg sichern Listen Sie die historischen Aufzeichnungen auf, die weiterhin benötigt werden: Zugriffsanfragen, Genehmigungen, Richtlinienversionen, Entscheidungen aus Überprüfungen, Provisionierungsergebnisse, Ausnahmen und wesentliche Vorfälle. Legen Sie Aufbewahrungs- und Zugriffsanforderungen mit den zuständigen Verantwortlichen für Aufzeichnungen, Datenschutz und Kontrollen fest. Exportieren Sie nicht alles unbegrenzt, nur weil Speicherplatz verfügbar ist. Testen Sie, ob eine autorisierte prüfende Person eine historische Entscheidung finden und interpretieren kann, nachdem SAP IdM nicht mehr läuft. Bewahren Sie die Kennungen und den erläuternden Kontext auf, die nötig sind, um den alten Eintrag mit der entsprechenden Identität, Anwendung und Berechtigung im Zielsystem zu verbinden. Ein unlesbares Archiv ist keine wirksame Übergabe von Nachweisen. Bereit, wenn: sich eine Stichprobe über den Übergang hinweg rekonstruieren lässt und neue Entscheidungen ab Beginn des Betriebs im Zielsystem erfasst werden. Pausieren, wenn: das Archiv von einem Konto abhängt, dessen Löschung geplant ist, oder der Zugriff auf Nachweise den Neustart eines nicht mehr unterstützten Produktivdienstes erfordert. Dokumentieren Sie bekannte Lücken und ihre genehmigte Behandlung, statt eine unvollständige Historie als lückenlose Abdeckung darzustellen. 10 ## Altpfade stilllegen und Service abnehmen Zur Stilllegung gehört mehr, als einen Server anzuhalten. Deaktivieren Sie veraltete Zeitpläne, Konnektor-Zugangsdaten, Netzwerkfreigaben, Servicekonten, Callbacks und manuelle Verfahren. Stellen Sie sicher, dass keine Quelle und kein Zielsystem noch von einem alten Job abhängt. Halten Sie Archive von aktiven Provisionierungspfaden getrennt, damit die Aufbewahrung von Nachweisen nicht versehentlich Kontoänderungen wieder auslöst. Übergeben Sie Betriebsverfahren, Monitoring, Sicherung und Wiederherstellung, Eskalationskontakte, Verantwortung für Zugangsdaten und bekannte Ausnahmen. Schulen Sie den Service Desk und die Anwendungsteams zu den neuen Fehlerbildern. Legen Sie fest, wer Konnektoren und Richtlinien pflegt, wenn das Projektteam nicht mehr da ist, und wie Änderungen vor der Freigabe getestet werden. Bereit, wenn: die serviceverantwortliche Person das System abnimmt und dafür Nachweise für einen stabilen Betrieb, zugeordnete Restrisiken und ein abgeschlossenes Protokoll zur Stilllegung des Altsystems vorliegen. Pausieren, wenn: ein verborgener Altjob die einzige Möglichkeit bleibt, einen geschäftskritischen Prozess abzuschließen. Beseitigen Sie diese Abhängigkeit oder dokumentieren Sie eine ausdrücklich genehmigte Übergangsregelung mit einer Endbedingung. ## Go/No-Go-Meeting zielführend leiten Bringen Sie die Scorecard, offene Mängel, abgeglichene Ergebnisse aus den Zielsystemen und ein kurzes Ausnahmeregister mit. Beginnen Sie mit Bedingungen, die zu unberechtigtem Zugriff, Serviceunterbrechungen oder dem Verlust von Nachweisen führen könnten. Prüfen Sie, ob jede zwingende Bedingung erfüllt ist; verbringen Sie das Meeting nicht damit, erledigte technische Aufgaben zu zählen. Halten Sie für jede Ausnahme die betroffene Personengruppe und die betroffenen Systeme, die möglichen Folgen, die ausgleichende Maßnahme, die verantwortliche Person, das Ablaufdatum und den Prüfplan fest. Die Person, die das Risiko akzeptiert, muss für diesen Service oder diese Kontrolle befugt sein. Ein Projektteam kann eine nicht erfüllte Sicherheitsbedingung nicht einfach dadurch in eine Risikoakzeptanz verwandeln, dass es die Statusfarbe ändert. Schließen Sie mit einer einzigen dokumentierten Entscheidung ab: im vereinbarten Umfang fortfahren, unter ausdrücklich genehmigten Bedingungen fortfahren oder pausieren, bis benannte Nachweise vorliegen. Legen Sie einen Termin für die Neubewertung fest. So ist die Checkliste auch dann nützlich, wenn die Antwort „noch nicht“ lautet, weil die nächste Maßnahme und der erforderliche Nachweis klar sind. ## Welche Rolle easyIGA in der Bewertung spielt [easyIGA](https://easyiga.com/de/produkt) ergänzt midPoint um einen Arbeitsbereich für die Fachbereiche. Mitarbeitende beantragen Zugriff, und Führungskräfte entscheiden mit dem verfügbaren Kontext. Die [Nachweisübersicht](https://easyiga.com/de/produkt#evidence-receipt) erläutert erfasste Genehmigungen, Berechtigungsvergaben außerhalb von easyIGA und fehlende historische Einträge. Prüfungen auf Richtlinienkonflikte sind zum Zeitpunkt der Entscheidung verfügbar; das Erstellen und Simulieren von Regeln in easyIGA ist noch geplant. Die erforderlichen SAP- und Nicht-SAP-Operationen sind Teil des für Ihre Migration vereinbarten Integrationsumfangs. [Die Erfahrung unseres Teams](https://easyiga.com/de/ueber-uns) umfasst mindestens 14 midPoint-Einführungen. Anhand Ihrer Bestandsaufnahme ermitteln wir den Migrationsaufwand, die unterstützten Versionen und die Zuständigkeiten, bevor wir einen Umsetzungsplan vereinbaren. Ein klar abgegrenztes Pilotprojekt liefert beiden Teams konkrete Nachweise für die nächste Phase. [Offene SAP-IdM-Punkte besprechen](https://easyiga.com/de/kontakt) [Das IGA-Betriebsmodell verstehen](https://easyiga.com/de/blog/was-ist-iga) ## Quellen und redaktionelle Angaben Angaben zum Produktumfang und redaktionelle Formulierungen am 12. Oktober 2026 aktualisiert. Die ursprünglichen Daten der Quellenprüfung sind unten unverändert angegeben. Geprüft am 12. September 2026. Die Prüfpunkte, die vorgeschlagenen Nachweise und die Go/No-Go-Kriterien sind redaktionelle Umsetzungshinweise. Sie sind weder vertragliche Bedingungen von SAP noch Kundenergebnisse. - [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), Februar 2024; Angaben zu Mainstream-Wartung und erweiterter Wartung. - [SAP Note 3268799](https://me.sap.com/notes/3268799), zugriffsgeschützte Supportreferenz; in dieser Prüfung nicht eigenständig eingesehen. Klären Sie die Anwendbarkeit mit der für Ihren SAP-Support verantwortlichen Person. - [Microsoft Learn: Migrate identity management scenarios from SAP IdM](https://learn.microsoft.com/en-us/entra/id-governance/scenarios/migrate-from-sap-idm), fortlaufend aktualisierter Migrationsleitfaden; herangezogen für Zuständigkeiten im Zielbild und Aspekte der Bereinigung. - [Microsoft Learn: Revoke user access in an emergency](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access), fortlaufend aktualisierte technische Dokumentation zu den Grenzen zwischen Sitzungen beim Identitätsanbieter und in Anwendungen. - [Evolveum: Synchronisation in midPoint 4.10](https://docs.evolveum.com/midpoint/reference/support-4.10/synchronization/), versionsspezifische Dokumentation; Aspekte zu Abgleich und Zielzustand. - [Produktumfang von easyIGA](https://easyiga.com/de/produkt) und [Hintergrund unseres Teams](https://easyiga.com/de/ueber-uns), aktuelle Angaben zum Produktivstand. Foto: [imgix / Unsplash](https://unsplash.com/photos/server-racks-in-data-center-klWUhr-wPJ8), [Unsplash License](https://unsplash.com/license); Bild aus unserem bestehenden Redaktionsbestand, Quellenangabe übernommen und geprüft. Korrekturen senden Sie uns über unsere [Kontaktseite](https://easyiga.com/de/kontakt). ## Über das easyIGA-Team Die midPoint-Erfahrung unseres Teams aus Kundenprojekten fließt in easyIGA und in die praxisnahen Hinweise auf dieser Website ein. Die Menschen hinter dem Produkt stellen wir unter „Über uns“ vor. [Über das easyIGA-Team](https://easyiga.com/de/ueber-uns) Übersetzung aktualisiert: 20. Oktober 2026