Irgendwann kommt in jedem gewachsenen System der Satz: „Das können wir nicht mehr anfassen.“ Kurz darauf folgt der Vorschlag, es neu zu bauen — sauber diesmal, mit aktueller Technik, ohne die Altlasten. Das klingt vernünftig und ist in den meisten Fällen die teuerste und riskanteste Option, die zur Verfügung steht.
Wir übernehmen regelmäßig gewachsene Python- und Django-Systeme und stehen dann vor genau dieser Entscheidung. Dieser Artikel beschreibt, wie wir Altsysteme bewerten, warum der große Neubau so oft scheitert, wie schrittweise Modernisierung praktisch abläuft — und die Fälle, in denen ein Neubau tatsächlich die richtige Antwort ist.
Warum der große Neubau scheitert
Das Grundproblem ist nicht technisch, sondern zeitlich. Ein Neubau braucht ein bis drei Jahre. In dieser Zeit passiert Folgendes:
- Das Altsystem steht nicht still. Es kommen Anforderungen, Gesetzesänderungen, Fehlerbehebungen. Ihr entwickelt zwei Systeme parallel und bezahlt beides.
- Niemand kennt den vollen Funktionsumfang. In fünfzehn Jahren Betrieb sind hunderte Sonderfälle eingebaut worden, die nirgends dokumentiert sind. Sie fallen einzeln auf — nach dem Umstieg.
- Es gibt jahrelang keinen Nutzen. Bis zur Umstellung fließt Geld ab, ohne dass jemand etwas davon hat. Das überlebt selten zwei Budgetrunden und drei Prioritätenwechsel.
- Der Umstieg ist ein Ereignis. Ein Stichtag, an dem alles gleichzeitig funktionieren muss. Geht etwas schief, gibt es keinen Rückweg, weil das Altsystem inzwischen abgeschaltet ist.
Die unbequeme Beobachtung: Systeme, die als „nicht mehr wartbar“ gelten, sind meist nicht unwartbar, sondern unverstanden. Der Unterschied ist entscheidend, weil Verstehen deutlich billiger ist als Neubauen.
Zuerst bewerten, dann entscheiden
Bevor wir eine Empfehlung abgeben, sehen wir uns fünf Dinge an. Das dauert ein bis zwei Wochen und ist jedes Mal gut investiert.
| Was wir prüfen | Warum es entscheidet |
|---|---|
| Testabdeckung | Ohne Tests ist jede Änderung ein Risiko. Das ist fast immer der erste Arbeitsschritt, egal wie es weitergeht. |
| Datenmodell | Ein tragfähiges Datenmodell rettet fast jedes System. Ein kaputtes ist das stärkste Argument für einen Neubau. |
| Abhängigkeiten | Wie viele Fremdpakete, wie alt, welche davon nicht mehr gepflegt. Hier steckt der Aufwand von Versionssprüngen. |
| Deployment | Lässt sich das System reproduzierbar aufsetzen? Wenn das Wissen nur in einem Kopf existiert, ist das die dringendste Baustelle. |
| Änderungshäufigkeit | Welche Teile werden laut Git-Historie tatsächlich angefasst? Meist sind es 10–20 Prozent. Nur die müssen modernisiert werden. |
Der letzte Punkt ist der wirkungsvollste und wird fast immer übersehen. Große Teile jedes Altsystems werden seit Jahren nicht mehr geändert — sie laufen einfach. Alter Code, der stabil läuft und niemanden stört, ist kein Problem, sondern ein gelöstes Problem. Ihn im Rahmen einer Modernisierung anzufassen, erzeugt Risiko ohne Gegenwert.
Schrittweise Modernisierung in der Praxis
Das bewährte Muster heißt Strangler Fig: Man baut das Neue um das Alte herum und leitet nach und nach Funktionen um, statt einen Stichtag zu setzen.
1. Sicherheitsnetz einziehen
Tests für die kritischen Abläufe, auch wenn sie grob sind. Ein Test, der einen Geschäftsvorgang von Anfang bis Ende prüft, ist mehr wert als fünfzig Unit-Tests für Hilfsfunktionen.
2. Reproduzierbar aufsetzbar machen
Docker, dokumentiertes Setup, CI-Pipeline. Solange nur eine Person das System zum Laufen bringt, ist jede Änderung ein Personenrisiko.
3. Eine Fassade davor
Alle Zugriffe laufen über eine Schicht, die entscheidet, ob eine Anfrage ans Alt- oder ans Neusystem geht. Meist ein Reverse Proxy, manchmal eine dünne API.
4. Den ersten Bereich herausschneiden
Ein fachlich abgegrenztes Stück, das oft geändert wird und wenig mit dem Rest verflochten ist. Neu bauen, umleiten, beobachten. Nach vier bis acht Wochen gibt es einen sichtbaren Erfolg.
5. Wiederholen — und rechtzeitig aufhören
Bereich für Bereich, nach Änderungshäufigkeit priorisiert. Wichtig: Es gibt keine Pflicht, bei 100 Prozent zu enden. Wenn der Rest stabil läuft und niemanden stört, darf er bleiben.
Der große Vorteil: Nach jedem Schritt habt ihr ein funktionierendes System und einen messbaren Fortschritt. Das Projekt kann jederzeit pausiert werden, ohne dass Investitionen verloren gehen — bei einem Neubau ist das nicht der Fall.
Wann ein Neubau doch richtig ist
Es gibt Fälle, in denen schrittweise Modernisierung nicht funktioniert:
Datenmodell am Ende
Neubau
Wenn die Datenstruktur die Fachlichkeit grundsätzlich falsch abbildet, vererbt jede Modernisierung den Fehler weiter
Technologie ohne Zukunft
Neubau
Plattform abgekündigt, keine Sicherheitsaktualisierungen mehr, niemand am Markt beherrscht sie noch
Fachlichkeit ändert sich
Neubau
Wenn das Geschäft heute ein anderes ist, ist die alte Software die richtige Lösung für ein Problem, das ihr nicht mehr habt
Selbst dann gilt: nicht alles auf einmal. Auch ein Neubau kann bereichsweise erfolgen, mit einem alten und einem neuen System im Parallelbetrieb. Der Stichtag ist das Risiko, nicht der Neubau selbst.
Der Sonderfall Excel
Ein eigener Fall, weil er so häufig ist: gewachsene Excel-Landschaften, oft mit Makros, die einen geschäftskritischen Prozess tragen. Die Reflexe sind hier meist falsch.
Excel abzulösen ist selten ein Softwareprojekt, sondern zuerst eine Erhebung. Bevor irgendetwas gebaut wird, muss klar sein: Wer bearbeitet welche Datei, in welcher Reihenfolge, was passiert bei Fehlern, und welche der dreißig Tabellenblätter werden tatsächlich benutzt. Erfahrungsgemäß tragen zwei bis drei Blätter den ganzen Prozess, der Rest ist Historie.
Und ein Hinweis, der oft überrascht: Nicht jedes Excel gehört abgelöst. Wenn drei Personen einmal im Monat eine Tabelle pflegen und das seit Jahren gut funktioniert, ist eine Webanwendung dafür Verschwendung. Der Handlungsdruck entsteht durch Mehrbenutzerzugriff, Nachvollziehbarkeit und Fehleranfälligkeit — nicht durch das Dateiformat.
Was das kostet
Grobe Orientierung aus unseren Projekten:
| Maßnahme | Aufwand | Wirkung |
|---|---|---|
| Assessment | 1–2 Wochen | Entscheidungsgrundlage statt Bauchgefühl |
| Tests für kritische Abläufe | 2–6 Wochen | Voraussetzung für alles Weitere |
| Reproduzierbares Setup und CI | 1–3 Wochen | Beseitigt das Personenrisiko |
| Versionssprünge nachziehen | 2–8 Wochen | Sicherheitslage, wieder wartbar |
| Erster Bereich herausgelöst | 4–8 Wochen | Sichtbarer Erfolg, Muster für den Rest |
| Vollständiger Neubau | 12–36 Monate | Hohes Risiko, lange ohne Nutzen |
Die ersten vier Zeilen zusammen kosten meist weniger als drei Monate — und lösen erfahrungsgemäß den größten Teil des Schmerzes, der ursprünglich zur Neubau-Idee geführt hat. Es lohnt sich, diese Reihenfolge einzuhalten, bevor eine Grundsatzentscheidung fällt.
Altsystem bewerten lassen
Wir übernehmen gewachsene Python- und Django-Systeme und sagen ehrlich, was Arbeit braucht und was in Ruhe gelassen gehört. Mehr dazu auf unserer Seite zur Python Entwicklung.
Erstgespräch vereinbaren →Fazit
Der Impuls, ein altes System komplett neu zu bauen, ist verständlich und meistens falsch. Er entsteht aus Frustration über etwas, das niemand mehr versteht — und Verstehen ist deutlich billiger als Neubauen.
Der pragmatische Weg beginnt fast immer gleich: Tests für das Wichtigste, reproduzierbares Setup, aktuelle Versionen. Danach schrittweise die Bereiche herauslösen, die tatsächlich oft geändert werden — und den Rest in Ruhe lassen. Das ist unspektakulär, liefert nach wenigen Wochen sichtbare Ergebnisse und lässt sich jederzeit anhalten.
Ein Neubau bleibt die richtige Antwort, wenn das Datenmodell die Fachlichkeit falsch abbildet oder die Plattform keine Zukunft hat. Aber diese Entscheidung sollte am Ende eines Assessments stehen — nicht am Anfang eines Frustgesprächs.