Praxisrealität: Wo Unternehmen aktuell stehen
Die Angular-Migration im One Identity Manager ist für viele Unternehmen eines der aktuell kritischsten Themen im Identity & Access Management. Sie beschreibt den Wechsel vom Web Designer zu modernen HTML5- und Angular-basierten Webanwendungen über den API Server.
In vielen Unternehmen ist das One Identity Manager Web Portal über Jahre organisch gewachsen. Prozesse wurden erweitert, Formulare angepasst und Oberflächen auf spezifische Fachbereiche zugeschnitten. Genau darin liegt heute das Problem: Was lange als stabiles, vertrautes Portal funktioniert hat, ist technisch an ein Modell gebunden, das strategisch ausläuft.
Die Praxis zeigt, dass viele Kunden das Thema noch immer als klassisches Upgrade betrachten. Tatsächlich geht es aber in den meisten Projekten nicht um ein normales Versionsupdate, sondern um einen grundlegenden technologischen Wechsel des Portalansatzes. Das ist ein wesentlicher Unterschied. Denn während bislang das Web-Designer-basierte Portal im Mittelpunkt stand, setzt One Identity inzwischen klar auf HTML5- beziehungsweise Angular-basierte Webanwendungen über den API Server.
Spätestens mit Identity Manager 9.3 ist diese Richtung nicht mehr nur Empfehlung, sondern Produktrealität: Der Web Designer und darauf basierende Webanwendungen werden dort nicht länger unterstützt.
Viele Organisationen befinden sich deshalb aktuell in einer Zwischenphase: fachlich besteht noch keine Notwendigkeit, technisch aber wächst der Handlungsdruck. Genau diese Diskrepanz führt häufig dazu, dass Migrationsprojekte zu spät eingeplant werden.
Warum die One Identity Angular Migration mehr als ein Upgrade ist
Die One Identity Angular Migration ist weit mehr als ein technisches Upgrade. Sie verändert nicht nur die Benutzeroberfläche, sondern das gesamte Entwicklungs- und Betriebsmodell.
Während der klassische Web Designer stark innerhalb des bestehenden One Identity Frameworks gedacht war, orientiert sich das Angular-basierte Portal an einem modernen Webstack rund um Angular, TypeScript, Git und dem REST-basierten API Server.
Für Unternehmen bedeutet das: Die zentrale Frage ist nicht mehr nur, welche Funktionen im Portal verfügbar sind. Entscheidend ist vielmehr, wie Anpassungen entwickelt, getestet, deployed und langfristig betrieben werden. In der Praxis bedeutet das häufig, dass bestehende Web-Designer-Anpassungen nicht direkt übernommen werden können, sondern neu entwickelt oder bewusst vereinfacht werden müssen.
One Identity Web Designer End of Support: Wer ist betroffen?
Betroffen sind alle Unternehmen, die ihr Web Portal heute noch auf dem Web Designer aufbauen oder umfangreiche individuelle Anpassungen in diesem Modell vorgenommen haben.
Für diese Kundengruppe ist die Situation eindeutig: Spätestens mit dem Upgrade auf Identity Manager 9.3 werden Web Designer und darauf basierende Webanwendungen nicht mehr unterstützt. Stattdessen sollen HTML5-Webanwendungen über den API Server genutzt werden.
Besonders aktiv werden sollten daher Unternehmen, die mindestens einen der folgenden Punkte erfüllen:
- stark angepasstes bestehendes Web Portal
- geschäftskritische Self-Service- oder Attestierungsprozesse
- geplanter Versionssprung in Richtung 9.3 oder höher
- fehlende interne Angular- oder API-Server-Kompetenz
- knappe Releasefenster oder hohe regulatorische Anforderungen an Test und Freigabe
Wichtig ist dabei: Nicht jedes Unternehmen muss in derselben Geschwindigkeit vorgehen. Aber jedes Unternehmen mit relevanten Web-Designer-Anpassungen sollte jetzt belastbar bewerten, wie groß der tatsächliche Migrationsbedarf ist.
Der Fehler liegt selten darin, zu früh zu starten. Der Fehler liegt fast immer darin, das Thema zu spät sauber zu bewerten.
Was sich mit der One Identity Portal Migration konkret ändert
Die größten Veränderungen liegen nicht in einzelnen Features, sondern im konzeptionellen Rahmen.
Das neue Portal ist kein 1:1-Ersatz des bisherigen Web-Designer-Modells. Stattdessen verschiebt sich die Logik hin zu moderner Webentwicklung, API-Nutzung und komponentenorientierter Anpassung.
Das hat mehrere Konsequenzen:
- Individualisierungen werden transparenter, aber entwicklungsnäher
- Anforderungen an Entwicklungs- und Deploymentprozesse steigen
- stärkere Zusammenarbeit zwischen IAM, Webentwicklung und DevOps
One Identity beschreibt diese neue Realität selbst der deutlich: Für die Portalentwicklung sind Angular- und Git-Kenntnisse erforderlich, während der API Server die zentrale Rolle in der Architektur übernimmt.
Aus Kundensicht bedeutet das: Die Migration ist nicht nur eine neue technische Basis, sondern häufig auch ein Wechsel im Arbeitsmodus. Teams, die bislang primär fachnah oder konfigurationsorientiert gearbeitet haben, müssen künftig deutlich stärker mit Entwicklungslogik umgehen.
Die neuen Webtechnologien schaffen eine zukunftssichere Grundlage für Betrieb und Wartung des One Identity Manager. Gleichzeitig erleichtert die moderne Architektur zukünftige Erweiterungen und Migrationen erheblich, da Anpassungen standardisiert, nachvollziehbar und wiederverwendbar umgesetzt werden können.
Gleichzeitig hat die Migration auch Auswirkungen auf das Identity & Access Management selbst. Prozesse wie Self-Service, Access Requests (IT Shop) und portalnahe Customizations sind eng mit dem bestehenden Portal verzahnt und müssen im neuen Modell entsprechend dargestellt und technisch anders umgesetzt werden.
Damit wird die Angular-Migration nicht nur zu einem Frontend-Thema, sondern zu einer Fragestellung der gesamten IAM-Architektur und Governance.
Risiken beim Abwarten: Warum Nichtstun die teuerste Option ist
Aus Projektsicht ist Abwarten fast immer die teuerste Variante. Nicht, weil die Migration sofort abgeschlossen sein muss, sondern weil späte Entscheidungen den Handlungsspielraum drastisch verkleinern.
Wenn Unternehmen zu spät starten, passiert erfahrungsgemäß Folgendes:
Zunächst wird die Migration intern unterschätzt, da das bestehende Portal weiterhin funktioniert. Dann nähert sich ein geplanter Upgrade-Zeitpunkt, und plötzlich wird sichtbar, dass nicht nur Technik, sondern auch Prozesse, Sonderlogiken, Testfälle und Betriebsmodelle betroffen sind. In dieser Phase steigt der Druck meist sprunghaft. Aus einer planbaren Transformation wird ein unter Zeitdruck laufendes Pflichtprojekt.
Die eigentlichen Kosten entstehen dabei selten nur durch Implementierung. Sie entstehen vor allem durch mangelnde Vorbereitung: unvollständige Bestandsaufnahme, fehlende Priorisierung, späte Einbindung der Fachbereiche und vermeidbare Reibungsverluste zwischen Teams.
Auch aus Compliance-Gründen ist der Betrieb des alten Portals nach Ende des Supports für die Version 9.2 ab Juli 2027 oft nicht möglich.
Wer also früh startet, gewinnt Optionen. Wer spät startet, verwaltet Zwänge.
Aufwand und Komplexität: Wovon die Migration wirklich abhängt
Der Migrationsaufwand hängt weniger von einer einzelnen Produktversion ab als vom individuellen Ausgangspunkt.
Entscheidend sind vor allem:
- der Anpassungsgrad des bestehenden Portals
- die Tiefe der Web-Designer-Nutzung
- die Anzahl geschäftskritischer Prozesse
- die Qualität der bestehenden Dokumentation
Typische Aufwandstreiber sind:
- viele individuelle Formulare, Seiten oder Sonderlogiken
- historisch gewachsene Anpassungen ohne klare Dokumentation
- enge Verzahnung mit fachlichen Freigabe- oder Bestellprozessen
- fehlende Trennung zwischen Standard und Customizing
- geringe Verfügbarkeit interner Angular- oder API-Kompetenz
- aufwendige Test- und Freigabeanforderungen
Aufwandsmindernd wirken dagegen eine klare Standardorientierung, überschaubare Individualisierung, gute Dokumentation und eine frühe Priorisierung nach geschäftlichem Nutzen.
Eine belastbare Zeitplanung sollte deshalb nicht mit fixen Pauschalzahlen starten, sondern mit einer strukturierten Bewertung des Ist-Zustands. Wer versucht, die Migration zu früh in Wochen oder Personentagen zu beziffern, unterschätzt häufig die fachlichen und organisatorischen Nebeneffekte.
Typische Stolpersteine der Angular Migration
Rückblickend zeigen viele frühe Projekte ein ähnliches Muster: Nicht die eigentliche Technik ist das größte Problem, sondern die falsche Annahme, dass sich das bisherige Portal weitgehend direkt übertragen lässt.
Typische Stolpersteine sind:
- fehlende Transparenz über bestehende Web-Designer-Anpassungen
- zu spätes Einbinden der Fachbereiche
- Start ohne Zielbild für Standard vs. individuelle Implementierung
- Unterschätzung von Testaufwand und Abnahmeschleifen
- fehlende Entwicklungs- und Deployment-Standards für das neue Portal
- Versuch, alte Konzepte unverändert in die neue Architektur zu "kopieren"
Was man heute anders machen würde als in früheren Projekten? Vor allem früher analysieren, konsequenter priorisieren und stärker zwischen "muss migriert werden" und "war historisch gewachsen, aber nicht mehr sinnvoll" unterscheiden.
Der richtige Upgrade-Pfad: Wie Unternehmen strukturiert vorgehen sollten
Der richtige Weg in die Migration beginnt nicht mit Entwicklung, sondern mit Klarheit. Unternehmen sollten zuerst verstehen, was sie heute tatsächlich betreiben, welche Anpassungen geschäftskritisch sind und welches Zielbild fachlich und technisch sinnvoll ist.
Ein strukturierter Einstieg besteht meist aus vier Schritten:
Bestandsaufnahme
Welche Web-Designer-Anpassungen existieren ? Was ist Standard, was ist individuell, was wird wirklich genutzt?
Bewertung und Priorisierung
Welche Funktionen sind geschäftskritisch? Was muss 1:1 erhalten bleiben, was kann vereinfacht oder neu gedacht werden?
Zielarchitektur und Betriebsmodell definieren
Welche Kompetenzen werden benötigt? Wie laufen Entwicklung, Deployment und Betrieb im Angular-/API-Server-Modell?
Pilot statt Big Bang
Ein kontrollierter Einstieg über priorisierte Use Cases reduziert Risiko und schafft belastbare Erfahrungswerte für die Gesamtmigration.
Fazit: Warum jetzt der richtige Zeitpunkt ist
Die Angular-Migration ist kein Thema für "irgendwann später". Nicht, weil sofortiges Handeln angebracht wäre, sondern weil Unternehmen jetzt noch die Möglichkeit haben, aus einer Pflichtaufgabe ein steuerbares Transformationsprojekt zu machen.
Mit Identity Manager 9.3 ist die Richtung klar vorgegeben: Der Web Designer gehört nicht mehr zur unterstützten Architektur. Wer weiterhin auf dem alten Portalmodell aufbaut, verschiebt kein normales Upgrade, sondern ein strategisch relevantes Modernisierungsthema. Entscheidend ist jetzt, Klarheit über die eigene Ausgangssituation zu schaffen. Nur so lässt sich der Migrationsbedarf realistisch bewerten und ein sinnvoller, strukturierter Weg in die neue Architektur definieren.
Angular Migration strukturiert angehen – mit der richtigen Unterstützung
Wenn Sie aktuell nicht sicher sind, wie groß Ihr Migrationsbedarf ist oder wie Sie strukturiert vorgehen sollten, lohnt sich eine frühzeitige Bewertung Ihrer bestehenden Portalarchitektur.
Die gute Nachricht lautet: Mit einer realistischen Bestandsaufnahme, einer klaren Priorisierung und einem pragmatischen Zielbild lässt sich der Umstieg strukturiert planen. Genau hier liegt auch der Mehrwert aus Projekterfahrung: nicht nur technisch zu migrieren, sondern die richtigen Entscheidungen in der richtigen Reihenfolge zu treffen.
IPG begleitet diese Fragestellungen seit Jahren in Kundenprojekten und unterstützt Sie dabei, Ihre Ausgangssituation transparent zu analysieren, Risiken zu identifizieren und eine realistische Migrationsstrategie zu entwickeln – bevor aus einem planbaren Projekt ein Zeitdruck-Thema wird.
