In den letzten Jahren war ich immer wieder in Projekten tätig, wo eine größere Anwendung durch eine neue ersetzt werden sollte. Häufig sollte dabei eine Windows Desktopanwendung durch eine Webanwendung ersetzt werden. Warum und wie man dieses auch bei Desktopanwendungen Schritt für Schritt, also ohne Big Bang, hinbekommt, darum soll es in diesem Artikel gehen.

Schrittweise vs Big Bang

Darüber, dass man große Anwendungen nicht in einem Big Bang sondern schrittweise ablösen sollte, gibt es schon viele Artikel. Martin Fowler hat dieses bspw. im Strangler Fig Pattern festgehalten. In dem Pattern geht es vom Prinzip her darum, dass die neue Anwendung in die alte integriert wird und dabei immer mehr Bereiche der alten Applikation ersetzt. Das hat folgende Gründe:

• Man kann jederzeit abbrechen oder pausieren: Normalerweise werden vorrangig die am Häufigsten benutzen Teile einer Anwendung modernisiert. Es kann dann sein, dass der Hersteller der Anwendung für sich die Entscheidung trifft, dass der unmodernisierte Rest gut genug ist. Grund hierfür kann bspw. sein, dass Kunden diese nur selten nutzen oder diese nur sehr selten angepasst werden müssen. Die wichtigsten Teile der Anwendung wurden bereits überarbeitet.  Hier hat man nun die Option einfach aufzuhören. Trotzdem arbeiten dann die Endbenutzer und Entwickler in einem Großteil der Zeit in einer modernen neuen Anwendung. Bei der Big Bang Migration sind zumindest einige Kundengruppen dann immer noch auf der Altanwendung oder müssten alternativ mit einem verringerten Funktionsumfang leben, wenn sie auf die modernere Anwendung wechseln wollten.
• Kundenzufriedenheit der am besten zahlenden Kunden: Letztendlich will man immer seine am besten zahlenden Kunden besonders zufrieden stellen, da diese den größten Anteil zum eigenen Unternehmensgewinn beitragen. Häufig benutzen diese Kunden aber auch die meisten Features in der alten Desktopanwendung. Bei einer Big Bang MIgration profitieren sie erst ganz am Ende von der Modernisierung, da sie die neue Anwendung erst nutzen können, wenn alle für sie wichtigen Features in die neue Anwendung überführt wurden. Somit erhalten zuerst Kunden die den geringsten Funktionsumfang der Altanwendung nutzen (aka „die, die am wenigsten zahlen“) Zugriff auf die modernisierte Anwendung. Dieses kann zu Unmut bei den Kunden führen, die am meisten Geld einbringen.
• Was ist, wenn das Geld ausgeht? Auch wenn dem Projekt das Geld ausgeht, hat man bei der schrittweisen Migration schon einen Mehrwert geschaffen. Wenn es bspw. in der Hälfte abgebrochen werden muss, so ist zumindest die Hälfte schon mal modernisiert und bringt den Kunden (hoffentlich) einen Mehrwert.  Bei der Big Bang Migration kann es sein, dass es dem Kunden gar nichts gebracht hat und die Entwicklungszeit verschwendet war. Vor allem hat es den am besten zahlenden Kunden in der Regel eher nichts gebracht.
• Risiko: Zusätzlich zu den bisher erwähnten Risiken, kann bei einer Big Bang Migration auch einiges schief gehen. Bei einer schrittweisen Migration kann im Fehlerfall dagegen leichter zurückgerollt werden um das Problem zu beheben.
• Big Bang ist unmöglich: Natürlich wollen auch die größten Kunden teilweise etwas neues haben. Dieses führt dann dazu, dass man neben einem Team für die Neuentwicklung auch eines für die Altanwendung braucht. Man läuft also auf ewig der Altanwendung beim Big Bang hinterher und es kann sehr lange dauern, diese abzulösen.

Zusammenfassend kann man also sagen, dass man größere Anwendungen nur schrittweise migrieren sollte. Bei kleineren mag es dagegen funktionieren.

Es geht nicht bei Desktopanwendungen, oder doch?

Hat man das Glück, eine Webanwendung zu migrieren, so ist dieses bspw. mit Web Components oder durch Module Federation / Micro Frontends verglichen mit einer Desktopanwendung relativ einfach möglich. In der Vergangenheit musste ich aber häufiger alte Windows Desktopanwendungen ersetzen und dachte hier führe nichts an einer Big Bang Migration vorbei. Bei meinem aktuellen Kunden schaffen sie aber eine schrittweise Migration. Der Trick dabei ist, dass die alte Desktopanwendung die neue in einer Webview einbindet und die beiden über Links sowie Javascript Funktionen miteinander interagieren.

Hier kann man bspw. wie folgt vorgehen:

