Altsysteme modernisieren ohne Big-Bang-Rewrite

Viele mittelständische Unternehmen arbeiten mit Software, die zehn oder zwanzig Jahre alt ist: eine Access-Datenbank, die zum ERP geworden ist, eine PHP-Anwendung, die niemand mehr anzufassen wagt, ein Desktop-Programm, das nur auf einer bestimmten Windows-Version läuft. Sie erfüllt noch ihren Zweck, aber jede Änderung dauert Wochen, der ursprüngliche Entwickler ist nicht mehr da, und Sicherheitsupdates gibt es längst nicht mehr.

Die naheliegende Antwort ist eine komplette Neuentwicklung: das neue System neben dem alten bauen, an einem Wochenende umstellen, fertig. In der Praxis ist dieser „Big Bang“ eines der riskantesten Projekte, die ein Unternehmen beginnen kann. Dieser Artikel erklärt, warum, und wie Sie stattdessen Schritt für Schritt modernisieren.

Warum Big-Bang-Neuentwicklungen scheitern

• Das alte System weiß mehr, als alle denken. Jahrelang gewachsene Sonderfälle, Umgehungslösungen und Geschäftsregeln stecken im Code, nicht in einer Dokumentation. Eine Neuentwicklung muss sie alle wiederentdecken, meist indem sie sie zuerst falsch umsetzt.
• Lange wird nichts geliefert. Ein bis zwei Jahre zahlt das Unternehmen für ein neues System ohne Nutzen, während das alte weiter gewartet werden muss.
• Das Ziel bewegt sich. Das Geschäft verändert sich, während die Neuentwicklung läuft. Am Starttag ist das neue System schon wieder hinterher.
• Die Umstellung ist alles oder nichts. Hat das neue System am ersten Tag Probleme, hat alles am ersten Tag Probleme.

Die Alternative: in Scheiben modernisieren

Die Idee ist einfach: Das alte System wird Stück für Stück ersetzt, während es weiterläuft. Jeder Schritt bringt Nutzen und lässt sich zurückdrehen. Entwickler nennen das Strangler-Pattern, nach einer Würgefeige, die um einen Baum herumwächst, bis sie allein stehen kann.

Schritt 1: verstehen, was da ist

Bevor Sie etwas ändern, erfassen Sie das bestehende System:

• Welche Funktionen werden täglich, selten oder nie genutzt? Nutzungsdaten zeigen oft, dass ein Drittel der Funktionen einfach wegfallen kann.
• Wo liegen die Schmerzpunkte: langsame Abläufe, doppelte Erfassung, fehlende Schnittstellen, Sicherheitsrisiken?
• Welche Daten liegen wo, und wie sauber sind sie?
• Welche anderen Systeme hängen davon ab?

Ergebnis: eine Landkarte der Module, sortiert nach Geschäftswert und Risiko.

Schritt 2: eine API davorsetzen

Bauen Sie eine moderne Schnittstelle (API) zwischen dem alten System und allem anderen. Neue Anwendungen wie ein Kundenportal oder eine App sprechen nur mit dieser API, nie direkt mit der alten Datenbank. Hinter der API erledigt vorerst weiter das alte System die Arbeit.

Schon dieser Schritt bringt oft schnelle Erfolge: Ein Webportal oder eine App für den Außendienst kann innerhalb weniger Wochen live gehen, ohne den Kern anzufassen.

Schritt 3: Modul für Modul ersetzen

Wählen Sie das Modul mit dem besten Verhältnis von Nutzen zu Risiko und bauen Sie es hinter der API neu. Ist es fertig, leiten Sie die Anfragen für diese Funktion an das neue Modul. Der Rest läuft weiter auf dem alten System. Dann folgt das nächste Modul.

Gute erste Kandidaten sind Module, die sich häufig ändern, den meisten Supportaufwand verursachen oder neue Funktionen blockieren. Stabile, selten genutzte Teile kommen zuletzt oder werden abgeschaltet.

Schritt 4: Daten laufend migrieren

Bei der Datenmigration tut Modernisierung am meisten weh. Planen Sie keine große Migration am Ende. Stattdessen:

• Bereinigen Sie Daten vor dem Umzug: Dubletten, uneinheitliche Formate, verwaiste Datensätze.
• Synchronisieren Sie Daten für eine Übergangszeit zwischen alt und neu, damit beide Seiten konsistent bleiben.
• Migrieren und prüfen Sie Modul für Modul, mit automatischen Prüfungen, die Anzahlen und Summen vergleichen.

Schritt 5: das alte System abschalten

Ist das letzte wichtige Modul umgezogen, wird das alte System schreibgeschützt, dann zum Archiv und schließlich abgeschaltet. Archivierte Daten müssen so lange zugänglich bleiben, wie gesetzliche Aufbewahrungsfristen es verlangen, etwa für Rechnungen und Buchhaltungsunterlagen.

So sieht ein realistischer Fahrplan aus

Für eine typische mittelständische Geschäftsanwendung:

1. Analyse und Zielarchitektur: zwei bis vier Wochen. Ergebnis: Modul-Landkarte, Zielarchitektur, Fahrplan und Budget.
2. API-Schicht und erster schneller Erfolg: sechs bis zehn Wochen, zum Beispiel ein Portal oder eine App auf Basis des alten Systems.
3. Ablösung der Module: ein Modul alle zwei bis vier Monate, je nach Größe.
4. Abschaltung: sobald die Kernmodule ersetzt sind.

Jede Phase liefert etwas Nutzbares. Nach jedem Schritt können Sie pausieren, neu priorisieren oder die Richtung ändern.

Technologiewahl

Wählen Sie langweilige, bewährte Technologie mit langer Zukunft: ein typisiertes Backend (etwa TypeScript oder Python), eine relationale Datenbank wie PostgreSQL, ein Web-Frontend mit einem verbreiteten Framework und Cloud-Hosting in der EU oder auf eigenen Servern. Meiden Sie Nischentechnologien, die nur ein einziger Entwickler versteht – genau so wird aus dem modernen System von heute das Altsystem von morgen.

Typische Fehler

• Das alte System eins zu eins nachbauen. Nutzen Sie die Modernisierung, um Abläufe zu vereinfachen, statt jede Umgehungslösung neu zu bauen.
• Die Nutzer übergehen. Beziehen Sie die Menschen ein, die täglich mit dem System arbeiten. Sie wissen, wo die echten Probleme liegen.
• Keine Tests für das bisherige Verhalten. Schreiben Sie vor dem Ersetzen eines Moduls Tests, die beschreiben, was es heute tut. Sie schützen vor unbemerkten Änderungen an Geschäftsregeln.
• Datenqualität unterschätzen. Planen Sie Zeit für die Datenbereinigung ein. Sie dauert immer länger als gedacht.

Fazit

Schrittweise Modernisierung ist weniger spektakulär als eine Neuentwicklung, aber deutlich sicherer. Jede Scheibe bringt Nutzen, die Risiken bleiben klein, und das Geschäft muss nie stillstehen. Wir unterstützen mittelständische Unternehmen dabei, Altsysteme zu analysieren, die API-Schicht aufzubauen und Module nacheinander abzulösen. Mehr auf unserer Seite zur individuellen Softwareentwicklung – oder sprechen Sie mit uns über Ihr System.

Über Ihr Altsystem sprechen