Fast jedes mittelständische Unternehmen hat sie: eine geschäftskritische Anwendung, die seit Jahren läuft, viele Anpassungen erlebt hat und an deren Codebasis sich heute niemand mehr so recht herantraut. Sie funktioniert – aber jede Änderung wird zur Geduldsprobe, jeder neue Mitarbeitende braucht Wochen, um sich einzuarbeiten, und immer öfter klingen die Antworten der IT mit "das geht so nicht mehr". Die Frage steht im Raum: Refactoring oder komplett neu entwickeln? Eine der schwierigsten Entscheidungen im Software-Lebenszyklus – und eine, bei der falsche Antworten teuer werden. In diesem Artikel zeigen wir die Kriterien, die in der Praxis wirklich entscheiden.
Was die beiden Optionen wirklich bedeuten
Bevor wir vergleichen, müssen die Begriffe klar sein. Sie werden in der Praxis oft unscharf verwendet, was Entscheidungen verzerrt.
Refactoring
Bestehender Code wird verbessert, ohne die Funktionalität zu ändern. Lesbarkeit, Wartbarkeit, Performance werden besser. Die Anwendung selbst bleibt dieselbe. Kein neues Lastenheft nötig.
Modernisierung
Mehr als Refactoring: Veraltete Technologien werden ausgetauscht (z.B. PHP 5 auf PHP 8), Architektur wird angepasst, Schnittstellen werden saniert. Funktionalität bleibt, Substanz wird erneuert.
Reengineering
Anforderungen werden neu analysiert, Architektur grundlegend neu konzipiert, Code wird teilweise neu geschrieben. Bestehende Funktionalität wird übernommen, aber strukturell neu gebaut.
Neuentwicklung
Komplett neue Anwendung, oft mit neuem Stack, neuer Architektur, neuem Datenmodell. Bestehende Anwendung läuft parallel weiter, bis Migration abgeschlossen ist.
Diese vier Optionen sind ein Spektrum, kein Schalter. In der Praxis sind die meisten Modernisierungs-Projekte eine Mischung – z.B. Refactoring im Frontend, Neuentwicklung der Datenschicht, Reengineering der Schnittstellen.
Die zentrale Frage: Was ist das Problem wirklich?
Bevor Sie über die Lösung sprechen, müssen Sie das Problem präzise benennen. Wir hören in Beratungen oft "die Anwendung muss neu gemacht werden" – und stellen dann fest, dass das eigentliche Problem ein anderes ist:
| Schmerz | Mögliche Ursache | Empfehlung |
|---|---|---|
| Anwendung ist langsam | Datenbank-Indizes fehlen, Caching nicht eingerichtet | Refactoring, kein Neuanfang nötig |
| Änderungen dauern ewig | Code ist schlecht strukturiert, keine Tests | Refactoring + Testabdeckung |
| Browser funktioniert nicht | Frontend basiert auf veralteter Technologie | Frontend-Modernisierung, Backend bleibt |
| Neue Anwendungsfälle gehen nicht | Architektur ist Sackgasse | Reengineering oder Neuentwicklung |
| Betriebssystem nicht mehr unterstützt | Plattform veraltet | Modernisierung des Tech-Stacks |
| Kein Entwickler kennt mehr die Technologie | Personalbasis weg | Schrittweise Migration auf zeitgemäßen Stack |
| UI ist nicht mehr akzeptabel | Frontend ist alt | Frontend-Refactoring (oft als isoliertes Projekt möglich) |
| Prozess soll grundlegend anders sein | Geschäftsmodell ändert sich | Neuentwicklung sinnvoll |
Wer nicht weiß, was das eigentliche Problem ist, entscheidet falsch. Erst diagnostizieren, dann therapieren. Ein zweitägiger Audit der bestehenden Anwendung spart oft monatelange Fehlinvestitionen.
Pro und Contra: Refactoring
Refactoring (im weiteren Sinne, also inkl. Modernisierung) ist die häufiger gewählte und meist günstigere Option:
| Vorteile | Nachteile |
|---|---|
| Bestehende Geschäftslogik bleibt unverändert | Wenn Architektur grundlegend falsch ist, hilft Refactoring nicht |
| Kein Parallel-Betrieb nötig | Risiko, in Altlasten zu investieren statt in Neues |
| Niedrigere Initialkosten | Code-Schichten können sehr verwoben sein, Refactoring komplex |
| Wissen im Team bleibt erhalten | Begrenzt, wenn Technologie nicht mehr unterstützt wird |
| In kleinen Schritten möglich | Endlosproblem, wenn nicht systematisch geplant |
| Messbare Verbesserungen Schritt für Schritt | Schwer zu kommunizieren – "wir refactoren" verkauft sich schlecht |
Pro und Contra: Neuentwicklung
| Vorteile | Nachteile |
|---|---|
| Saubere Architektur von Anfang an | Hohe Initialkosten |
| Aktuelle Technologien einsetzbar | Lange Time-to-Market (Monate bis Jahre) |
| Geschäftslogik kann hinterfragt und verbessert werden | Risiko des "Second System Effect" (Überfrachtung mit Features) |
| Klare Trennung von Alt und Neu | Wissen aus der alten Anwendung muss übertragen werden |
| Bessere Wartbarkeit langfristig | Parallel-Betrieb teuer und komplex |
| Motivierender für Entwickler | Migration der Daten meist unterschätzt |
⚠️ Wichtig: Das größte Risiko bei Neuentwicklungen: Sie unterschätzen den Umfang, was die alte Anwendung tatsächlich kann. Über Jahre angesammelte Sonderfälle, Geschäftsregeln und Workarounds sind nirgendwo dokumentiert und müssen mühsam aus dem Code extrahiert werden.
Die 7 Entscheidungs-Kriterien
Welcher Weg der richtige ist, hängt von einer Reihe ehrlich beantworteter Fragen ab:
Wie alt ist der Tech-Stack?
PHP 5 ist nicht mehr unterstützt, jQuery 1 ist Geschichte, alte Frameworks ohne Updates sind Sicherheitsrisiko. Wenn die Plattform tot ist, hilft Refactoring nicht mehr.
Gibt es noch Entwickler, die das können?
Wenn Sie niemanden mehr finden, der die Technologie kennt, wird jede Änderung exponentiell teuer. Das ist ein klares Signal für Modernisierung.
Ist die Architektur eine Sackgasse?
Wenn neue Anforderungen grundlegend andere Strukturen brauchen (z.B. Multi-Tenancy in einem Single-Tenant-System), ist Refactoring oft nicht ausreichend.
Wie hoch ist die Test-Abdeckung?
Ohne automatisierte Tests ist jedes Refactoring Roulette. Mit guter Test-Abdeckung wird Refactoring sicher und schnell.
Wie tief sind die Schnittstellen?
Wenn die Anwendung tief mit anderen Systemen verzahnt ist, ist eine Neuentwicklung ein Großprojekt – jede Schnittstelle muss mit migriert werden.
Wie kritisch ist Continuity?
Bei geschäftskritischen Anwendungen ist Big-Bang-Migration riskant. Schrittweise Modernisierung ist oft die einzige praktikable Option.
Wie groß ist der Funktions-Drift?
Wenn die neue Anwendung 80 % gleich wie die alte sein soll, ist Refactoring oft sinnvoller. Wenn 80 % neu, ist Neuentwicklung sinnvoll.
Der Strangler-Fig-Ansatz: Modernisierung im laufenden Betrieb
In den meisten Fällen ist weder reines Refactoring noch komplette Neuentwicklung optimal. Ein bewährter Mittelweg ist das Strangler-Fig-Pattern: Die neue Anwendung wächst stückweise um die alte herum, übernimmt Schritt für Schritt einzelne Funktionalitäten, bis die alte Anwendung am Ende komplett ersetzt ist.
Vorteil 1: Risiko stark reduziert
Wenn ein neuer Teil nicht funktioniert, läuft die alte Anwendung weiter. Rollback ist immer möglich.
Vorteil 2: Wert von Anfang an
Erste neue Funktionalitäten gehen in Wochen statt Jahren live. Stakeholder sehen Fortschritt.
Vorteil 3: Lernen im Verlauf
Frühe Module zeigen, was im neuen Stack funktioniert. Spätere Module profitieren von diesen Erfahrungen.
Vorteil 4: Verteilte Kosten
Kein riesiges Initial-Budget nötig. Investitionen verteilen sich auf 1-3 Jahre.
Vorteil 5: Keine Big-Bang-Migration
Daten und Anwender wandern stückweise mit, weniger Stress am Tag X.
Ein neuer Service übernimmt zuerst eine klar abgegrenzte Funktionalität (z.B. einen Report). Der bestehende Code wird so angepasst, dass er für diese Funktionalität den neuen Service aufruft. Funktioniert das, wandert der nächste Bereich. Schritt für Schritt schrumpft die alte Anwendung – am Ende bleibt nichts mehr von ihr übrig.
Kostenrahmen: Was kosten welche Optionen?
Konkrete Zahlen sind immer abhängig vom Einzelfall – aber als Orientierung für mittelständische Anwendungen:
| Option | Typische Kosten | Dauer | Risiko |
|---|---|---|---|
| Reines Refactoring | 20-40 % der Erstellungskosten | 2-6 Monate | Niedrig |
| Modernisierung Tech-Stack | 40-70 % | 4-9 Monate | Mittel |
| Reengineering | 60-100 % | 9-18 Monate | Mittel-hoch |
| Neuentwicklung (Big Bang) | 100-200 % | 12-36 Monate | Hoch |
| Strangler-Fig (verteilt) | 100-160 % über 2-3 Jahre | 24-36 Monate | Niedrig-mittel |
Eine Faustregel aus der Praxis: Wenn die Neuentwicklung mehr als das Doppelte der Refactoring-Kosten kostet, ist Refactoring fast immer die bessere Wahl – außer es gibt klare strategische Gründe für einen Neuanfang.
Wann eine Neuentwicklung wirklich nötig ist
Trotz aller Argumente für Refactoring gibt es Situationen, in denen Neuentwicklung der richtige Weg ist:
- Die Geschäftsanforderungen haben sich fundamental geändert – die alte Anwendung passt nicht mehr
- Der Tech-Stack ist tot (keine Updates, keine Entwickler, Sicherheitslücken)
- Die Architektur ist eine Sackgasse, die durch Refactoring nicht mehr fixbar ist
- Die alte Codebasis ist so verworren, dass selbst kleine Änderungen Wochen dauern
- Die alte Anwendung hatte nie eine durchdachte Architektur – ein Neuanfang ist günstiger als Restrukturierung
- Compliance-Anforderungen erzwingen einen Neuanfang (DSGVO, branchenspezifische Standards)
- Die Daten sollen in einer komplett anderen Form gehalten werden
Was vor jeder Entscheidung passieren muss
Diagnose vor Entscheidung
- Code-Audit der bestehenden Anwendung (Architektur, Qualität, Testabdeckung)
- Interviews mit Anwendern (was funktioniert, was bremst, was fehlt)
- Anforderungs-Vergleich (was kann die Anwendung heute, was soll sie können?)
- Stakeholder-Mapping (wer entscheidet, wer ist betroffen, wer zahlt?)
- Datenstand-Analyse (Konsistenz, Migration, Sonderfälle)
- Schnittstellen-Inventar (was hängt dran?)
- Budget- und Zeitrahmen aus Geschäftsführungssicht
- Risiko-Profil (was passiert, wenn die Anwendung 1 Tag steht?)
5 typische Fehler bei Modernisierungs-Projekten
Big-Bang ohne Notwendigkeit
Komplette Neuentwicklung wo schrittweise Modernisierung gereicht hätte. Resultat: hohe Kosten, lange Time-to-Value, oft Projekt-Abbruch.
Alte Anforderungen blind übernommen
Die neue Anwendung soll genau das tun, was die alte tat – inklusive aller historischen Sonderfälle. Resultat: keine echte Verbesserung, gleicher Tech-Schulden-Berg.
Kein Audit zu Beginn
Direkt mit der Lösung loslegen, ohne das Problem zu verstehen. Resultat: Mitte des Projekts wird klar, dass die Strategie falsch war.
Kein Plan für Daten-Migration
Daten kommen erst am Ende. Resultat: Migration scheitert, Go-Live verschoben, Stakeholder verärgert.
Entwickler-getriebene Entscheidung
Entwickler wollen neuen Stack, weil aufregender. Aber: Strategische Entscheidung gehört in die Geschäftsführung, nicht in den Bauchladen.
Fazit: Modernisieren ist eine Investition, kein Reflex
Software zu modernisieren ist eines der heikelsten Themen im IT-Lebenszyklus. Refactoring ist meist günstiger und sicherer als Neuentwicklung – aber nicht in jedem Fall die richtige Wahl. Wer das eigentliche Problem präzise diagnostiziert, kennt die Antwort meist schon. Wer aus Frustration handelt, riskiert Millioneninvestitionen ohne erkennbaren Mehrwert.
Wenn Sie vor der Entscheidung stehen, eine bestehende Anwendung zu modernisieren oder neu zu entwickeln, helfen wir Ihnen mit einem ehrlichen Audit – inklusive Code-Review, Anforderungs-Abgleich und Empfehlung für den richtigen Weg. Wir entwickeln auch die Lösung selbst – aber erst, nachdem die Strategie steht.