Legacy-Software modernisieren: Von Access und Excel zur Web-Anwendung

Das lernen Sie in diesem Artikel:

• Warum Access- und Excel-Lösungen zu unkalkulierbaren Geschäftsrisiken werden
• Wie der Strangler-Ansatz risikoarme Migration ermöglicht – ohne Big Bang
• Welche Schritte bei Datenmigration und Parallelbetrieb kritisch sind
• Wie Sie Team-Akzeptanz für neue Systeme sichern
• Was Legacy-Modernisierung kostet und wie Nearshore-Entwicklung hilft

Wenn Excel zur Risikobombe wird: Das Problem mit gewachsenen Insellösungen

Die Warenwirtschaft läuft in einer Access-Datenbank, die vor zehn Jahren der damalige Werkstudent gebaut hat. Die Angebotskalkulation steckt in einem Excel-Makro mit 47 Tabellenblättern und verschachtelten VBA-Skripten. Der einzige Kollege, der das System noch versteht, ist seit drei Monaten in Rente.

Dieses Szenario ist kein Einzelfall. Viele mittelständische Unternehmen – vom Großhändler über den Maschinenbauer bis zum Dienstleister – haben über Jahre hinweg auf Access-Datenbanken und Excel-Lösungen aufgebaut. Die Systeme funktionieren. Bis zu dem Moment, wo sie es nicht mehr tun.

Das zentrale Problem: Kritisches Geschäftswissen existiert nur in den Köpfen einzelner Personen. Die Logik hinter den Berechnungen, die Bedeutung einzelner Felder, die Abhängigkeiten zwischen verschiedenen Tabellen – all das ist nirgends dokumentiert. Hinzu kommt: Access und Excel sind Einzelplatzsysteme. Mehrere Mitarbeiter können nicht gleichzeitig arbeiten, Mandantenfähigkeit ist nicht vorgesehen, mobile Zugriffe unmöglich.

Spätestens wenn Compliance-Anforderungen steigen, wenn das Team wächst oder wenn der Inhaber über Nachfolge nachdenkt, wird aus der pragmatischen Lösung ein strukturelles Risiko. Legacy-Software modernisieren wird dann keine Kann-Entscheidung mehr, sondern eine strategische Notwendigkeit.

Warum der Big Bang fast immer scheitert

Die intuitive Reaktion vieler Geschäftsführer: "Wir brauchen ein komplett neues System. Lasst uns alles auf einmal umstellen." Dieser Big-Bang-Ansatz klingt effizient – führt in der Praxis aber regelmäßig zu gescheiterten Projekten.

Warum? Weil Sie versuchen, jahrelang gewachsene Prozesse und implizites Wissen in einem Schritt in eine neue Software zu gießen. Das Ergebnis:

• Unterschätzte Komplexität: Erst im laufenden Projekt stellt sich heraus, dass die alte Access-Datenbank 27 Sonderfälle abbildet, die niemand mehr auf dem Schirm hatte.
• Lähmende Abhängigkeiten: Die neue Software kann erst produktiv gehen, wenn alle Module fertig sind. Bis dahin: kein Mehrwert.
• Team-Überforderung: Mitarbeiter müssen von heute auf morgen komplett umlernen – während das Tagesgeschäft weiterläuft.
• Go-Live-Panik: Am Stichtag X muss alles funktionieren. Jeder Bug wird zum Showstopper.

Die Folge: Projekte dauern deutlich länger als geplant, werden spürbar teurer – oder werden nach Monaten abgebrochen, weil das Altsystem "doch noch irgendwie läuft".

Der Strangler-Ansatz: Legacy-Software Schritt für Schritt ablösen

Die risikoärmere Alternative heißt Strangler-Pattern – benannt nach Würgefeigen, die einen Wirtsbaum langsam umschließen und schließlich ersetzen. Übertragen auf Software-Modernisierung bedeutet das:

Sie bauen die neue Web-Anwendung neben dem Altsystem auf. Modul für Modul migrieren Sie Funktionen – während das alte System parallel weiterläuft. Erst wenn ein Bereich vollständig funktioniert und das Team damit arbeiten kann, wird er im Altsystem abgeschaltet.

Konkrete Umsetzung in drei Phasen

Phase 1: Fachliche Inventur

Bevor eine Zeile Code geschrieben wird, dokumentieren Sie gemeinsam mit Ihrem Entwicklungspartner:

• Welche Geschäftsprozesse bildet das Altsystem ab?
• Welche Daten existieren – und welche werden tatsächlich genutzt?
• Welche Abhängigkeiten bestehen zwischen Modulen?
• Wo stecken Sonderfälle und Workarounds?

