Wie lange dauert eine Software-Modernisierung wirklich?

"Das schaffen wir in vier Wochen." Das hört man oft von Dienstleistern. Manchmal stimmt es. Meistens nicht. Denn die software modernisierung dauer hängt von Faktoren ab, die ein erster Blick nicht zeigt. Dieser Artikel erklärt ehrlich, was den Zeitplan wirklich bestimmt.

Warum Zeitschätzungen so oft falsch liegen

Der häufigste Fehler: Eine Schätzung wird abgegeben, bevor der Code analysiert wurde. "Vier Wochen" klingt gut im Angebot. Es entsteht aber aus dem Bauch, nicht aus dem Befund.

Eine Software-Modernisierung ist wie eine Gebäuderenovierung. Wer von außen auf ein Haus schaut, sieht die Fassade. Was hinter den Wänden steckt, weiß man erst wenn man aufmacht.

Wir geben keine verbindliche Zeitschätzung, bevor wir den Code gesehen haben. Das klingt unbequem. Es ist aber das Einzige, was fair ist.

Was die Dauer einer Modernisierung wirklich bestimmt

Fünf Faktoren prägen den Zeitrahmen mehr als alles andere.

1. Alter und Qualität der Codebasis

Ein PHP-Projekt aus 2008, das über zehn Jahre von wechselnden Entwicklern bearbeitet wurde, hat andere Voraussetzungen als eine sauber strukturierte Anwendung aus 2018.

Alter allein sagt noch wenig. Aber Alter plus fehlende Struktur plus viele Sonderlösungen: Das macht Modernisierung aufwändig.

Typische Zeichen für schwierige Codebasen: keine einheitliche Architektur, viel Copy-Paste-Code, Datenbankabfragen direkt im HTML-Template, undokumentierte Sonderfälle. Jedes dieser Merkmale kostet extra Zeit.

2. Dokumentation

Dokumentation fehlt bei Legacy-Systemen fast immer. Das vervielfacht den Aufwand.

Ohne Dokumentation muss jeder Schritt zuerst verstanden werden. Was macht diese Funktion? Warum gibt es diese Ausnahme? Was passiert, wenn dieser Wert leer ist?

Das kostet Zeit. Nicht weil die Entwickler langsam sind, sondern weil niemand schummeln kann. Man muss wissen, was man anfasst, bevor man es ändert.

Ein System mit guter Dokumentation kann in der Hälfte der Zeit modernisiert werden. Das ist keine Übertreibung.

3. Testabdeckung

Tests ermöglichen sicheres Arbeiten. Wenn ich Code ändere und danach die Tests grün sind, weiß ich: Die wichtigen Funktionen laufen noch.

Fehlen Tests, muss jede Änderung manuell überprüft werden. Das bremst erheblich. Und es erhöht das Risiko, dass etwas übersehen wird.

Bei vielen Legacy-Projekten gibt es keine automatisierten Tests. Dann wird das Schreiben von Tests Teil der Modernisierung. Das ist sinnvoll. Aber es verlängert den Zeitrahmen.

4. Umfang der Modernisierung

Es macht einen großen Unterschied, ob man:

• nur eine PHP-Version anhebt (Update),
• veraltete Bibliotheken ersetzt (Refactoring),
• die Architektur grundlegend überarbeitet (Restrukturierung),
• oder die Software Schritt für Schritt durch eine neue ersetzt (Migration).

Diese vier Szenarien können sich im Aufwand um den Faktor 10 unterscheiden. Wer "Modernisierung" sagt, meint oft sehr verschiedene Dinge. Mehr dazu, wann welcher Ansatz sinnvoll ist, lesen Sie im Artikel zu Software modernisieren oder neu entwickeln.

5. Verfügbarkeit interner Ansprechpartner

Ein oft unterschätzter Faktor: Wie schnell beantwortet das Unternehmen Rückfragen?

Während einer Modernisierung entstehen viele fachliche Fragen. Was ist der korrekte Ablauf bei diesem Sonderfall? Welche Kunden nutzen welche Funktion? Was darf sich ändern, was nicht?

