Ein Vertriebsteam wartet drei Minuten auf einen Auftragsexport. Die Buchhaltung korrigiert Daten in Excel, weil das Kernsystem keine verlässliche Schnittstelle bietet. Neue Produktlogik kostet Wochen statt Tage. Genau an diesem Punkt beginnt eine Fallstudie zur Legacy System Modernisierung nicht mit einer Technologieentscheidung, sondern mit einer geschäftlichen Frage: Was kostet es das Unternehmen, wenn das zentrale System Wachstum ausbremst?
Legacy ist kein Synonym für schlecht. Viele geschäftskritische Systeme leisten seit Jahren wertvolle Arbeit. Sie enthalten Prozesse, Sonderregeln und Erfahrungswissen, das in keiner Dokumentation vollständig erfasst ist. Das Risiko liegt nicht im Alter allein. Es entsteht, wenn Änderungen unberechenbar werden, Integrationen fragil bleiben und operative Teams ihre Arbeit um die Software herum organisieren müssen.
Diese Fallstudie beschreibt ein typisches Modernisierungsszenario aus einem wachstumsorientierten B2B-Unternehmen. Der Fall ist anonymisiert, die Ausgangslage und die Entscheidungslogik sind jedoch bewusst konkret gehalten.
Ausgangslage: Ein Kernsystem wird zum Engpass
Das Unternehmen steuerte Angebote, Aufträge, Projektabwicklung und Abrechnung über eine individuell entwickelte Webanwendung. Das System war über Jahre gewachsen: ein monolithisches Backend, direkte Datenbankzugriffe aus verschiedenen Modulen, uneinheitliche Rollenrechte und mehrere manuelle Exporte für CRM, Finance und Reporting.
Die Anwendung funktionierte - solange die Anzahl der Nutzer, Transaktionen und Integrationen überschaubar blieb. Mit dem Wachstum änderte sich die Lage. Vertrieb, Operations und Finance arbeiteten in denselben Daten, aber mit unterschiedlichen Wahrheiten. Ein Statuswechsel im Auftrag löste nicht immer die erwarteten Folgeprozesse aus. Für neue Partnerintegrationen musste ein Entwickler tief in bestehende Logik eingreifen. Releases wurden deshalb selten und mit hoher Vorsicht durchgeführt.
Das Problem war nicht nur technisch. Die Geschäftsführung konnte neue Servicepakete nicht mit der gewünschten Geschwindigkeit testen. Das Operations-Team kompensierte fehlende Automatisierung mit manuellen Kontrollschritten. Fehler wurden spät entdeckt, weil es keine klare Ereignishistorie und kein zentrales Monitoring gab. Jede kleine Änderung erzeugte Abstimmungsaufwand zwischen Fachbereichen und Entwicklung.
Fallstudie zur Legacy System Modernisierung: Der richtige Schnitt
Der erste Impuls lautete: Alles neu bauen. Das ist verständlich, aber selten die beste Entscheidung. Ein vollständiger Rebuild verschiebt den Nutzen weit nach hinten, bindet Budget und erzeugt ein erhebliches Risiko: Während ein neues System entsteht, entwickelt sich das operative Geschäft weiter. Am Ende bildet die neue Plattform oft bereits wieder eine veraltete Realität ab.
Stattdessen wurde das Altsystem als laufender Kern behandelt, der schrittweise entkoppelt werden sollte. Ziel war keine kosmetische Modernisierung, sondern eine Architektur, die Veränderungen kalkulierbar macht. Dafür wurden zunächst die wertvollen und die problematischen Bereiche getrennt betrachtet.
Die Analyse kombinierte technische Prüfung und Prozesssicht. Relevant waren Datenflüsse, Abhängigkeiten, Lastspitzen, Fehlerbilder, Berechtigungen und die tatsächlichen Arbeitsabläufe der Teams. Besonders aufschlussreich waren nicht die dokumentierten Prozesse, sondern die Ausnahmen: Welche Informationen werden parallel geführt? Wo greifen Mitarbeitende manuell ein? Welche Schritte gelten intern als "normal", obwohl sie nicht im System abgebildet sind?
Dabei kristallisierten sich vier Prioritäten heraus:
- Auftrag und Abrechnung mussten als verlässliche Kernprozesse stabil bleiben.
- Integrationen zu CRM und Finance brauchten klar definierte Schnittstellen.
- Das Operations-Team benötigte ein eigenes Dashboard für Ausnahmen und Freigaben.
- Neue Produktregeln sollten ohne Eingriffe in die gesamte Anwendung auslieferbar sein.
Diese Priorisierung war entscheidend. Nicht jedes alte Modul musste sofort ersetzt werden. Bereiche ohne unmittelbaren Geschäfts- oder Risikodruck durften zunächst bestehen bleiben. Modernisiert wurde dort, wo Durchlaufzeit, Datenqualität oder Skalierbarkeit spürbar litten.
Die Architektur: Entkoppeln statt nur umgestalten
Die Modernisierung begann mit einer API-Schicht vor dem bestehenden System. Sie wurde nicht als dünne Fassade gebaut, sondern als klarer Vertrag zwischen Kernlogik, neuen Anwendungen und externen Services. So konnten neue Funktionen auf konsistenten Datenmodellen aufbauen, ohne dass jedes Frontend direkt auf die alte Datenbank zugreifen musste.
Parallel entstand eine Ereignislogik für relevante Statusänderungen. Wenn ein Auftrag freigegeben, geändert oder abgeschlossen wurde, erhielten angebundene Systeme ein nachvollziehbares Ereignis. Das reduzierte zeitversetzte Datenstände und machte Fehler sichtbar. Für kritische Prozesse blieben bewusst synchronisierte Prüfungen bestehen. Nicht jede Interaktion muss asynchron sein - etwa wenn eine Rechnung erst nach erfolgreicher Validierung erzeugt werden darf.
Das neue Operations-Dashboard wurde als eigenständige Web-App umgesetzt. Es ersetzte nicht sofort jede Ansicht des Altsystems, sondern fokussierte die Arbeit mit hohem Volumen und hohem Fehlerrisiko. Mitarbeitende sahen offene Ausnahmen, konnten Freigaben dokumentieren und erhielten eine vollständige Historie. Das war mehr als ein besseres Interface: Die neue Oberfläche zwang dazu, Verantwortlichkeiten, Statusmodelle und Eskalationen präzise zu definieren.
Auch das Datenmodell wurde nicht auf einen Schlag migriert. Stammdaten wurden schrittweise bereinigt und über eine zentrale Zuordnungsschicht konsolidiert. Historische Datensätze blieben dort, wo sie revisionssicher benötigt wurden. Aktive Prozesse liefen zunehmend über die neue Domänenlogik. Diese Trennung schützt den Betrieb und vermeidet, dass eine Migration zur monatelangen Blockade wird.
Warum Design in diesem Projekt Architekturarbeit war
Bei internen Systemen wird UX häufig unterschätzt. Dabei entscheidet die Oberfläche darüber, ob ein sauberer Prozess wirklich gelebt wird oder ob erneut Schattenlisten und Nebenwege entstehen. Im vorliegenden Fall hatten unterschiedliche Teams jeweils eigene Tabellen und Filter entwickelt, weil das alte System keine klare Priorisierung bot.
Das neue Interface stellte nicht alle Daten gleichzeitig dar. Es zeigte pro Rolle genau die Informationen und Aktionen, die für die nächste Entscheidung nötig waren. Kritische Abweichungen wurden visuell priorisiert, Standardfälle automatisiert abgewickelt. Das reduzierte Klickwege, aber vor allem kognitive Last.
Für ein Premium Digital Studio ist diese Verbindung zentral: Visuelle Qualität und technische Architektur sind keine getrennten Disziplinen. Ein präzises Interface kann Prozessfehler reduzieren. Eine saubere Architektur sorgt dafür, dass dieses Interface auch bei steigender Komplexität schnell und verlässlich bleibt.
Migration ohne Betriebsunterbrechung
Die Einführung erfolgte in kontrollierten Etappen. Zuerst lief das Dashboard parallel zum Altsystem und zeigte nur Daten an. So konnte geprüft werden, ob Status, Berechnungen und Berechtigungen korrekt abgebildet waren. Danach wurden einzelne Aktionen freigeschaltet, zunächst für ein kleines Team und klar abgegrenzte Auftragsarten.
Wichtig war ein messbarer Abgleich. Für jede migrierte Prozessstrecke wurde definiert, welche Daten identisch sein mussten, welche Abweichungen zulässig waren und wer Entscheidungen bei Konflikten trifft. Ohne diese Regeln wird Parallelbetrieb schnell zu dauerhafter Doppelarbeit.
Ein Rollback-Konzept gehörte ebenfalls dazu. Bei Fehlern konnte ein Vorgang im alten System weiterbearbeitet werden, ohne Daten zu verlieren. Das kostet in der Umsetzung zusätzliche Zeit. Es ist aber günstiger als ein erzwungener Go-live, bei dem operative Teams Vertrauen in das neue System verlieren.
Ergebnisse: Weniger Reibung, mehr Handlungsspielraum
Nach der ersten Ausbaustufe sank die Bearbeitungszeit für Standardaufträge deutlich, weil Prüfung und Übergabe zwischen Teams automatisiert wurden. Entscheidend war jedoch der strukturelle Effekt: Neue Produktregeln konnten in einem isolierten Modul umgesetzt werden. CRM und Finance erhielten stabile Schnittstellen statt wiederkehrender CSV-Exporte. Das Management bekam belastbarere Prozessdaten, weil Statuswechsel und Ausnahmen zentral erfasst wurden.
Die Modernisierung machte das Unternehmen nicht automatisch schneller in jeder Hinsicht. Für manche Altprozesse blieb Übergangslogik nötig, und die Pflege klarer API-Verträge verlangt Disziplin. Doch die Kosten jeder weiteren Veränderung sanken. Genau das ist der strategische Gewinn: Das System wird von einer Quelle operativer Unsicherheit zu einer Plattform für Produktentwicklung, Automatisierung und Wachstum.
Was Entscheider aus dieser Modernisierung mitnehmen können
Eine Legacy-Modernisierung sollte nicht nach dem Alter des Codes priorisiert werden, sondern nach dem Verhältnis aus Geschäftsrisiko, Veränderungsdruck und technischem Hebel. Ein zehn Jahre altes Modul kann stabil und wirtschaftlich sein. Ein zwei Jahre alter Schnellbau kann dagegen bereits ein kritischer Engpass sein.
Der sinnvollste Einstieg ist meist ein klar abgegrenzter Prozess mit hoher Frequenz oder hoher Fehlerquote. Dort lassen sich Architektur, Datenqualität, UX und Automatisierung gemeinsam verbessern - und der Nutzen wird im Betrieb sichtbar. Erst dann lohnt sich die nächste Ausbaustufe mit voller Klarheit.
Die entscheidende Frage lautet deshalb nicht, ob ein Legacy-System ersetzt werden muss. Sie lautet: Welche Fähigkeit soll Ihr Unternehmen in den nächsten zwei Jahren schneller, sicherer und unabhängiger beherrschen? Die Antwort definiert den ersten Schnitt in die bestehende Architektur.