Legacy-Systeme ablösen ohne Betriebsausfall: Strangler Fig für Excel & Access

Dein Vertrieb arbeitet mit einer 12 Jahre alten Access-Datenbank, deine Buchhaltung pflegt Forecast-Tabellen, die niemand mehr versteht, und in der Schublade liegt das Angebot der "großen Modernisierung", an das sich seit 2022 keiner herantraut. Willkommen im Legacy-Alltag. Legacy-Systeme ablösen ist kein IT-Projekt – es ist ein Risikomanagement-Projekt. Und es gibt einen Weg, der ohne Betriebsausfall funktioniert: den Strangler-Fig-Ansatz.

Wir bei Storyable in Hannover migrieren mittelständische Excel-, Access- und SAP-Insellösungen seit Jahren. Wir haben dabei gelernt, dass die teuerste Migration nicht die ist, die zu spät kommt – sondern die, die zu groß angesetzt wird. Dieser Cluster-Artikel ergänzt unseren Web-App-Entwicklungs-Guide und zeigt dir, wie du eine Ablösung sauber durchziehst, ohne dass dein Tagesgeschäft auch nur eine Stunde stillsteht.

Das Problem: Warum Unternehmen jahrelang mit gefährlicher Schatten-IT leben

Schatten-IT ist selten ein Sicherheitsproblem zuerst – sie ist ein Wahrnehmungsproblem. Niemand bezeichnet die zentrale Excel-Tabelle als "kritische Geschäftsanwendung". Sie ist halt da. Sie funktioniert. Bis sie nicht mehr funktioniert.

In jedem zweiten Mittelständler, mit dem wir in Hannover sprechen, finden wir dasselbe Muster:

• Eine Excel-Datei mit 40+ Verknüpfungen, die nur eine Person versteht
• Eine Access-Datenbank von 2011, die auf einem Windows-Server unter dem Schreibtisch läuft
• Manuelle CSV-Exporte aus SAP, die per E-Mail durch die Buchhaltung wandern
• Ein "ERP" aus drei Tools, die niemand mehr offiziell wartet

Die Folgen sind messbar und gefährlich:

• Compliance-Risiko: GoBD verlangt revisionssichere Datenhaltung – Excel kann das nicht
• Key-Person-Risiko: Der Kollege, der die Logik kennt, ist im Urlaub. Oder gekündigt.
• Skalierungsbremse: Bei doppeltem Auftragsvolumen brechen die Tabellen weg
• Sicherheits-Albtraum: Veraltete Access-Runtimes sind ein bekanntes Einfallstor für Ransomware

Genau hier setzt das Argument für strukturierte interne Webapps zur Prozessoptimierung an: Du kaufst dir nicht nur Tempo, du kaufst dir Belastbarkeit. Und die ehrliche Vergleichsfrage Custom Code vs. Baukasten entscheidet sich bei Legacy-Ablösungen fast immer zugunsten von Custom Code – weil Baukästen die Eigenheiten gewachsener Geschäftsprozesse nicht abbilden.

Der "Strangler Fig"-Ansatz erklärt: Schrittweise Ablösung statt Big-Bang-Migration

Big-Bang-Migration heißt: Stichtag X, altes System aus, neues System an. Die Standish-Group-Chaos-Reports zeigen seit Jahren, dass über 60 % dieser Projekte scheitern, massiv über Budget laufen oder Funktionen verlieren. Ein einziger Edge Case, der in der Spezifikation übersehen wurde, kann das Tagesgeschäft tagelang lahmlegen.

Martin Fowler beschrieb 2004 eine elegante Alternative: das Strangler-Fig-Pattern. Inspiriert von der Würgefeige, die einen Baum umschließt und langsam ersetzt, ohne dass dieser bricht.

Übersetzt auf Software:

1. Das Altsystem bleibt im Betrieb. Niemand wird gezwungen, sofort zu wechseln.
2. Eine neue Webapp wächst funktional um es herum. Modul für Modul wird aus dem Altsystem ausgeschnitten und im neuen System neu implementiert.
3. Routing entscheidet pro Anfrage, ob die alte oder neue Anwendung antwortet – über einen API-Gateway, ein Reverse Proxy oder eine schlichte Login-Weiche.
4. Wenn jede Funktion abgelöst ist, wird das Altsystem abgeschaltet – als Read-Only-Snapshot archiviert, niemals einfach gelöscht.

Der zentrale Vorteil: Jeder Schritt ist reversibel. Bricht ein Modul der neuen Webapp, schaltest du das Routing zurück. Das Altsystem ist dein Sicherheitsnetz, nicht dein Feind.

Phase 1: Analyse und Mapping der bestehenden Prozesse

Bevor eine einzige Zeile Code geschrieben wird, kartieren wir die gewachsene Wirklichkeit. Nicht das, was im Org-Handbuch steht – sondern das, was tatsächlich passiert.

Die drei Werkzeuge der Phase 1

