Legacy-Software modernisieren: Mittelstand ohne Big-Bang-Rewrite
Warum Legacy-Modernisierung jetzt auf die Agenda gehört
Viele mittelständische Unternehmen arbeiten mit Software, die zuverlässig gewachsen ist: ERP-Erweiterungen, Access-Datenbanken, Excel-Makros, alte Webportale, individuelle Produktions- oder Dispositionssysteme. Diese Systeme sind nicht automatisch schlecht. Oft steckt darin genau das Prozesswissen, das ein Unternehmen stark macht.
Das Problem entsteht, wenn diese Software nicht mehr mit dem Geschäft mitkommt. Neue Schnittstellen dauern Monate. Änderungen sind nur durch eine Person möglich. Sicherheitsupdates sind riskant. Daten liegen in Silos. Und jede neue digitale Initiative beginnt mit dem Satz: Das geht mit unserem Altsystem schwierig.
Der KfW-Digitalisierungsbericht Mittelstand 2025 zeigt die Investitionsrealität: Digitalisierungsausgaben lagen bei 23,8 Milliarden Euro, Sachinvestitionen bei 256 Milliarden Euro. Modernisierung muss deshalb messbar und risikoarm sein.
Warum der Big-Bang-Rewrite selten passt
Ein kompletter Neubau wirkt sauber: alte Technologie weg, moderne Architektur rein, neue Oberfläche, neue Schnittstellen. In der Praxis ist ein Big-Bang-Rewrite aber riskant, weil das alte System meist mehr kann, als dokumentiert ist. Fachlogik steckt in Code, Datenbankfeldern, Exportdateien, Workarounds und Köpfen einzelner Mitarbeitender.
| Ansatz | Vorteil | Risiko | Geeignet für |
|---|---|---|---|
| Big-Bang-Rewrite | Klare Zielarchitektur auf einmal | Hohe Go-live-Risiken | Kleine, gut verstandene Systeme |
| Lift & Shift | Schneller Infrastrukturwechsel | Fachliche Altlasten bleiben | Hosting- oder Betriebsprobleme |
| API-Kapselung | Integration ohne sofortigen Umbau | Kernlogik bleibt alt | Systeme mit stabiler Logik |
| Strangler Pattern | Risiko verteilt sich auf Etappen | Erfordert Architekturdisziplin | Kritische Systeme im laufenden Betrieb |
Strangler Fig: Schrittweise statt alles auf einmal
Das Strangler-Fig-Pattern ist ein bewährtes Muster für risikoarme Modernisierung. Microsoft beschreibt es im Azure Architecture Center, AWS in der Prescriptive Guidance. Neue Komponenten wachsen um das bestehende System herum, bis alte Teile sicher abgeschaltet werden können.
Praktisch bedeutet das:
- Das Legacy-System bleibt zunächst produktiv.
- Neue Funktionen werden außerhalb des Altsystems gebaut.
- Eine Fassade, API oder Routing-Schicht entscheidet, ob ein Vorgang alt oder neu verarbeitet wird.
- Funktion für Funktion wird migriert.
- Erst stabile Bereiche werden abgeschaltet.
Dieser Ansatz liefert messbare Zwischenergebnisse und vermeidet die Wette auf einen einzigen großen Go-live.
APIs als Brücke zwischen Alt und Neu
IBM beschreibt Application Modernization auch als Öffnung bestehender Funktionalität über APIs. Für den Mittelstand ist das oft der beste erste Schritt: Ein altes ERP-Modul muss nicht sofort neu gebaut werden, wenn es stabile Auftragsdaten liefern kann. Eine Kundenplattform kann modernisiert werden, während Bestandslogik kontrolliert weiterläuft.
Typische erste API-Schnitte sind Kunden- und Auftragsdaten für Portale, Statusinformationen aus Produktion und Logistik, Dokumente für Self-Service-Prozesse, Stammdatensynchronisation zwischen ERP, CRM und Shop sowie moderne Authentifizierung.
Technische Schulden sichtbar machen
Technische Schulden sind ein Budgetthema. McKinsey nennt 10 bis 20 Prozent Zusatzaufwand auf Projekte durch Tech Debt und berichtet, dass viele CIOs erhebliche Teile ihres Budgets für Altlasten aufwenden. Gartner empfiehlt, technische Schulden strukturiert zu bewerten und zu steuern (Gartner Technical Debt).
| Bewertungskriterium | Leitfrage | Messgröße |
|---|---|---|
| Geschäftskritikalität | Was passiert bei Ausfall? | Umsatz-, Liefer- oder Compliance-Auswirkung |
| Änderbarkeit | Wie schnell sind neue Anforderungen möglich? | Durchlaufzeit von Change Requests |
| Betriebsrisiko | Wie stabil und sicher läuft das System? | Incidents, Patch-Stand |
| Wissensrisiko | Wie abhängig sind wir von Einzelpersonen? | Anzahl aktiver Know-how-Träger |
| Integrationsfähigkeit | Wie gut lässt sich das System anbinden? | APIs, Datenqualität, Aufwand |
Fazit
Legacy-Software ist im Mittelstand oft ein Vermögenswert mit technischen Nebenwirkungen. Der bessere Weg ist selten alles neu, sondern das Richtige zuerst: Engpässe identifizieren, Systeme bewerten, APIs schaffen, Funktionen gezielt herauslösen und technische Schulden messbar reduzieren.
Wenn Sie wissen möchten, welche Legacy-Systeme zuerst modernisiert werden sollten, starten Sie mit unserem Digitalisierungs-Check.
Schlagwörter
