Die Zeit vergeht und die Betriebskosten der Altsysteme steigen. Eines Tages kommt eine Mitteilung, dass der Support für die Software ausläuft und nur noch ein „Extended Support“ erworben werden kann – die Kosten steigen weiter. Was tun?
Auf den ersten Blick scheint die Antwort einfach: Die Software muss abgelöst werden. Eine Neuentwicklung würde sich jedoch erst in einigen Jahren amortisieren, gleichzeitig steigen der Kostendruck und der Wunsch nach einer ausgeglichenen Bilanz. In der Konsequenz schrecken viele Manager vor der Umstellung auf eine zeitgemäße Plattform zurück. Auch, wenn mehr als nur ein gutes Argument gegen Legacy-Systeme spricht.
Vom Stolperstein zum Steinhaufen
Was bleibt, sind horrende Kosten und die Notwendigkeit, einen kostengünstigen Ersatz für die Alt-Anwendung zu finden.
Ein Manager stellt eine Aufwandsschätzung für die Neuentwicklung der besagten Alt-Anwendung auf. Er plant, die Kosten durch ein Outsourcing des Projektes nach Indien möglichst niedrig zu halten. Während der Projektplan besprochen wird, fällt der Einwand, dass ein „Code Freeze“ von sechs Monaten nötig ist, um die Funktionalität der Alt-Anwendung abzubilden. Die Anwendung wird jedoch aufgrund rechtlicher und kundenspezifischer Anforderungen stetig weiterentwickelt, ein weiterer Stolperstein. Zusätzlich wird dem (mittlerweile zu bemitleidenden) Manager bewusst, dass es keine umfassende Dokumentation zur Alt-Anwendung gibt. Ebenfalls eine – vorsichtig gesagt – nicht optimale Ausgangslage.
Diese Geschichte ist keine reine Fiktion, sondern eine alltägliche Herausforderung in der IT von Betrieben weltweit. Haben Sie sich gerade bei dem Gedanken „Das kenne ich doch!“ erwischt? Dann habe ich eine gute Nachricht für Sie: Die Lösung Ihres Problems könnte eine automatisierte Migration sein.
Vom Steinhaufen zum Kieselstein
„Code Freeze“, Kosten, Zeitaufwand, lückenhafte Dokumentationen – bei einer automatisierten Migration sind dies alles keine „echten“ Stolpersteine. Natürlich ist es von Vorteil, eine Dokumentation zu haben, eine rein technische Migration ist jedoch nicht darauf angewiesen. Der angesprochene „Code Freeze“ muss nicht stattfinden. Eventuell fragen Sie sich jetzt, wie das funktionieren soll. Ganz einfach: Eine automatisierte Migration kann wiederholbar den aktuellen Stand des Source Codes herstellen – jederzeit und per Knopfdruck. Ein weiterer Pluspunkt – v.a. bei großem Codeumfang – ist die Fehlerbehandlung. Fehler, die im Zielcode gefunden werden, können anhand des Fehlermusters anwendungsweit behoben werden. Ein Vorgehen, das die Testphase bei großen Projekten immens verkürzt.
Ab welchem Umfang lohnt sich eine automatisierte Migration?
Die Frage, ab welchem Zeitpunkt eine automatisierte Migration die manuelle Implementierung von der reinen Kostenbasis her schlägt, kann nicht mit einer einfachen Formel beantwortet werden. In der Regel geht es jedoch nicht um Anwendungen mit fünf bis zehn Klassen, sondern eher um Anwendungen mit 100 bis 10.000 Klassen. Erst dann stehen Aufwand (vom Migrationsautomat benötigte Kalibrierungszeit) und Ergebnis in einem attraktiven Verhältnis. Sind die Regeln im Automaten einmal definiert, macht es wenig Unterschied, ob er 100, 1.000 oder 10.000 Klassen als Eingabe erhält. Lediglich die Testphase skaliert mit der Größe der Anwendung. Großer Vorteil einer automatisierten Migration – vor allem bei komplexen Anwendungen: Das fachliche Wissen bleibt vollständig erhalten. Mitarbeiter mit Know-how im Alt-Code werden sich auch in der neuen Anwendung schnell zurechtfinden.
Bildquelle: Shutterstock