Typisch für diese Phase: Viele Felder einer gewachsenen Access-Datenbank bleiben seit Jahren leer – Relikte früherer Prozesse, die längst anders gelöst werden. Sie müssen nicht migriert werden.

Phase 2: Pilotmodul mit Quick Win

Starten Sie mit einem Modul, das:

• Klare Abgrenzung hat (z. B. Angebotserstellung, Zeiterfassung, Bestellwesen)
• Echten Mehrwert bringt (z. B. mobiler Zugriff, Teamfähigkeit)
• Nicht zu komplex ist

Beispielszenario: Ein Maschinenbauer beginnt mit der Urlaubsverwaltung – bislang eine Excel-Liste. Das neue Webmodul ermöglicht Mitarbeitern, Urlaub per Smartphone zu beantragen. So lernt das Team die neue Oberfläche kennen – ohne Druck im Kerngeschäft.

Phase 3: Schrittweise Erweiterung

Jetzt folgen weitere Module – immer mit klarem Übergang:

1. Neues Modul entwickeln und testen
2. Daten migrieren (zunächst historisch, dann laufend synchronisiert)
3. Team schulen
4. Parallelbetrieb (beide Systeme laufen)
5. Produktivbetrieb im neuen System
6. Altsystem für diesen Bereich abschalten

Dieser Ansatz verteilt Risiko, Lernaufwand und Investition über Monate. Sie haben nach jedem Modul ein funktionierendes System – kein monatelanges Warten auf den großen Stichtag.

Datenmigration: Wo die meisten Projekte straucheln

Die technische Migration alter Datenbestände ist oft der unterschätzte Stolperstein. Access-Datenbanken und Excel-Dateien enthalten über Jahre gewachsene Inkonsistenzen:

• Freitextfelder, in denen eigentlich strukturierte Daten stecken
• Datumsangaben in unterschiedlichen Formaten
• Doppelte Datensätze mit leicht abweichenden Schreibweisen
• Berechnete Felder, deren Logik nur in VBA-Code existiert

Fünf Regeln für saubere Migration

1. Datenqualität vorher prüfen: Analysieren Sie das Altsystem systematisch. Welche Inkonsistenzen existieren? Welche Bereinigung ist vor der Migration nötig?

2. Testmigration mit Echtdaten: Migrieren Sie einen Teilbestand, prüfen Sie Vollständigkeit und Korrektheit. Wiederholen Sie diesen Prozess, bis die Fehlerquote gegen null geht.

3. Migrationsskripte dokumentieren: Die Transformation von Alt- zu Neudaten muss nachvollziehbar sein. Keine manuellen Excel-Spielereien.

4. Historische vs. laufende Daten trennen: Alte, abgeschlossene Vorgänge können oft 1:1 übernommen werden. Laufende Prozesse brauchen saubere Schnittstellenlogik.

5. Rollback-Szenario einplanen: Wenn die Migration schiefgeht, müssen Sie binnen Minuten zurück ins Altsystem können.

Beispielszenario: Ein Dienstleistungsunternehmen hat 14 Jahre Projekthistorie in einer Access-Datenbank. Die Testmigration deckt auf, dass Kundennummern mehrfach umgestellt wurden – mit inkonsistenter Zuordnung. Genau solche Funde sollten vor dem Echtbetrieb bereinigt werden, nicht danach.

Parallelbetrieb: Die kritische Übergangsphase meistern

Während der Migration laufen altes und neues System parallel. Das bedeutet:

• Doppelte Datenpflege (temporär)
• Synchronisationsmechanismen zwischen Alt und Neu
• Klare Regeln, welches System führend ist

Dieser Zustand sollte so kurz wie möglich sein – aber lang genug, um sicherzustellen, dass das neue System stabil läuft.

Typischer Parallelbetrieb-Fahrplan

• Woche 1-2: Team arbeitet primär im alten System, testet neue Funktionen parallel
• Woche 3-4: Neue Vorgänge werden im neuen System erfasst, alte Vorgänge im Altsystem zu Ende bearbeitet
• Woche 5: Nur noch Lesezugriff aufs Altsystem (für historische Recherche)
• Woche 6+: Altsystem wird archiviert, bleibt aber technisch verfügbar

Der Parallelbetrieb ist auch die Phase, in der sich zeigt, ob die Mitarbeiterakzeptanz stimmt.

Team-Akzeptanz sichern: Change Management ist kein Buzzword

Die beste neue Software scheitert, wenn das Team sie nicht nutzt. Typische Widerstände:

• "Das alte System kenne ich in- und auswendig. Das neue ist umständlich."
• "Ich habe keine Zeit, mich in neue Software einzuarbeiten."
• "Warum ändern wir etwas, das funktioniert?"

