Microservices-Migration eines Konzern-Onlineshops —
ohne einen Tag Ausfall

Die Ausgangslage

Der Shop umfasste ein breites Produktportfolio: Mobilfunkverträge, Smartphones, DSL-Tarife, Router, Zubehör – und einen separaten Bestandskundenshop mit eigenen Anforderungen. Jede dieser Produktwelten hatte ihre eigenen Datenstrukturen und Inhalte, die im Rahmen der Migration vereinheitlicht werden mussten.

Der Shop lief auf XSL/XSLT in einem hauseigenen Framework – Technologie, die für solche Anforderungen nie gedacht war und über ein Jahrzehnt weitergebaut wurde. Das gravierendste Problem: Ein einziger Fehler konnte den gesamten Shop lahmlegen. Kein Teilausfall, kein Fallback. Kein Entwickler hatte noch einen vollständigen Überblick darüber, was das System alles tat.

Was das Projekt wirklich schwierig gemacht hat

Bevor auch nur eine Zeile neuer Code entstehen konnte, musste erst verstanden werden, was überhaupt migriert werden soll. Wir haben systematisch Reverse Engineering betrieben – alten Code analysiert, Abhängigkeiten rekonstruiert, Features aufgelistet. Nicht um alles zu migrieren, sondern um erst mal zu wissen, was da überhaupt ist.

Parallel dazu lief intensives Stakeholder-Management mit den Fachbereichen. Die Frage war nicht nur „was brauchen wir in Zukunft?" – sondern auch „was brauchen wir eigentlich gar nicht mehr?" Viele Features, die jahrelang im System lebten, wurden schlicht nicht mehr genutzt. Die Entscheidung, etwas nicht zu migrieren, ist manchmal die wichtigste Entscheidung im Projekt.

Was das Ganze anstrengend gemacht hat: Oft fehlte der Entscheidungsträger, der diese Calls treffen wollte oder konnte. Entscheidungen, die eigentlich in einem Meeting hätten fallen können, zogen sich über Wochen. Das ist kein technisches Problem – das ist ein organisatorisches. Und es gehört zur ehrlichen Darstellung dieses Projekts dazu.

Dazu kam ein Faktor, der in technischen Projekten oft unterschätzt wird: die Belegschaft. Ein Technologiewechsel in dieser Größenordnung bedeutet für viele Entwickler, dass plötzlich alles, was sie kennen, nicht mehr gilt. Die erste Reaktion ist selten Begeisterung. Am Anfang gab es Ablehnung – Bedenken, wie künftige Features umgesetzt werden sollen, Unsicherheit ob das neue System wirklich besser ist. Diese Überzeugungsarbeit war ein echter Teil des Projekts, über Monate.

Technisch kam noch eine Herausforderung hinzu: Während der Migration mussten alte und neue Welt gleichzeitig funktionieren. Teile der Datenbasis liefen noch auf dem alten System, andere bereits auf dem neuen – und beide mussten miteinander kommunizieren, obwohl sie auf komplett unterschiedlichen Technologien basierten. Kein sauberer Schnitt, kein Big Bang – sondern ein langer Zeitraum, in dem zwei Welten parallel existiert haben. CMS, PIM, CRM – alle Systeme waren Teil dieser Abhängigkeitskette, die nach und nach gehärtet werden musste.

Mein Beitrag

Ich habe das Nearshore-Entwicklungsteam als Product Owner geleitet – eines von drei Teams, die parallel an der Migration gearbeitet haben. Aber der Job war deutlich breiter als Teamführung.

Am Anfang stand Reverse Engineering: Bevor irgendein Sprint geplant werden konnte, musste ich selbst verstehen, was das alte System überhaupt tut. Alten Code analysieren, Abhängigkeiten rekonstruieren, Features listen – und dann mit den Fachbereichen klären, was davon wirklich noch gebraucht wird. Das war keine Aufgabe für das Entwicklungsteam allein. Das war inhaltliche Arbeit, die ich mitgetragen habe.

Parallel dazu: die Belegschaft mitnehmen. Ein Technologiewechsel dieser Größenordnung trifft Menschen. Entwickler, die jahrelang im alten System gearbeitet haben, standen plötzlich vor einer komplett neuen Welt. Die Ablehnung war real – Bedenken, Unsicherheit, Skepsis. Ich habe diese Überzeugungsarbeit aktiv betrieben: in Gesprächen, in Demos, in der täglichen Zusammenarbeit. Change Management war kein Nebenjob, sondern ein echter Teil meiner Rolle.

Auf Teamebene habe ich bewusst darauf geachtet, dass kein Inselwissen entsteht. Teamzusammensetzungen wurden gezielt verändert, Verantwortlichkeiten rotiert. Die Sprints aller drei Teams mussten aufeinander abgestimmt sein – Abhängigkeiten zu Drittsystemen mussten vor Sprintstart geklärt sein, quer durchs Unternehmen. Den Fortschritt habe ich regelmäßig in Steering Committees vertreten, mit hart gesetzten Zielen und der Pflicht, Verzögerungen zu begründen und Lösungen zu liefern.

Die eigentliche Arbeit war: gleichzeitig im System denken, in der Organisation denken und im Team denken – und dafür sorgen, dass alle drei Ebenen nicht gegeneinander arbeiten.

Was danach möglich wurde

Mit der Microservices-Architektur kann das Entwicklungsteam heute wirklich unabhängig voneinander arbeiten und deployen. Ein Fehler in einem Service reißt nicht mehr alles mit. Das Projekt hat mehr hinterlassen als eine neue Architektur – es hat eine neue Arbeitsweise möglich gemacht.

Was vorher Wochen gedauert hat, dauert heute einen Bruchteil davon. Features, die im Monolithen aufwendige Abstimmung, Testzyklen und koordinierte Releases erfordert haben, können Teams jetzt eigenständig und schnell liefern. Die Architektur gibt der Organisation eine Geschwindigkeit zurück, die jahrelang nicht mehr möglich war.

„Solche Projekte scheitern selten an der Technologie. Sie scheitern daran, dass niemand den Überblick hat, niemand Entscheidungen trifft und niemand das Business und die Technik gleichzeitig im Blick behält. Genau das ist die Arbeit, die ich mache." — Matthias Lambert