Jede Individualsoftware benutzt Standard-Software, sei es die Datenbank, das Betriebssystem, Drittsoftware, mit der kommuniziert werden muss oder das Entwicklungssystem, mit dem die Individuallösung erstellt wurde. Standard-Software wird weiterentwickelt und so stellt sich für die Individuallösung irgendwann die Frage der Migration auf eine neue Version der genutzten Plattform.
Oft wartet man mit einer solchen Migration so lange, bis sie unumgänglich ist – außerdem macht das Unternehmen, bei dem die Individuallösung im Einsatz ist, auch nicht jeden Plattformwechsel mit. Deshalb muss bei einem Migrationsprojekt oft ein Sprung über drei oder vier Zwischenversionen geschafft werden – und da kann es schon eine Menge von wesentlichen und überraschenden Unterschieden in den genutzten Schnittstellen geben.
Wie soll man in einer solchen Situation vorgehen, und vor allem, wie viel Zeit und Ressourcen muss man einplanen?
Migrationen sind zunächst ganz normale Softwareprojekte, und wie bei diesen gibt es paradigmatisch auch hier zwei Vorgehensmodellen: Phasenmodelle und agile Vorgehensweisen. In einem phasenorientierten Vorgehensmodell wird man zunächst den Migrationsbedarf als funktionale Anforderungsmenge analysieren und spezifizeren, dann ein Umsetzungskonzept entwickeln und schließlich die Migration als Neuimpementierung von Funktionalität umsetzen.
Gerade bei Migrationen ist allerdings der Anteil der Unbekannten Anforderungen besonders groß. Migrationen sind Entdeckungsreisen in die unbekannte Welt der neuen Plattform – und selbst, wenn man Experten für die neue Welt als Lotsen an Bord hat, weiß man nicht, wie das alte Schiff in den neuen Fahrwassern wirklich reagieren wird, welche Schwachstellen in der „Neuen Welt“ erst zum Tragen kommen, die man zuvor gar nicht bemerken konnte.
Deshalb bieten sich gerade bei Migrationen agile Vorgehensmodellen an. Kurz gesagt: Man startet mit einem Experiment und schaut, was passiert. Man wagt die ersten vorsichtigen Schritte und beobachtet, wie System und Kontext reagieren. Man löst die auftretenden Probleme und geht den nächsten Schritt – so lange, bis das System in de Ziel-Umgebung stabil läuft.
Agile Projekte dieser Art haben den Nachteil, dass man zu Beginn nicht weiß, wie lange sie dauern und wie aufwändig sie sind – aber paradoxerweise sind sie preiswerter und effizienter als das phasenorientierte Vorgehen, bei dem man zwar immer eine plausible Aufwands- und Kostenschätzung hat – die aber leider nie stimmt, weil man die Überraschungen, die unweigerlich auftreten, nicht einkalkulieren kann.
Natürlich liegt in der wirklichen Projektwelt – wie immer – die Wahrheit in der Mitte. Eine Analyse der entscheidenden Plattform-Differenzenen mit Relevanz-Betrachtung und Risikobewertung soll und kann immer am Anfang stehen und eine intensive Beschäftigung mit den Möglichkeiten und konzeptionellen Neuigkeiten des Zielsystems ist ebenfalls sinnvoll.
In jedem Fall sollte zu Beginn des Migrations-Projektes die Erstellung eines detaillierten Testkonzeptes stehen. Nirgends ist der Einsatz eines Testfall-getriebenen Entwicklungsansatzes so sinnvoll wie bei Migrationen. Die Testfälle sollten hier als White-Box-Tests geplant werden, da der Code der Individual-Anwendung ja bekannt ist. Die Codeabdeckung der Testfälle sollte Risiko-abhängig vorab festgelegt werden.