Gründe für die Software-Migration
Es gibt viele Szenarien, die eine Migration notwendig machen:
Wissensverlust im Unternehmen
„Günther geht nächstes Jahr in Rente und er ist der Einzige, der sich mit der AS400 auskennt. Was machen wir jetzt?"
Fehlender Support
„Hier ist ein Brief von der XYZ AG: Sie haben tatsächlich den Support für ihr Framework eingestellt. Ab jetzt gibt es keine Security-Updates und keine Bugfixes mehr!"
Gesetzliche Anforderungen
„Seit zwei Wochen sind die neuen Gesetze bezüglich der Verwaltung von personenbezogenen Daten relevant. Mit unserer Software können wir die aber nicht abbilden."
Die Gründe, warum die Migration einer Software notwendig wird, sind so vielfältig wie die Software-Systeme selbst. Jeder Software-Entwickler weiß, dass Software auch gewartet werden muss, in der Praxis ist das aber nicht immer leicht zu realisieren.
Warum die Begründung oft schwerfällt - Viele Legacy-Systeme laufen seit Jahren stabil.
Für Management und Anwender ist schwer nachvollziehbar, warum eine Migration von Altsystemen so dringend und kostenintensiv ist, davor vielen Jahren auf Basis des damals aktuellen Software-Stacks entwickelt wurde und seither gute Dienste leistet, ist der Antrieb, die Technologie zu aktualisieren häufig nicht so hoch. Das ist auch nicht weiter verwunderlich. Wie soll man den Anwendern oder noch wichtiger, dem Management verkaufen, dass eine Migration notwendig ist, die zwar viel Geld kostet, bei der nach außen hin aber nachher alles genauso aussieht wie vorher? Also werden Migrationen immer wieder verschoben.
Wann Software-Migration unumgänglich wird
Irgendwann kommt der Zeitpunkt, an dem es nicht mehr weitergeht. Die Technologie, auf der die Software basiert, erreicht zum Beispiel das Lebensende. Mit dem Ende des Supports gibt es auch keine Sicherheitsupdates mehr. Ein anderer Grund kann sein, dass wichtige Wissensträger das Unternehmen verlassen (und sei es in den wohlverdienten Ruhestand).
Manche Systeme haben einen Zustand erreicht, in dem das Entwickeln von neuen Features langwierig und zäh ist. Baut man an einer Stelleetwas an, geht eine andere kaputt, obwohl diese unabhängig zu sein scheint. Eine Modernisierung der Software ist nun notwendig, um zukünftige Features in einer akzeptablen Geschwindigkeit umsetzen zu können. In manchen Fällen ist nicht das reine Umsetzen, sondern der Prozess zur Inbetriebnahme eines Features die Herausforderung. Wenn nur zwei oder drei Releases im Jahr möglich sind, kann eine angemessene Time-to-Market nicht erreicht werden.
Risiken und Herausforderungen der Migration
Auf dem Weg zu einer erfolgreichen Softwaremigration gibt es viele Stolpersteine. Von der Planung bis zur Implementierung erfordert jeder Schritt sorgfältige Überlegungen, eine definierte Vorgehensweise und auch immer wieder Reflexion. Das bedeutet allerdings nicht, dass es immer sinnvoll ist, den gesamten Prozess bis ins kleinste Detail im Vorfeld zu planen.
Iteratives Vorgehen minimiert Risiken
Statt Big Bang empfiehlt sich eine schrittweise Migration. Einzelne Module oder Features werden übertragen, um Risiken zu kontrollieren. Deshalb gilt es eine Strategie zu wählen, die die Risiken während der Migration minimiert. Die gewählte Strategie kann dann in einen groben Fahrplan überführt werden. Es kann sinnvoll sein, zunächst einzelne Teile der Software zu migrieren, um Aufwände und Komplexitäten besserabschätzen zu können und so das Risiko zu reduzieren.
Typische Stolpersteine
Aufwandsexplosion
Viele Migrationen scheitern, weil der Aufwand initial als zu niedrig eingeschätzt wird. Später stellt man fest, dass man das geplante Budget zwar verbraucht hat, aber kein lauffähiges System hat. Bricht man die Migration ab, ist nichts erreicht.
Benutzerakzeptanz
Wir haben Migrationen erfolgreich abgeschlossen, in dem wir sie so geplant haben, dass wir sehr schnell erste Erfolge erzielen konnten. Die Zwischenergebnisse stellten bereits signifikante Verbesserungen dar. Wir führen Migrationen so durch, dass regelmäßig Versionen mit einem Mehrwert in Betrieb genommen werden können.
Datenmigration
Dadurch ist auch eine regelmäßige Kosten-Nutzen-Rechnung der verbleibenden Migration möglich. Sollten die Kosten den Nutzen übersteigen, muss eine Migration auch abgebrochen werden können. Wenn das bis dahin Erreichte eine Verbesserung zum Initialzustand darstellt, war die Migration ein Erfolg obwohl sie nicht zu Ende durchgeführt wurde.
Internes Marketing & Change-Management bei der Software-Migration
Ein oft unterschätzter Erfolgsfaktor jeder Software-Migration ist die Benutzerakzeptanz. Selbst wenn das Migrationsprojekttechnisch perfekt umgesetzt wurde, kann es scheitern, wenn Mitarbeitende das neue System ablehnen. Deswegen ist es unerlässlich, dass die Anwenderfrühzeitig einzubeziehen werden. Durch gezielte Schulungen, Workshopsund interne Kommunikation können sie mit der neuen Software vertraut gemacht werden und so merken, dass auch sie Vorteile bekommen. Zusätzlich liefert das Feedback der Nutzer wertvolle Impulse, um das Endergebniskontinuierlich zu verbessern.
Allgemein wird es sehr positiv aufgenommen, wenn der Migrations-Fortschritt transparent im Unternehmen kommuniziert wird. Proaktive Updates zu Meilensteinen und möglichen Verzögerungen verhindern Missverständnisse und fördern eine positive Erwartungshaltung gegenüber der neuen Lösung.
Datenmigration & Sicherung der Systemfunktionen
Es ist einfach, eine Applikation zu deinstallieren und eine neue zu installieren. Die Schwierigkeiten beginnen mit der Übertragung der Daten aus dem Bestandssystem in das neue System. Die Strukturen und Abhängigkeiten müssen verstanden werden. Gegebenenfalls ist die Qualität der Daten im Bestandssystem verbesserungswürdig. Wir legen großen Wert darauf, die Bestandsdaten zu verstehen und fachlich korrekt zu überführen. Dasselbe gilt für die wichtigen Funktionen des Bestandssystems.
Hier ist neben der Korrektheit und Vollständigkeit der Daten auch auf die Performance des Migrationsprozesses zu achten. Dauert die Datenübertragung zu lange, kann es zu Stillständen oder Kostenüberschreitungen kommen. In diesem Fall müssen Migrationsstrategie und Tools angepasst werden, um eine effiziente und sichere Transformation zu garantieren.
Erfolgreiche Software-Migration in 6 Schritten
Schritt 1: Ziele & Anforderungen definieren
Zu Beginn muss geklärt werden, welche Ziele mit der Migration verfolgt werden. Es muss die Frage beantwortet werden, was von dem System nach der Migration erwartet wird. Was soll anders sein und im Idealfallbesser? Indem wir die Ziele und Anforderungen klären, wird sichergestellt, dass die neue Software den Bedürfnissen entspricht. Dies hilft bei der Auswahl desrichtigen Migrationsansatzes und der geeigneten Tools.
Wenn mangelnde Software-Qualität ein Auslöser der Migration ist, dann muss eines der Ziele die Verbesserung derselben sein. In jedem Fall sollte sie mindestens aufrechterhalten werden. Eine Migration stellt auch immer die Chance dar, Fehler aus der Vergangenheit mit dem Wissen von heute zu korrigieren. Diese Chance sollte nicht verpasst werden.
Schritt 2: Analyse der bestehenden Systeme
Analyse der Bestandssoftware als Grundlage für die richtige Migrationsstrategie.
In unseren Projekten haben viele erfolgreiche Migrationen durchgeführt, in dem wir zunächst analysiert haben, welche Teile der Legacy-Software geschäftskritisch sind und unbedingt in die neue Welt übernommen werden müssen. Diese Priorisierung schafft Transparenz und ermöglicht eine fundierte Risikoanalyse.
Für die Analyse einer Bestandssoftware wir sehr gute Erfahrungen mit Big-Picture Event-Stormings gemacht. Dies hat sich als effektive Methode erwiesen, um alle Prozesse und beteiligten Komponenten zu identifizieren.
Bereits nach dem initialen Workshop ist in der Regel das gesamte Wissen über die Software zusammengeführt, und zwar von allen Stakeholdern und Entwicklern. Dieses konsolidierte Ergebnis bildet die ideale Grundlage für die Auswahl der optimalen Migrationsstrategie und legt den Grundstein für eine erfolgreiche IT-Modernisierung.
Schritt 3: Die passende Migrationsstrategie wählen
Es gibt verschiedene Strategien für die Softwaremigration. Die Wahl der richtigen Strategie hängt von verschiedenen Faktoren ab. Dazugehören z.B. Art, Umfang und Komplexität der zu migrierende Software, dem verfügbaren Budget und den zeitlichen Einschränkungen.
Was ist die Big-Bang-Strategie?
Ein verbreiteter Ansatz ist die sogenannte "BigBang"-Methode, bei der die gesamte Software in einem einzigen Schrittmigriert wird. Dieser Ansatz klingt effizient, bringt jedoch erhebliche fachliche und technische Risiken mit sich. Die größte Herausforderung bei dieser Strategie ist es, die neue Software parallel zur bestehenden Lösung entwickelt werden muss. Deshalb müssen alle Features, die während der Entwicklungszeit der neuen Software in die alte einfließen immer doppeltimplementiert werden (einmal in der alten und einmal in der neuen Software).
Praxisbeispiel einer Big-Bang-Migration
Wir haben selbst eine Big-Bang-Migration durchgeführt, bei der es um den Wechsel einer Programmiersprache ging. Um das zu realisieren, wurde die neue Software auf Basis des Source-Codes der altenautomatisch generiert. Über einen Zeitraum von rund einem Jahr wurde die Migration täglich testweise durchgeführt. Auf Basis des Ergebnisses wurde der Generator iterativ verbessert. Durch die automatische Migration konnte das doppelte Implementieren von Features vermieden werden.
Die Entwicklung des Migrations-Generators hat in diesem Projekt den großen Teil der Zeit des Projektes eingenommen. Die eigentliche Umstellung – also die Code-Generierung und der Systemwechsel –konnte dann innerhalb eines einzigen Wochenendes erfolgreich durchgeführt werden.
Strangler-Fig-Application
Die zweite Kategorie von Migrations-Strategien ist die schrittweise Migration. Diese Strategien werden häufig Strangler Fig Application genannt. Der Name Strangler Fig bezieht sich auf einen Blog-Post von Martin Fowler. Er vergleicht darin die schrittweise Migration einer Software mit einer Schlingpflanze, die einen Baum umschlingt, bis er schließlich stirbt. Es werden also nach und nach Teile der Bestandssoftware ersetzt, bis diese schließlich abgeschaltet werden kann.
Feature-basierte Migration
In der Praxis setzen wir je nach Anwendung zwei Arten von schrittweisen Migrationen ein. Die erste ist die feature-basierte Migration. Jedes neue Feature wird komplett in der neuen Anwendung implementiert. Das Bestandssystem wird nur noch für die bestehenden Features verwendet. Die Herausforderung dieser Strategie ist, dass neue und alte Anwendung häufig auf dieselben Daten zugreifen. Diese Daten müssen kontinuierlich synchronisiert werden. Hierfür bietet sich das Event-Interception-Pattern an. Hat man dieses Pattern einmal etabliert, kann man nicht nur neue Features im neuen System umsetzen, sondern auch Features aus dem Bestandssystem Schritt für Schritt im neuen System implementieren.
Modulbasierte Migration
Da das Bestandssystem auch bei der feature-basierten Migration angepasst werden muss (um die Event-Interception zu implementieren),bietet sich an, die Modularisierung nicht auf Basis neuer Features vorzunehmen, sondern fachlich. Bei einem solchen Ansatz geht es zunächst darum, die Softwarekonzeptionell in fachliche Module zu zerteilen. Wir bedienen uns in der Regel den Methoden des Domain Driven Design. Mit den dort existierenden Ansätzen können Bounded Contexts identifiziert werden, die als fachliche Module realisiert werden sollten. Hier eignen sich insbesondere Process Modelling Workshops und Software Design Workshops.
Die gefundenen fachlichen Module extrahiert man während der Migration Modul für Modul aus der Bestandssoftware.
Schritt 4: Migrationsprozess planen
Unterschiedliche Migrationsstrategien im Vergleich
Plant man die Migration trotz aller Risiken als Big Bang, ist die größte Herausforderung die Doppelentwicklung von Features. Entscheidet man sich für den Big-Bang-Ansatz, besteht die größte Herausforderung in der Doppelentwicklung von Features. Da die Weiterentwicklung der Bestandssoftwarewährend des Projekts meist nicht komplett gestoppt werden kann, müssen alle neuen Funktionen sowohl im alten als auch im neuen System implementiert werden. Um das einzuplanen, muss von vornherein eine Strategie entwickelt werden. Eine Möglichkeit zur Lösung dieses Problems ist die oben beschriebene automatische Migration.
Wählt man den modulbasierten Ansatz, muss zunächst überlegt werden, welches Modul zuerst extrahiert werden soll. Es bietet sich an, eines mit möglichst wenig Abhängigkeiten zu wählen. Auf diese Weise kann ein schneller Erfolg erzielt und das Vorgehen der Migration kann geübt werden. Beim modulbasierten Ansatz wird die Software schrittweise modernisiert, indem einzelne Module nacheinander extrahiert und migriert werden. Sinnvoll ist es, zunächst mit einem Modul mit wenigen Abhängigkeiten zu starten. So lassen sich schnelle Erfolge erzielen und Erfahrungen sammeln.
Wählt man eine feature-basierte Migration, liegt der Fokus auf den Daten, die sowohl vom Bestandssystem und als auch von den neuen Features verändert werden. Für diese muss man eine kontinuierliche Synchronisation planen. Je nach Art des Bestandssystems kann diese Synchronisation unterschiedlich gestaltet sein. Mögliche Lösungen reichen von einem API Gateway, der Requests im neuen und im Bestandssystem ausführt, bis hin zu Datenbank-Triggern.
Schritt 5: Schrittweise Umsetzung mit Feedback-Schleifen
Bei der Umsetzung der Migration ist es wichtig, regelmäßige Feedback-Schleifen einzuführen.
Bei der Umsetzung einer Software-Migration ist es entscheidend, regelmäßige Feedbackschleifen einzuführen. Viele Stolpersteine treten oft erst während der Migration auf. Dann ist es entscheidend, solche Stolpersteine frühzeitig zu erkennen, um den geeigneten Umgang damit bewusst zu planen. Die kontinuierliche Zusammenarbeit der Software-Teams spielt dabei eine zentrale Rolle. Anstatt dass einzelne Teams isoliert arbeiten, sollten Fortschritte regelmäßig gemeinsam überprüft werden. Dies ermöglicht nicht nur eine frühzeitige Problemerkennung, sondern sorgt auch dafür, dass Anpassungen schnell umgesetzt werden können.
Das große Ziel dieser Feedbackschleifen ist es, die Migration so sanft wie möglich zu gestalten und sie dennoch kontinuierlich voranzubringen.
Schritt 6: Erfolge messen & kommunizieren
Wie bereits oben erwähnt, sollten alle beteiligten Personen auf dem Laufenden gehalten werden. Dies fördert die Akzeptanz der Migration innerhalb des Unternehmens. Insbesondere kleine Erfolge sollten regelmäßig kommuniziert werden.
Bei der Präsentation eines neuen Features sollte z.B. darauf hingewiesen werden, dass es auf Basis der neuen Plattform entstanden ist(ggf. mit dem Vermerk, dass dieses Feature erst durch die Migration möglichgeworden ist).
Fazit
Erfolgreiche IT-Modernisierung durch Software-Migration
Jede Software-Migration ist anders und muss individuell geplant werden. Dennoch ist es sinnvoll, Erfahrungen aus vorherigen Migrationsprojekten einfließen zu lassen. Die gewählte Strategie musssicherstellen, dass wichtige Daten und Funktionen sicher übertragen werden. Die Planung des Migrationsprozesses sollte so gestaltet sein, dass die täglichen Geschäftsabläufe so wenig wie möglich beeinträchtigt werden. Mit einer fundierten Analyse und einer soliden Planung kann das gelingen.
Anmerkungen: Dieser Artikel wurde von Arne Limburg und Olaf Prins verfasst.