1. Process-Walking: Wir setzen uns einen Tag neben jeden Power-User. Wir schauen zu, was geklickt, kopiert, exportiert wird. 80 % der echten Logik steht nirgendwo dokumentiert.
2. Datenfluss-Diagramm: Welche Tabelle füttert welche? Wo bricht eine Verknüpfung? Welcher Mitarbeiter ist Single Point of Failure?
3. Edge-Case-Inventar: Stornos, Sonderpreise, Kunden mit Sondervereinbarungen, Quartalsabschlüsse, GoBD-Exporte. Jeder Sonderfall, der "ach ja, das ist nochmal anders" ausgelöst hat.

Was am Ende der Phase 1 vorliegt

Diese Phase wird gerne unterschätzt – und ist genau deshalb der häufigste Grund, warum Migrationen entgleisen. Wer hier abkürzt, baut das gleiche Chaos in einer schöneren Oberfläche nach.

Phase 2: Parallelbetrieb – neue Webapp läuft neben dem alten System

In Phase 2 startet das, was die meisten Stakeholder zuerst beunruhigt: zwei Systeme gleichzeitig. Klingt nach Doppelarbeit – ist aber genau das Gegenteil von Big-Bang-Risiko.

Die drei Säulen des Parallelbetriebs

1. Routing & API-Gateway: Ein Reverse Proxy (Nginx, Traefik, Cloudflare Workers) entscheidet pro Anfrage, welches System antwortet. Beispiel: "Auftragserfassung neu" → neue Webapp. "Lagerbestände" → noch Altsystem. Mitarbeiter sehen nur eine URL.

2. Dual Writes mit Single Source of Truth: Solange ein Modul migriert wird, schreibt die neue Webapp parallel ins alte System – oder umgekehrt. Eine der beiden Datenquellen ist die führende, die andere wird kontinuierlich abgeglichen. Der Vorteil: Reporting-Tools, SAP-Schnittstellen oder Steuerberater-Exporte funktionieren weiter, ohne dass irgendwer sie anpasst.

3. Schatten-Validierung: Jede Anfrage in der neuen Webapp wird parallel im Altsystem ausgeführt – nur zum Vergleich, nicht zum Schreiben. Stimmen die Ergebnisse über zwei Wochen zu 100 % überein, ist das Modul migrationsreif. Der CTO entscheidet auf Daten, nicht auf Bauchgefühl.

Typische Reihenfolge der Modul-Ablösung

1. Lese-Zugriffe zuerst (Reports, Dashboards) – geringes Risiko, hoher Nutzen
2. Erfassungs-Workflows (Auftragseingang, Stammdatenpflege) – mittleres Risiko, sehr hoher Nutzen
3. Buchhaltungs-Module zuletzt – höchstes Compliance-Risiko, daher als Letztes mit voller Schatten-Validierung

Die UX dieser Phase ist entscheidend für die Akzeptanz – ein Thema, das wir im Cluster zu UX-Design in Webapps und Kundenbindung ausführlich beleuchten. Mitarbeiter, die das neue Tool als Hilfe statt als Bedrohung empfinden, beschleunigen jede Migration um Wochen.

Phase 3: Daten-Migration ohne Datenverlust (Strategien für Excel, Access, SAP-Exporte)

Phase 3 ist der Punkt, an dem Migrationen kippen. Nicht wegen Technik – sondern wegen schmutziger Daten, die jahrelang niemand sehen wollte. Doppelte Kunden, unsaubere Datentypen, Felder mit "siehe Bemerkung", Duplikate aus drei verschiedenen Excel-Versionen.

Die ETL-Pipeline (Extract, Transform, Load)

[Altsystem]  →  Extract  →  Validate  →  Transform  →  Load  →  [Neue Webapp]
   Excel        CSV /         Schema      Mapping        DB
   Access       SQL Query     Check       Cleansing      API
   SAP          BAPI / IDoc   Constraints Normalisierung

Jede Stufe wird versioniert und reproduzierbar gebaut. Bricht der Import, wird er zurückgerollt. Niemals "wir korrigieren das einmal von Hand" – jede Hand-Korrektur ist eine zukünftige Diskrepanz.

Spezifische Strategien je Quelle

Excel:

• Quellen erst auf einem read-only Snapshot einfrieren
• Power-Query oder Python-Pandas für die initiale Bereinigung
• Spalten-Mappings dokumentieren (alte Bezeichnung → neues Feld → Datentyp → Constraint)
• Formeln niemals ungeprüft übernehmen – sie sind oft falsch oder veraltet

Access:

• Per ODBC die SQL-Schemata exportieren
• Beziehungstabellen identifizieren (Access ist relational – die meisten User wissen das nicht)
• VBA-Module gesondert dokumentieren – sie enthalten die wahre Geschäftslogik

SAP / DATEV / ERP-Exporte:

• BAPIs oder OData-Schnittstellen statt CSV-Magie
• Master-Data ist führend in SAP, transaktionale Daten wandern – diese Reihenfolge nicht umdrehen
• Steuerberater frühzeitig einbinden für GoBD-Konformität

Sicherheitsnetz vor dem Cutover

