Irgendwann steht in fast jedem Betrieb dieselbe Frage im Raum: Das System, das seit fünfzehn Jahren den Laden trägt, wird zum Problem. Der Entwickler von damals ist weg, jede Änderung dauert Wochen, und die IT drängt, weil die alten Versionen keine Updates mehr bekommen. Das ist der Normalfall, nicht die Ausnahme: In einer Lünendonk-Befragung (2025) unter mehr als 150 mittelständischen und großen Unternehmen gaben 62 Prozent an, dass Teile ihrer geschäftskritischen Anwendungen so veraltet sind, dass sie erneuert werden müssen; in jedem zweiten Haus ist der Betrieb der Altsysteme auf mittlere Sicht nicht mehr gesichert. Ab hier gibt es im Wesentlichen drei Wege: alles neu entwickeln, das Bestehende schrittweise ablösen oder auf eine fertige Standardlösung wechseln. Alle drei sind legitim. Welcher passt, hängt weniger von der Technik ab als von Ihrem Betrieb – und von der ehrlichen Antwort auf ein paar unbequeme Fragen.

Warum „einfach alles neu schreiben“ so oft schiefgeht

Der komplette Neubau ist die intuitivste Antwort und in der Praxis die riskanteste. Der Plan klingt sauber: Man entwickelt das neue System in Ruhe fertig, und an einem Wochenende wird umgeschaltet. In der Realität dauert der Neubau eines Systems, das fünfzehn Jahre gewachsen ist, selten unter anderthalb Jahren – und in dieser Zeit läuft das Altsystem weiter und verändert sich, weil der Betrieb nicht wartet. Das neue System jagt einem beweglichen Ziel hinterher.

Dazu kommt das versteckte Wissen: In altem Code stecken hunderte Sonderfälle, die nirgends dokumentiert sind. Die Preisregel für den größten Kunden, die Ausnahme für Bestellungen aus Vorarlberg, der Rundungsfall aus 2014. Beim Big-Bang-Umstieg fallen alle vergessenen Sonderfälle am selben Tag auf – am ersten Tag nach der Umstellung, wenn es am wenigsten passt.

Weg 1: Schrittweise ablösen, während alles weiterläuft

Die Alternative zum Big Bang: Das neue System wächst um das alte herum und übernimmt einen Bereich nach dem anderen. Zuerst legt sich eine neue Schnittstelle als Fassade vor das Altsystem, sodass aller Verkehr über eine Stelle läuft. Dann wird hinter dieser Fassade ein Modul neu gebaut – etwa die Auftragsverwaltung – und umgeschaltet, während der Rest nichts davon merkt. Alt und neu rechnen eine Zeit lang parallel, Abweichungen fallen sofort auf. Erst wenn nichts mehr über das alte Modul läuft, wird es abgeschaltet.

Dieser Weg passt, wenn das System geschäftskritisch ist und viel individuelle Logik enthält, die es so nirgends zu kaufen gibt. Er hat einen ehrlichen Preis: Über die Dauer der Migration betreiben Sie zwei Systeme nebeneinander, und die Fassade ist Aufwand, der am Ende wieder verschwindet. Dafür ist das Risiko zu jedem Zeitpunkt klein und jeder Schritt umkehrbar – man kauft Sicherheit mit etwas Mehraufwand.

Weg 2: Neuentwicklung – wann sie doch die richtige Wahl ist

Es gibt Fälle, in denen der Neubau vernünftig ist: wenn das Altsystem klein ist, sagen wir eine Access-Datenbank oder ein Werkzeug mit einer Handvoll Masken, das eine Person in wenigen Wochen nachbauen kann. Oder wenn die Technik so tot ist, dass sich niemand mehr findet, der sie anfassen kann, und der Quellcode ohnehin fehlt. Dann arbeitet man vom Verhalten aus: Datenbank, Exporte und Oberflächen zeigen, was das System tut, und das wird nachgebaut, getestet und diesmal dokumentiert.