Diese Einwände sind emotional nachvollziehbar – und müssen ernst genommen werden.

Vier Hebel für erfolgreiche Einführung

1. Frühzeitig einbinden: Lassen Sie die Mitarbeiter, die täglich mit dem System arbeiten, bei der Anforderungsanalyse mitreden. Wer gehört wird, trägt Veränderung mit.

2. Quick Wins zeigen: Die neue Web-Anwendung muss vom ersten Tag an Mehrwert bieten. Wenn die Kollegin aus dem Vertrieb erstmals vom Tablet beim Kunden ein Angebot erstellen kann, ist das überzeugender als jede Schulung.

3. Schulung im echten Kontext: Keine abstrakten Software-Demos. Arbeiten Sie mit den realen Prozessen und Daten Ihres Unternehmens.

4. Ansprechpartner benennen: In der Einführungsphase braucht es jemanden, der bei Fragen sofort helfen kann – nicht erst nach drei Tagen Ticket-Warteschlange.

Ein bewährtes Mittel sind "System-Paten": Zwei technikaffine Kollegen werden intensiv geschult und stehen in den ersten Wochen als erste Anlaufstelle bereit. Das entlastet die externen Entwickler und gibt den Mitarbeitern das Gefühl, die Umstellung sei "unser Projekt", nicht "das Projekt der IT-Firma".

Nearshore-Entwicklung: Modernisierung wirtschaftlich umsetzen

Legacy-Software modernisieren ist kein Wochenendprojekt. Realistisch müssen Sie je nach Komplexität mit drei bis zwölf Monaten rechnen. Entsprechend entscheidend ist die Frage: Mit welchem Partner setze ich das um?

Viele Mittelständler scheuen die Investition, weil deutsche Entwicklerkapazitäten teuer und knapp sind. Hier kommt Nearshore-Entwicklung ins Spiel:

• Schriftliche Anforderungen: Projektkommunikation und Dokumentation erfolgen auf Englisch oder Türkisch; Anforderungen werden schriftlich festgehalten und abgestimmt.
• EU-Datenschutz-Verständnis: Ihr Entwicklungspartner sollte DSGVO-Anforderungen kennen, auch wenn das Entwicklerteam in der Türkei sitzt.
• Zeitzonennähe: Nur ein bis zwei Stunden Zeitverschiebung; Videocalls zu normalen Geschäftszeiten.
• Wirtschaftlichkeit: Tagessätze liegen in der Türkei in der Regel unter dem deutschen Niveau.

Bei D'Cloud Software, einem Softwareteam aus Mersin, Türkei, arbeiten wir nach diesem Modell: Entwicklung in Mersin, Festpreis, Verträge und Datenschutz nach EU-Standard. Das macht Legacy-Modernisierung auch für kleinere Mittelständler planbar.

FAQ: Häufige Fragen zur Legacy-Software-Modernisierung

Was kostet es, eine Access-Datenbank durch eine Web-Anwendung zu ersetzen?

Das hängt von Umfang, Komplexität und gewünschtem Funktionsumfang ab. Eine einfache Datenbankanwendung mit CRUD-Funktionen (Create, Read, Update, Delete) ist deutlich weniger aufwendig als ein komplexes Warenwirtschafts- oder ERP-System.

Entscheidend ist: Im kostenlosen Erstgespräch analysieren wir Ihre Anforderungen und erstellen ein verbindliches Festpreis-Angebot. Sie wissen vor Projektstart genau, was die Modernisierung kostet – vertraglich fixiert, ohne versteckte Zusatzkosten. Nach Übergabe beheben wir 15 Tage lang Fehler kostenlos.

Wie lange dauert die Migration einer Legacy-Anwendung?

Ein einzelnes Modul (z. B. Angebotserstellung, Zeiterfassung) ist deutlich schneller umgesetzt als die vollständige Ablösung eines gewachsenen Access- oder Excel-Systems. Die verbindliche Dauer steht nach der Klärung des Umfangs im Vertrag.

Der Strangler-Ansatz hat den Vorteil, dass Sie nicht die gesamte Zeit warten müssen: Nach jedem abgeschlossenen Modul haben Sie funktionierenden Mehrwert. Ein mögliches Vorgehen: Ein Maschinenbauer beginnt mit der Urlaubsverwaltung, ergänzt zwei Monate später das Bestellwesen und danach die Angebotskalkulation – die Entwicklungszeit je Modul wird jeweils im Vertrag festgelegt.

Können wir das Altsystem während der Migration weiterbetreiben?

Ja, genau dafür ist der Strangler-Ansatz konzipiert. Das alte System läuft parallel, bis das neue Modul produktiv ist. Kritisch ist die Datensynchronisation: Änderungen im Altsystem müssen – temporär – ins neue System übernommen werden, bis der endgültige Wechsel erfolgt.