1. Read-Only-Snapshot des Altsystems auf Backup-Storage – immer verfügbar, niemals gelöscht
2. Reverse-Migration-Pfad vorbereitet: Wie kommen wir innerhalb von 24 h zurück, falls das neue Modul kippt
3. Audit-Log über jeden migrierten Datensatz – wer wurde wann von wo nach wo migriert, mit Hash-Checksumme

Wer hier sauber arbeitet, gewinnt nicht nur Datensicherheit, sondern auch E-E-A-T-Trust-Signale für Audits und Compliance – Wirtschaftsprüfer und ISO-Auditoren lieben revisionssichere Migrationspfade.

Realbeispiel: Wie ein Mittelständler seine Auftragserfassung modernisiert hat

Ein hannoverscher Großhändler (40 Mitarbeiter, 8.000 Aufträge/Monat) kam mit folgendem Bild zu uns: Auftragserfassung in einer Access-Datenbank von 2013, Lagerbestand in vier separaten Excel-Sheets, Versand-Etiketten manuell aus SAP exportiert und neu eingegeben. Drei Vollzeitkräfte verbrachten 60 % ihrer Zeit mit Datenpflege.

Der Weg in 6 Monaten (gekürzt)

Monat 1 – Phase 1 (Discovery):

• 4 Tage Process-Walking, 1 Tag pro Power-User
• 38 Edge Cases identifiziert (u.a. Stornos mit Skonti, Saisonpreise, B2B-Sondervereinbarungen)
• Datenmodell: 17 Tabellen geplant statt 4 Excel-Sheets

Monat 2–3 – Phase 2 (Parallelbetrieb beginnt):

• Login-Weiche per Reverse Proxy
• Modul 1: Stammdatenpflege live in der neuen Webapp – Access bleibt führend, dual writes
• Schatten-Validierung über 4 Wochen, 99,98 % Datenidentität

Monat 4 – Modul 2: Auftragserfassung:

• Neue Webapp wird führend, Access als Read-Only
• KI-gestützte Plausibilitätsprüfung der Eingaben (Anbindung über die KI-Automation-Logik aus dem Website-Support-Cluster)
• Erfassungs-Zeit pro Auftrag: von 4:30 min auf 1:10 min

Monat 5 – Modul 3: Lagerbestand & SAP-Sync:

• OData-Schnittstelle zu SAP, kein CSV-Hin-und-Her mehr
• Excel-Sheets archiviert als Read-Only-Snapshot

Monat 6 – Cutover & Decommissioning:

• Access-Server abgeschaltet, Snapshot in Cold Storage
• Schulungen, Doku, Übergabe

Messbare Ergebnisse nach 6 Monaten

Diesen Detailgrad bauen wir in jedem unserer Webapp-Projekte aus Hannover ein – nicht weil es schön aussieht, sondern weil messbare KPIs der einzige ehrliche Beweis sind, dass eine Migration ihr Geld wert war.

Kostenkalkulation: Was eine Ablösung wirklich kostet vs. was Stillstand kostet

Die teuerste Frage, die wir hören: "Was kostet uns das?". Die richtige Frage lautet: "Was kostet uns das Nichts-Tun?".

Beispielrechnung Mittelständler (40–80 Mitarbeiter)

Investition Strangler-Fig-Migration:

Stillstandskosten pro Jahr (Status quo):

Break-Even: Bei einer Investition von 60.000 € und einer Einsparung von ~250.000 €/Jahr liegt der Break-Even bei unter 4 Monaten nach Vollbetrieb. Selbst bei einer 80 %-Quote der Realisierung amortisiert sich das Projekt im ersten Jahr.

Fazit: Legacy-Systeme ablösen heißt Risiko abbauen, nicht IT modernisieren

Legacy-Systeme ablösen ist kein Tech-Fetisch. Es ist die ehrlichste Form von Risikomanagement – und sie funktioniert messbar besser als Big-Bang. Der Strangler-Fig-Ansatz bietet dir vier Dinge, die keine andere Migration liefert: kein Betriebsausfall, jederzeit reversibel, datensicher, mitarbeitenden-freundlich. Das ist kein Methoden-Dogma, das ist Erfahrung aus über einem Jahrzehnt Mittelstandsprojekten.

Der nächste Schritt ist nicht, eine RFP zu schreiben oder ein Pflichtenheft zu drucken. Der nächste Schritt ist eine ehrliche Discovery-Phase mit jemandem, der schon zwei Dutzend solcher Migrationen sauber abgeschlossen hat. Wenn du Hintergrund willst, wie die Architektur dahinter atmet, lies unseren tieferen Einblick in Custom Code statt Baukasten für Webapps – und wenn du die strategische Klammer suchst, fängst du am besten bei unserem Web-App-Entwicklungs-Guide an.

Cagri Ersöz

Bereit, deine Schatten-IT abzulösen – ohne Stillstand?

Wir kartieren in 2 Wochen deine Excel-, Access- und ERP-Insellösungen, identifizieren die ersten drei migrationsfähigen Module und bauen dir eine Strangler-Fig-Roadmap inklusive Business Case. Pragmatisch, aus Hannover, kein Vendor-Lock-In.

Migrations-Discovery anfragen