Reden wir zuerst respektvoll über Access. Die Datenbank, die heute als Altlast gilt, war vor fünfzehn oder zwanzig Jahren eine gute Entscheidung: Jemand im Betrieb hat damit ein Werkzeug gebaut, das exakt zum eigenen Ablauf passt, für einen Bruchteil dessen, was Individualsoftware damals gekostet hätte. Deshalb leben diese Lösungen so lange – sie funktionieren. Bis sie es nicht mehr tun. Wenn Sie diesen Text lesen, ist Ihre Access-Lösung vermutlich an ihrer Grenze angekommen, und die Frage lautet: Wie kommt man da heraus, ohne zwanzig Jahre Daten und eingebautes Firmenwissen zu verlieren?

Woran man merkt, dass die Grenze erreicht ist

Die Symptome ähneln sich von Betrieb zu Betrieb verblüffend. Die Datei liegt am Netzlaufwerk, und sobald mehrere Leute gleichzeitig arbeiten, hakt es: Datensätze sind gesperrt, die Anwendung friert ein, gelegentlich meldet Access eine beschädigte Datenbank und jemand muss die Reparaturfunktion bemühen – mit klopfendem Herzen. Die Datei wächst Richtung Zwei-Gigabyte-Grenze. Homeoffice geht nur über Umwege, ein Zugriff vom Handy gar nicht.

Und dann ist da die Personenfrage: Gepflegt wird das Ganze von der einen Person, die sich VBA beigebracht hat – oder von niemandem mehr, weil diese Person in Pension ist. Damit sind Sie in großer Gesellschaft: Laut der Lünendonk-Studie „IT-Modernisierung zwischen Legacy, Cloud und KI“ (2025) berichtet die Hälfte der befragten Unternehmen, dass Betrieb, Pflege und Weiterentwicklung ihrer Altsysteme mittel- bis langfristig nicht mehr sichergestellt sind. Spätestens wenn die IT-Abteilung fragt, wann „das Access-Ding“ endlich wegkommt, weil alte Office-Versionen ein Sicherheitsthema sind, ist der Zeitpunkt da.

Der wichtigste Schritt passiert vor dem ersten Datensatz: die Bestandsaufnahme

Eine Access-Anwendung besteht aus vier Schichten, und alle vier enthalten Geschäftswissen: die Tabellen mit den Daten selbst, die Abfragen, in denen oft erstaunlich viel Logik steckt, die Formulare mit ihren Eingaberegeln und dem VBA-Code dahinter, und die Berichte, an deren Layout sich womöglich Kunden und Steuerberater gewöhnt haben.

Vor jeder Migration gehört das inventarisiert: Welche Tabellen werden tatsächlich befüllt, welche Abfragen laufen wirklich, welcher VBA-Code tut was? Fast immer finden sich dabei Regeln, die niemand mehr am Schirm hatte – der Rabatt, der ab einer bestimmten Menge automatisch greift, die Plausibilitätsprüfung im Formular. Genau diese unscheinbaren Regeln sind das, was bei einem schlampigen Umzug verloren geht. Nicht die Daten – die Regeln.

Schicht	Was darin steckt	Typisches Risiko beim Umzug
Tabellen	Die Daten selbst, oft über Jahrzehnte gewachsen	Dubletten, Datumswerte als Text, verwaiste Verknüpfungen
Abfragen	Erstaunlich viel Geschäftslogik	Logik wird übersehen und fehlt im neuen System
Formulare + VBA	Eingaberegeln, Plausibilitätsprüfungen, Automatismen	Undokumentierte Regeln gehen stillschweigend verloren
Berichte	Layouts, an die sich Kunden und Steuerberater gewöhnt haben	Empfänger bekommen plötzlich andere Auswertungen

Der Umzug selbst: wiederholbar statt heldenhaft, ohne harten Stichtag

Der eigentliche Umzug der Daten ist Handwerk, aber Handwerk mit Methode. Gewachsene Access-Tabellen bringen typische Altlasten mit: Dubletten, verwaiste Verknüpfungen, Felder, die je nach Jahr anders befüllt wurden, Datumswerte als Text. Das wird nicht händisch geflickt, sondern in einer automatisierten Migrationsroutine behandelt, die man beliebig oft laufen lassen kann.

Das ist der Kern der Methode: Die Migration wird als wiederholbarer Vorgang gebaut und im Probelauf so oft wiederholt, bis sie sauber durchläuft. Nach jedem Lauf wird abgeglichen – Anzahl der Datensätze, Summen über Beträge, Stichproben auf Feldebene. Am Umstellungstag passiert dann nichts Neues mehr, sondern nur noch der x-te Durchlauf einer Routine, die längst bewiesen hat, dass sie funktioniert.

Auch bei einer vergleichsweise kleinen Access-Ablöse raten wir vom harten Schnitt ab. Besser: Die neue Anwendung geht in Betrieb, während die alte Datenbank noch eine Weile mitläuft oder zumindest lesend verfügbar bleibt. Das Team arbeitet im Neuen, kann aber jederzeit im Alten nachsehen, ob eine Zahl von früher stimmt.

Die alte Datei wird dabei schreibgeschützt – sonst entstehen in der Übergangszeit zwei Wahrheiten, und das Zusammenführen danach ist mühsamer als die ganze Migration. Abgeschaltet und archiviert wird sie erst, wenn wochenlang niemand mehr hineingeschaut hat.

Was danach besser ist – und was ungewohnt sein wird

Die Gewinne sind handfest: Eine echte Mehrbenutzer-Datenbank statt einer Datei am Netzlaufwerk, keine Sperrkonflikte, keine Reparaturläufe, tägliche automatische Sicherungen. Zugriff im Browser, also auch im Homeoffice und am Handy. Rollen und Rechte, sodass nicht mehr jeder alles ändern kann. Und eine Anwendung, die dokumentiert ist und die nicht mehr an einer Person hängt.

Ehrlicherweise verlieren Sie auch etwas: die Bastelfreiheit. In Access konnte die versierte Kollegin mal schnell eine Abfrage ändern oder eine Spalte ergänzen. In einer sauber betriebenen Anwendung geht das nicht mehr nebenbei – Änderungen laufen über einen geordneten Weg. Für den Betrieb ist das ein Gewinn an Verlässlichkeit, für einzelne Power-User fühlt es sich zunächst wie ein Verlust an. Das sollte man offen ansprechen und diese Leute früh einbinden: Sie kennen die Anwendung besser als jeder andere und sind die besten Tester, die Sie kriegen können.

Aufwand und Zeitrahmen: eine ehrliche Einordnung

Eine typische Access-Ablöse – eine Anwendung mit einer Handvoll Formularen, gewachsenen Tabellen und etwas VBA-Logik – ist bei uns ein Projekt von etwa sechs bis zwölf Wochen. Die Bandbreite hängt weniger an der Datenmenge als an der Logik: Zehntausende Datensätze umzuziehen ist Routine, dreihundert Zeilen undokumentiertes VBA nachzuvollziehen ist Arbeit.

Ein Rat noch: Nutzen Sie die Ablöse nicht als Anlass, gleichzeitig alle Prozesse umzukrempeln. Erst das Bestehende sauber ins Neue bringen, sodass das Team sich wiederfindet – dann, auf stabilem Fundament, verbessern. Wer beides gleichzeitig will, verdoppelt das Risiko und kann am Ende nicht mehr sagen, ob eine Abweichung ein Migrationsfehler oder eine gewollte Änderung ist.