Dieses Projekt ist ein Erfolgsbeispiel für Staff Augmentation: Statt ein abgeschlossenes Projektpaket zu liefern, hat Tuix einen erfahrenen Entwickler direkt in das Team des Kunden eingebettet und dessen interne Kapazitäten mit spezialisierter Identity-Expertise erweitert, so lange, wie es gebraucht wurde.
Der Kunde, eine Unternehmensgruppe im Marketplace-Bereich, betrieb mehrere Webanwendungen, darunter auch solche, die von anderen Unternehmen übernommen wurden und weiterhin unter ihrer ursprünglichen Marke liefen. Das Frontend-Branding blieb getrennt, doch das Ziel im Backend war eindeutig: alles unter einem einzigen Identity Provider vereinheitlichen, den Wartungsaufwand mehrerer parallel betriebener Authentifizierungssysteme reduzieren, und das, ohne Millionen von Nutzern zu einem Passwort-Reset oder einem fehlerhaften Login-Prozess zu zwingen.
Ein erfahrener Tuix-Entwickler wurde für ein volles Jahr als eingebetteter Ingenieur Teil des Identity-Engineering-Teams des Kunden und arbeitete in dessen deutscher Zeitzone, um im gleichen Rhythmus wie der Rest des Teams zu arbeiten. Eingebunden in die Sprints, Tools und Code-Reviews des Kunden, entwickelte er die Migrationsstrategie gemeinsam mit dem internen Team und führte sie bis zur Umsetzung durch, Architekturentscheidungen, die Aufteilung zwischen Lazy und Bulk-Migration, das gestaffelte Rollout und schließlich die Ablösung der Legacy-Identity-Provider. Nach der Migration verbrachte der Entwickler die verbleibende Zeit damit, gemeinsam mit dem Team des Kunden das neue Identitätssystem zu pflegen und weiterzuentwickeln, bevor das Projekt abgeschlossen wurde.
Ein Entwickler. Ein IdP. 4.2 Millionen Nutzer, die nichts davon gemerkt haben.
Vor der Migration
Nach der Migration
Legacy-Multi-IdP-Landschaft
Das Ökosystem des Kunden umfasste mehrere Plattformen, die jeweils separate Identitätssysteme und Legacy-IdPs nutzten. Dieser fragmentierte Ansatz führte zu operativer Komplexität, inkonsistenten Nutzererfahrungen und doppelter Identitätslogik.
Zentralisierte Identität mit Auth0
Wir führten Auth0 als einzigen Identity Provider (IdP) ein, um die Authentifizierung zu zentralisieren und SSO über die Plattformen hinweg zu ermöglichen. Die neue Architektur leitet die Authentifizierung über Auth0, während sie ein gestaffeltes Nebeneinander mit den Legacy-IdPs während der Migration erlaubt.
Lazy Migration (Migration beim Login)
Für eine Produktfamilie setzten wir Lazy Migration um: Wenn sich ein Nutzer über den neuen Auth0-Flow anmeldet, prüft das System zunächst die Zugangsdaten gegen den Legacy-IdP (AWS Cognito). Bei Erfolg wird der Nutzer in Echtzeit ohne Unterbrechung zu Auth0 migriert. Das minimiert die Reibung für Nutzer und vermeidet Masse-Resets.
Bulk-Migration mit gestaffeltem Rollout
Für andere Produktnutzer führten wir ein Bulk-Migrationsskript aus, um Nutzer in Auth0 zu importieren. Um das Risiko zu senken, nutzten wir A/B-Tests und gestaffelte Traffic-Verschiebungen, sodass eine Teilmenge der Nutzer den neuen Login-Flow früh sah, was uns erlaubte, Probleme vor dem vollständigen Umstieg zu erkennen.
Koexistenz & schrittweiser Umstieg
Während der Migration liefen Auth0 und die Legacy-IdPs nebeneinander. Das ermöglichte Verifikation, Drosselung, Rollback und fortlaufende Anpassungen des Routings, um Ausfallzeit-Freiheit und eine reibungslose Nutzererfahrung sicherzustellen.
Identität & Auth
Auth0 neuer zentralisierter Identity Provider (SSO, moderne OIDC/OAuth-Flows). AWS Cognito & individuelle IdPs Teil der Legacy-Identitätslandschaft. Diese Systeme wurden während der Migration aufrechterhalten, um Koexistenz und einen nahtlosen Übergang ohne Störung der Nutzer sicherzustellen.
Backend & Orchestrierung
AWS Lambda (TypeScript) leichtgewichtige Migrations-/Validierungsaufgaben und ereignisgesteuerte Verbindungslogik. AWS API Gateway sicheres Routing für Auth-Flows und Migrations-Endpunkte.
Daten & Storage
DynamoDB leichtgewichtiger Nutzerstatus bzw. Migrations-Metadaten (in der Orchestrierung genutzt). S3 / CloudFront Hosting von Assets bzw. Rollout-Frontends, wo nötig.
Frontend (Konsumenten-Apps)
Vue.js / React Konsumenten-Apps, die nun Auth0 zur Authentifizierung nutzen.
Die Lazy Migration minimierte die Reibung für Nutzer, indem sie diese nahtlos beim ersten erfolgreichen Login umzog, statt Passwort-Resets zu erzwingen – Nutzererfahrung und Kundenbindung hatten Vorrang vor einem schnelleren, aber riskanteren Umstieg; die Bulk-Migration in Kombination mit A/B-Tests erlaubte es dem Team, den Ansatz im großen Maßstab zu validieren und Randfälle früh zu erkennen, statt alles auf einen einzigen riskanten Moment zu setzen; und die Konsolidierung auf Auth0 als einzige Quelle der Wahrheit für Identität vereinfachte das langfristige Identitätsmanagement, verbesserte die Sicherheitslage des Kunden und ermöglichte konsistentes SSO über alle Produkte hinweg. Das waren genau die Art von Abwägungen, die davon profitieren, dass ein Ingenieur den vollständigen Kontext über den gesamten Migrationsprozess trägt, statt dass Entscheidungen jedes Mal neu verhandelt werden, wenn ein anderer Berater den Faden aufnimmt.
Automatisierte Nutzer-Migrationsflows beim Login (Lazy Migration). Skriptbasierte Bulk-Migrationspipeline mit gestaffeltem Rollout und A/B-Tests. Ausfallzeit-freie Umstiege durch Koexistenz von Legacy- und neuem IdP. Token- und Session-Handling einheitlich über Auth0 für konsistentes SSO-Verhalten.
Login-Erfolgsraten, Fehlerraten, Latenz und Nutzerabbrüche wurden während der Migrationsfenster nahezu in Echtzeit verfolgt, um Probleme früh zu erkennen. Jeder Migrationsflow war darauf ausgelegt, die Integrität von Passwörtern zu wahren und sensible Daten sicher zu handhaben, mit verschlüsselter Übertragung und Speicherung, und Rollback-Pläne mit gestaffelten Drosselungen standen bereit, um den Traffic bei kritischen Problemen zurück auf die Legacy-IdPs zu leiten, mit automatisierten Health-Checks und Canary-Prozentsätzen zur Steuerung des Rollout-Tempos. Weil der Entwickler das ganze Jahr über eingebettet war, war es derselbe Ingenieur, der diese Sicherungsmechanismen gebaut hatte und sie auch im Produktivbetrieb beobachtete – nichts am Verhalten des Systems unter echtem Traffic musste von jemand Neuem erst neu gelernt werden.
Die Migration von Millionen Nutzern erforderte sorgfältige Orchestrierung, Chunk-Verarbeitung sowie robuste Retry- und Kompensationslogik, um Fehler geordnet zu behandeln; Unterschiede in gespeicherten Zugangsdatenformaten und Legacy-Auth-Verhalten erforderten gezielte Behandlung während der Lazy Migration; und selbst eine kleine Störung im Auth-Flow kann echte Nutzerabwanderung verursachen, weshalb jede Migrationsentscheidung minimalen sichtbaren Impact über Geschwindigkeit stellen musste. Diese Urteilsfähigkeit über eine einjährige Migration hinweg konsistent zu bewahren, fiel als einzelner Embedded Engineer leichter, der die Geschichte des Systems von Anfang bis Ende kannte, statt als etwas, das mittendrin zwischen Personen weitergereicht wird.