Auch dann gilt: Die Umstellung selbst sollte nicht als Stichtag passieren, sondern mit Parallelphase und Rückfallebene. Der Neubau als Entwicklungsstrategie und der Big Bang als Umstellungsstrategie sind zwei getrennte Entscheidungen – man kann neu bauen und trotzdem schrittweise umsteigen.

Weg 3: Standardsoftware – die unbequeme Option, die man prüfen muss

Wir entwickeln Individualsoftware, trotzdem gehört diese Prüfung an den Anfang jedes Modernisierungsgesprächs: Wenn Ihr Altsystem im Kern etwas tut, das heute jede Standardlösung kann – Rechnungen schreiben, Lager führen, Termine verwalten –, dann ist der Wechsel auf ein fertiges Produkt oft der schnellste und billigste Weg. Dass das System einmal individuell gebaut wurde, heißt nicht, dass es individuell bleiben muss; manches war 2008 Sonderlocke und ist 2026 Standardfunktion.

Die Gegenprobe: Zählen Sie die Stellen, an denen Ihr Betrieb wirklich anders arbeitet, als die Standardlösung es vorsieht. Sind es zwei, drei Randthemen, lassen die sich meist um das Standardprodukt herum lösen. Zieht sich das Anderssein durch den Kernprozess, werden Sie die Standardlösung so lange verbiegen, bis Sie ihre Nachteile mit den Kosten einer Individualentwicklung bezahlt haben – nur eben verteilt auf Jahre und Workarounds.

Die drei Wege im Überblick

Bevor es an die Entscheidung geht, die drei Wege nebeneinander, so wie sie oben beschrieben sind:

	Schrittweise Ablöse	Neuentwicklung	Standardsoftware
Passt, wenn	System geschäftskritisch und voller Eigenlogik	System klein oder Technik tot, Quellcode fehlt	Kernprozess ist heute Standardfunktion
Risiko	Klein, jeder Schritt umkehrbar	Hoch am Stichtag, kleiner mit Parallelphase	Standard wird verbogen, bis er wie Individualbau kostet
Ehrlicher Preis	Zwei Systeme parallel, Fassade verschwindet wieder	Nachbau vom Verhalten aus, Testaufwand	Workarounds, verteilt auf Jahre
Tempo	Länger, aber ohne Stillstand	Wochen bei kleinen Systemen, sonst ab anderthalb Jahren	Oft der schnellste Weg

Die Entscheidungsfragen

In der Beratung läuft die Wahl fast immer auf dieselben Fragen hinaus:

Wie speziell ist der Kernprozess? Standard kaufen, Spezielles bauen.
Wie groß ist das System wirklich? Kleine Systeme neu bauen, große schrittweise ablösen.
Gibt es den Quellcode und jemanden, der ihn versteht? Ohne beides bleibt nur der Nachbau vom Verhalten aus.
Wie lange darf der Betrieb stehen? Wenn die Antwort „gar nicht“ ist, scheidet jeder Stichtags-Plan aus.
Wer soll das System in fünf Jahren warten? Die Antwort entscheidet über Technologie und Dokumentation, egal welcher Weg es wird.

Was bei allen drei Wegen gleich bleibt

Egal wie Sie sich entscheiden: Die Daten ziehen vollständig um, samt Historie. Vor jeder Umstellung wird das Verhalten des Altsystems in Tests festgehalten – auch die Eigenheiten, gerade die Eigenheiten. Umgeschaltet wird erst, wenn das Neue im Parallelbetrieb dieselben Ergebnisse liefert, und der Weg zurück ist Teil des Plans, nicht der Notfallordner.

Und am Ende sollte das Wissen über das System in Dokumentation, Tests und Ihrem Team stecken – nicht wieder nur in einem Kopf. Sonst haben Sie in zehn Jahren dasselbe Gespräch noch einmal, nur mit einem anderen Altsystem.