Es ist die erste Frage in fast jedem Erstgespräch, und es ist die ehrlichste: Was kostet das? Die unbefriedigende, aber wahre Antwort lautet: Das hängt davon ab. Nicht weil wir uns drücken wollen, sondern weil eine Migration kein Produkt mit Preisschild ist, sondern ein Projekt, dessen Aufwand sich aus dem Zustand Ihres Systems ergibt.
Was den Preis bestimmt, lässt sich aber sehr wohl benennen. Wer die Treiber kennt, kann eine Größenordnung abschätzen – und Angebote besser einordnen.
Warum es keinen Quadratmeterpreis gibt
Bei einer Renovierung kann man grob pro Quadratmeter rechnen. Bei Software funktioniert das nicht, weil zwei Anwendungen mit derselben Zeilenzahl völlig unterschiedlich teuer sein können. Tausend Zeilen sauberer, dokumentierter Code sind in einem Bruchteil der Zeit migriert, die tausend Zeilen verwobener, undokumentierter Logik mit versteckten Sonderfällen verschlingen.
Der Preis hängt also weniger an der Größe als am Zustand. Und der Zustand zeigt sich erst, wenn jemand in den Code schaut.
Die fünf Kostentreiber
1. Der Zustand der Codebasis. Sauber strukturierter Code mit klarer Trennung von Logik und Darstellung ist günstig zu migrieren. Code, in dem HTML, SQL und Geschäftslogik in denselben Dateien kleben – typisch für alte ASP- und PHP-Anwendungen –, muss erst entwirrt werden. Diese Entwirrung ist oft der größte einzelne Posten.
2. Dokumentation, oder ihr Fehlen. Existiert eine aktuelle Dokumentation, fällt das Verstehen leichter. Meist existiert sie nicht. Dann muss die Geschäftslogik aus dem Code selbst rekonstruiert werden – das, was wir „Logik freilegen“ nennen. Es ist die wertvollste und zugleich aufwendigste Arbeit.
3. Die Datenqualität. Über Jahre sammeln sich in jeder Datenbank Altlasten an: Dubletten, inkonsistente Formate, halb gepflegte Felder. Je unsauberer die Daten, desto mehr Aufwand steckt in der Migration und Bereinigung. Bei manchen Systemen – etwa altem PHP mit magic_quotes-verseuchten Beständen – ist das ein eigenes Teilprojekt.
4. Die Schnittstellen. Eine in sich geschlossene Anwendung ist einfacher als eine, die mit zehn anderen Systemen, Geräten oder Diensten spricht. Jede Schnittstelle muss verstanden, nachgebaut und getestet werden. Im Maschinenbau, wo Software direkt mit Anlagen kommuniziert, ist das besonders heikel.
5. Die Anforderungen ans Ziel. Soll die Anwendung eins zu eins nachgebaut werden, oder sollen gleich neue Funktionen dazukommen? Reicht ein moderner Desktop-Client, oder soll es ins Web gehen? Jede Erweiterung des Ziels erhöht den Aufwand – manchmal lohnend, manchmal besser auf später verschoben.
Warum die schrittweise Migration langfristig günstiger ist
Es klingt zunächst teurer, ein System Modul für Modul zu migrieren statt in einem großen Wurf. Tatsächlich ist der Big-Bang-Ansatz das teurere Risiko. Wenn am Stichtag etwas schiefgeht, steht der Betrieb – und Stillstand kostet pro Stunde oft mehr als die ganze Migration.
Bei der schrittweisen Migration laufen altes und neues System parallel. Jede Funktion wird einzeln übernommen und abgenommen, bevor die nächste folgt. Fehler zeigen sich klein und früh, nicht groß und zum schlechtesten Zeitpunkt. Das verteilt nicht nur das Risiko, sondern auch die Kosten – Sie zahlen in Etappen und sehen nach jeder Etappe ein Ergebnis.
Die versteckten Kosten des Nichtstuns
In jede Kostenrechnung gehört die andere Seite: Was kostet es, nicht zu migrieren? Diese Posten stehen in keinem Angebot, sind aber real.
Ein Altsystem wird mit jedem Jahr teurer im Unterhalt. Änderungen dauern länger, weil sich niemand mehr herantraut. Die wenigen Menschen, die es noch verstehen, sind teuer und unersetzlich – und irgendwann weg. Sicherheitslücken in alter Software bleiben offen und können im schlimmsten Fall einen Schaden verursachen, der die Migrationskosten um ein Vielfaches übersteigt. Und der Tag, an dem ein Betriebssystem-Update das System lahmlegt, kommt – nur sucht man sich den Zeitpunkt dann nicht aus.
Wer früh migriert, hat die Wahl. Wer wartet, zahlt am Ende oft mehr, unter schlechteren Bedingungen.
Wie man zu einer belastbaren Zahl kommt
Eine ehrliche Aufwandsschätzung gibt es erst, wenn jemand in den echten Code geschaut hat. Genau dafür gibt es das Code-Assessment: Wir prüfen Struktur, Datenmodell und Sicherheit, ordnen die fünf Kostentreiber für Ihr System konkret ein und nennen eine ehrliche Größenordnung – ohne Scheingenauigkeit, aber belastbar genug für eine Entscheidung.
Häufige Fragen
Können Sie nicht wenigstens eine grobe Hausnummer nennen? Erst nach einem Blick in den Code. Eine Hausnummer ohne diese Grundlage wäre geraten – und genau solche Schätzungen sprengen später das Budget.
Ist Neuentwicklung nicht oft günstiger als Migration? Manchmal. Aber Neuentwicklung verliert leicht die undokumentierte Geschäftslogik, die über Jahre gewachsen ist. Was günstiger ist, klärt sich erst, wenn man weiß, wie viel wertvolles Wissen im Altsystem steckt.
Wie zahlt man eine schrittweise Migration? In Etappen, passend zu den Migrationsschritten. Nach jeder Etappe steht ein abgenommenes Ergebnis. Das macht die Kosten planbar und das Projekt jederzeit stoppbar.
Dieser Beitrag ist ein allgemeiner Ratgeber und ersetzt keine individuelle Aufwandsschätzung.