In der Übergangsphase bedeutet das meist etwas Mehraufwand für Ihr Team (Doppeleingaben oder nächtliche Sync-Läufe). Dieser Zustand sollte aber auf wenige Wochen begrenzt sein. Ein klarer Migrationsfahrplan mit fixen Stichtagen verhindert, dass der Parallelbetrieb zur Dauerlösung wird.

Was passiert mit unseren historischen Daten?

Historische Daten werden migriert und bleiben vollständig erhalten. Je nach Anforderung können Sie:

• Vollständig migrieren: Alle Altdaten werden in die neue Datenbank übernommen und stehen dort zur Verfügung.
• Archivlösung nutzen: Daten älter als X Jahre werden separat archiviert (z. B. als schreibgeschützte Datenbank), auf die bei Bedarf zugegriffen werden kann.
• Reporting-Schnittstelle bauen: Das neue System greift für historische Auswertungen auf die alte Datenbank zu (nur lesend).

Welche Variante sinnvoll ist, hängt von Datenmenge, Zugriffsfrequenz und Compliance-Anforderungen ab. Beispiel: Ein Dienstleister mit 20 Jahren Projekthistorie migriert die letzten 5 Jahre vollständig und archiviert die älteren Daten – Zugriff bei Bedarf, aber nicht im Live-System.

Brauchen wir danach keine IT-Wartung mehr?

Doch. Auch moderne Web-Anwendungen brauchen Wartung:

• Sicherheitsupdates: Frameworks und Bibliotheken müssen regelmäßig aktualisiert werden.
• Browserkompatibilität: Neue Browser-Versionen können Anpassungen erfordern.
• Feature-Wünsche: Ihr Geschäft entwickelt sich weiter – die Software sollte das auch tun.

Der Unterschied zum Altsystem: Diese Wartung ist planbar, dokumentiert und nicht abhängig von Einzelpersonen. Ihr neuer Entwicklungspartner kann Wartungsverträge anbieten; Umfang und Kosten werden darin vorab festgelegt. Alternativ bleibt die Anwendung wartbar für jeden qualifizierten Entwickler – weil der Code sauber dokumentiert ist, nicht in obskuren VBA-Makros versteckt.

Können wir die neue Software später selbst erweitern?

Ja, wenn Sie eigene Entwicklerkapazität haben. Seriöse Entwicklungspartner übergeben vollständigen Quellcode, Dokumentation und Deployment-Anleitungen. Sie sind nicht an den ursprünglichen Anbieter gebunden.

Alternativ können Sie kleinere Anpassungen über Ihren Entwicklungspartner beauftragen – auch Jahre später. Bei D'Cloud Software arbeiten wir mit sauberen Git-Repositories, automatisierten Tests und ausführlicher technischer Dokumentation. Die Rechte am Code werden im Vertrag geregelt – so entscheiden Sie, wer ihn weiterentwickelt.

Fazit: Legacy-Modernisierung ist Risikomanagement, kein Luxus

Wenn Ihr Unternehmen auf Access-Datenbanken oder Excel-Lösungen aufbaut, haben Sie vermutlich Jahre oder Jahrzehnte damit erfolgreich gearbeitet. Diese Systeme sind nicht per se schlecht – aber sie skalieren nicht, sie sind nicht teamfähig, und sie binden kritisches Wissen an einzelne Personen.

Legacy-Software modernisieren bedeutet nicht, funktionierende Prozesse zu zerschlagen. Es bedeutet, gewachsenes Geschäftswissen in moderne, wartbare, teamfähige Systeme zu überführen – bevor der Renteneintritt eines Mitarbeiters oder ein Compliance-Audit Sie dazu zwingt.

Der Strangler-Ansatz ermöglicht risikoarme Migration: Schritt für Schritt, Modul für Modul, mit Mehrwert nach jedem Meilenstein. Keine Big-Bang-Umstellung, keine monatelange Wartezeit, kein Totalausfall-Risiko.

D'Cloud Software, ein Softwareteam aus Mersin, Türkei, unterstützt mittelständische Unternehmen dabei, genau diesen Weg zu gehen: mit EU-Datenschutz-Standard und wirtschaftlicher Nearshore-Entwicklung. Vereinbaren Sie ein kostenloses Online-Erstgespräch – wir analysieren Ihre Legacy-Situation und erarbeiten einen konkreten Migrationsfahrplan. Festpreis, vertraglich fixiert, 15 Tage kostenlose Fehlerbehebung nach Übergabe.

---

Autor: Doğuhan Bulut, D'Cloud Software