Wenn Rückfragen zwei Wochen auf Antwort warten, verzögert sich das Projekt um zwei Wochen. Das liegt nicht am Dienstleister. Es liegt an der verfügbaren Kapazität beim Kunden.

Realistische Zeitrahmen für typische Szenarien

Die folgenden Angaben sind Richtwerte. Jedes System ist anders. Aber sie geben eine Orientierung.

PHP-Upgrade (z.B. von 7.4 auf 8.2), kleines gut strukturiertes System: 3 bis 10 Tage. Wenige Abhängigkeiten, vorhandene Tests: schnell machbar.

PHP-Upgrade, gewachsenes System ohne Tests: 2 bis 6 Wochen. Analyse, Kompatibilitätscheck, manuelle Tests, Fehlerbehebung. Das braucht Zeit.

Modernisierung einer individuell entwickelten Webanwendung: 2 bis 6 Monate. Je nach Umfang, je nach Dokumentation, je nach Teamgröße.

Komplette Migration einer komplexen Legacy-Plattform: 6 bis 18 Monate. Manchmal auch länger. Solche Projekte brauchen einen klaren Plan und ein erfahrenes Team.

Bei technischen Schulden, die sich über viele Jahre angesammelt haben, ist der erste Schritt fast immer die gründliche Analyse. Erst danach kann eine seriöse Schätzung gegeben werden.

Warum Schätzungen trotzdem oft zu optimistisch sind

Selbst erfahrene Teams unterschätzen den Aufwand. Das hat Gründe.

Überraschungen im Code sind die Regel, nicht die Ausnahme. Veraltete Abhängigkeiten, die niemand kannte. Undokumentierte Sonderfälle, die in der Produktion plötzlich auftauchen. Drittsysteme, die nicht dokumentiert sind, aber doch angebunden sein müssen.

Dazu kommt die Koordination. Abstimmungen, Freigaben, Testzyklen mit echten Nutzern: All das kostet Zeit, die in Erstschätzungen selten vorkommt.

Wer einen Zeitplan ohne Puffer präsentiert, präsentiert einen Plan, der mit hoher Wahrscheinlichkeit nicht eingehalten wird. Wir empfehlen: mindestens 20 bis 30 Prozent Puffer für unerwartete Befunde. Bei schlecht dokumentierten Systemen deutlich mehr.

Was Sie als Auftraggeber tun können

Drei Dinge beschleunigen den Prozess auf Ihrer Seite.

Interne Ansprechpartner benennen. Jemand muss fachliche Fragen beantworten können. Nicht irgendwann, sondern innerhalb von 24 Stunden.

Vorhandenes Wissen sichern. Gibt es ehemalige Entwickler, die noch erreichbar sind? Gibt es interne Handbücher? Alte Ticketsysteme? Das alles kann wertvolle Zeit sparen.

Realistische Erwartungen setzen. Eine Modernisierung ist kein Sprint. Es ist ein strukturierter Prozess. Wer einen Monat plant und sechs braucht, hat ein Problem. Wer von Anfang an realistisch plant, hat die Kontrolle.

Wie ein ehrliches Vorgehen aussieht

Bevor ein Zeitplan steht, steht die Analyse. Das bedeutet: Wir lesen den Code. Wir prüfen die Abhängigkeiten. Wir verstehen, was das System tut und was nicht dokumentiert ist.

Dann gibt es eine ehrliche Einschätzung: mit realistischen Zeiträumen, mit klaren Risiken, mit einem Puffer der kein Wunschdenken ist.

Das ist die Grundlage für die Software-Wartung, die wir anbieten. Kein Versprechen ins Blaue. Kein Festpreis auf Basis eines Fotos der Fassade.

Fazit: software modernisierung dauer ist planbar, aber nicht rätbar

Eine Zahl ohne Analyse ist keine Schätzung. Es ist eine Spekulation.

Wer wissen will, wie lange seine Software-Modernisierung dauert, braucht zunächst eine ehrliche Bestandsaufnahme. Die meisten Überraschungen lassen sich durch sorgfältige Analyse vorab entschärfen. Nicht alle, aber die meisten.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihr System an und sagen Ihnen, womit Sie wirklich rechnen müssen.