• Als erstes muss man möglichst unabhängige Bereiche finden. Das ist bei meinem aktuellen Kunden relativ einfach, da es sich um eine Versicherung handelt. Die alte Anwendung hat viele Bereiche wie Absicherungsübersicht, Krankenversicherungen, Autoversicherungen, Lebensversicherungen die relativ unabhängig voneinander sind. Man kann hier bspw. Krankenversicherung als eigenen Bereich herauslösen. Ist es noch nicht so klar, kann man versuchen diese Bereiche bspw. per Event Storming oder Domain Storytelling zu finden.
• Nun kann man bspw. für Krankenversicherungen (oder einen Teil davon) eine neue Webanwendung bauen. Sobald diese einen ausreichenden Funktionsumfang hat, kann die Altanwendung, sobald ein Angebot für eine Krankenversicherung angelegt werden soll, diese in einer Webview öffnen. Für den Benutzer sieht es dann so aus, als befände er sich immer noch in der alten Anwendung.
• Normalerweise muss man irgendwann von der neuen Anwendung auch wieder zurück in die alte. So kann es bspw. sein, dass man nach dem Angebot für die Krankenversicherung wieder zurück in die Absicherungsübersicht möchte, wo alle Versicherungen des Kunden angezeigt werden. Dieses kann man bspw. darüber lösen, dass die Desktopanwendung Javascript Funktionen bereitstellt. Bspw. kann die Desktopanwendung einen Aufruf von window.close() so interpretieren, dass die Webview geschlossen werden soll. Auch andere spezielle Javascript Funktionen sind denkbar. Wenn man in einer Webanwendung auf einen anderen Anwendungsbereich weiterleitet, macht man dieses in der Regel mit Redirects. Dieses kann man auch bei hier so lösen. So kann die Desktopanwendung bei einem Redirect auf eine spezielle Url eine Ansicht in der Desktopanwendung öffnen. Führt die Webanwendung innerhalb der Webview bspw. einen Redirect auf https://www.example.com/angebot/123434?cmd=print aus, so könnte die Desktopanwendung das abfangen und so interpretieren, dass sie das Angebot 123434 in der Druckansicht anzeigen soll.
• Im Optimalfall sollte man immer so vorgehen, dass man die Entwicklung auch mit wenig Vorlauf abbrechen kann. D.h. dass in der Migration möglichst nur Sachen eingebaut werden, die auch später in der Anwendung sein sollen. Bspw. will man einem Mechanismus, der ständig im großen Umfang Daten zwischen der alten und neuen Anwendung, ggf. sogar noch per Datenbanktrigger, hin- und her migriert (Asset Capture Pattern), nicht in seiner modernisierten Anwendung haben. Damit man also immer in der Lage ist, die Migration abzubrechen, sollte man solche Workarounds längerfristig vermeiden.

Das kann man dann immer weiter und weiter machen und so immer größere Teile ersetzen.

Also alles einfach machbar?

Auf ein paar Schwierigkeiten kann man dann trotzdem noch stoßen, die aber alle lösbar und den Problemen bzw. Risiken eines Big Bangs vorzuziehen sind:

• Ggf. möchte man einen Verlauf haben. Der Sachbearbeiter möchte also sehen, woran er gerade gearbeitet hat. Die Altanwendung hat diese Information ggf. nicht, da sie nur die Webview geöffnet hat und nicht weiß, wo man sich innerhalb dieser Webanwendung befindet. Dieses könnte man bspw. darüber lösen, dass man ein Request an die Desktop Anwendung schickt, die die Requests an diese Url dann abfängt und entsprechend interpretiert.
• Als Entwickler arbeitet und testet man normalerweise im Browser. Es mag sein, dass dort etwas funktioniert was dann in der Webview zu Problemen führt. In meinem aktuellen Projekt gab es hier hin und wieder Probleme, aber in der Regel funktionierte in der Webview alles gut. Natürlich gibt es dieses nicht umsonst, aber die Nachteile einer Big Bang Migration sind deutlich gravierender (s.o.).
• Die neue Anwendung wird vermutlich deutlich moderner aussehen, d.h. der Benutzer wird einen Bruch vom Aussehen feststellen je nachdem ob er einen bereits modernisierten oder einen alten Teil der Anwendung benutzt. Mit der Zeit wird der Benutzer aber immer mehr Zeit in dem neuen Teil der Anwendung verbringen. Auch wollen die Kunden gerne die neuen Features haben. Daher wird dieses normalerweise in Kauf genommen.
• Man muss aufpassen, nicht mehrere Browserfenster / Webviews öffnen wenn man auf einen Button in der Anwendung klickt

 Fazit

Ich habe früher auch an Big Bang Migrationen mitgearbeitet. Heute würde ich meinen Kunden immer raten, dieses schrittweise zu probieren, sofern die Anwendung größer ist. Wenn man sie innerhalb von drei bis sechs Monaten komplett abgelöst bekommt, kann man es auch in einem Big Bang realisieren. Wenn man da über fünf Jahre und mehr für braucht, was keine Seltenheit ist, sollte man es definitiv schrittweise machen.