Access-Datenbank ablösen: Wann es sich lohnt und wie du vorgehst

Access ist selten das Problem. Das Problem ist die Datei, die vor fünfzehn Jahren als Provisorium für die Auftragserfassung entstand und heute Angebote rechnet, Lieferscheine druckt, Provisionen ermittelt und jeden Montag eine Excel-Liste an die Geschäftsführung schickt. Niemand hat das so geplant. Es ist passiert, weil Access genau dafür gebaut wurde: schnell etwas Funktionierendes hinzustellen, ohne IT-Projekt.

Am 13. Oktober 2026 ist der Support für Access 2021 ausgelaufen, und in vielen Unternehmen liegt das Thema deshalb gerade wieder auf dem Tisch. Das Datum ist allerdings nur der Anlass. Die Frist, die wirklich zählt, ist eine andere: der Tag, an dem der Kollege, der die VBA-Module geschrieben hat, in Rente geht oder das Unternehmen verlässt.

Woran du merkst, dass deine Access-Lösung an Grenzen stößt

Access ist eine Desktop-Datenbank. Daten und Anwendung liegen in Dateien (.accdb oder .mdb) auf einem Netzlaufwerk, und jeder Client liest und sperrt direkt in dieser Datei. Fast alle Grenzen, die im Alltag auftauchen, folgen aus dieser einen Architekturentscheidung.

Am harmlosesten ist noch die Versionsfrage. Für Access 2016 und 2019 endete der Support laut Microsoft-Lifecycle am 14. Oktober 2025, für Access 2021 am 13. Oktober 2026. Access selbst ist aber nicht abgekündigt. In Microsoft 365 wird es weiter gepflegt, Office LTSC Professional Plus 2024 hat Mainstream-Support bis Oktober 2029. Ein Versionswechsel löst das Sicherheitsproblem, sonst nichts.

Auf der Roadmap, die das Access-Team im Oktober 2026 vorgestellt hat, stehen Wartung, Sicherheit und Komfortfunktionen. Web-Zugriff, Mandantenfähigkeit oder ein feineres Rechtekonzept gehören nicht dazu, die Architektur bleibt also absehbar, wie sie ist.

Ernster wird es bei der Größe. Die Access-Spezifikationen nennen 2 GB als Obergrenze für eine Datenbankdatei, abzüglich Systemobjekte. Wer Anhänge, Bilder oder Protokolldaten in Access ablegt, erreicht das schneller als gedacht. Mit dem Aufteilen auf mehrere Backend-Dateien oder dem Abspalten von Archiven lässt sich Zeit gewinnen, die Grenze gilt dann für jede einzelne Datei.

Dann die Gleichzeitigkeit. Offiziell sind 255 gleichzeitige Benutzer möglich, ein theoretischer Wert. Weil die Sperrverwaltung über das Dateisystem läuft, wird es in der Praxis deutlich früher zäh, sobald mehrere Personen parallel schreiben. Das Symptom kennt jeder, der damit arbeitet: Die Datenbank hängt, bis irgendwo jemand ein Formular schließt.

Richtig gefährlich wird es im Netz. Microsoft rät in der eigenen Anleitung zur Bereitstellung von Access-Anwendungen davon ab, eine geteilte Access-Datenbank über ein WAN oder Azure-Dateifreigaben zu betreiben, weil die Leistung einbricht und die Datei beschädigt werden kann. Eine VPN-Verbindung ins Büro fällt genau in diese Kategorie. Als unterstützte Alternativen nennt Microsoft Remote Desktop oder ein Server-Backend. Wer seinen Außendienst also per VPN direkt in der Access-Datei arbeiten lässt, betreibt die Lösung außerhalb dessen, wofür sie gebaut ist.

Und am Ende steht das Wissen. Die eigentliche Geschäftslogik liegt in Abfragen, Makros und VBA-Modulen, meist undokumentiert. Wenn genau eine Person weiß, warum der Rabatt im Formular frmAuftrag anders gerechnet wird als im Bericht, hast du ein Klumpenrisiko, das in keiner Bilanz steht.

Weiterbetreiben, stabilisieren, ablösen: die Risikoampel

Nicht jede Access-Datenbank muss weg. Eine Inventarliste, die drei Leute im Lager pflegen, darf gern noch zehn Jahre laufen. Entscheidend sind zwei Achsen: Wie geschäftskritisch ist die Anwendung, und wie gut passt ihre Nutzung noch zur Datei-Architektur?

Die gelbe Stufe wird oft unterschätzt. Microsoft bietet mit dem SQL Server Migration Assistant für Access (SSMA) ein kostenloses Werkzeug für die Access-Migration nach SQL Server oder Azure SQL.

Es überträgt die Tabellen und die meisten Auswahlabfragen (als Views) und verknüpft die Access-Oberfläche auf Wunsch anschließend mit den Server-Tabellen. Formulare, Berichte, Makros, VBA-Module und Aktionsabfragen bleiben in Access und laufen weiter. Soll das Ziel PostgreSQL sein, brauchst du andere Werkzeuge und verknüpfst per ODBC selbst. In beiden Fällen liegen die Daten danach in einer echten Server-Datenbank mit Transaktionen, Backups und Benutzerrechten.

Grenzen hat der Schritt auch. Abfragen, die Access lokal verarbeitet, können über verknüpfte Tabellen langsamer werden, und die VBA-Logik bleibt, wo sie ist. Trotzdem ist er fast immer richtig, auch wenn du langfristig ablösen willst, weil er das Fundament für den Parallelbetrieb legt.

Bei Rot hilft Stabilisieren nur noch als Brücke. Sobald Externe zugreifen oder das System an drei Standorten laufen muss, brauchst du eine Anwendung, die für das Netz gebaut ist.

Bestandsaufnahme in fünf Schritten

Der heikelste Teil einer Access-Ablösung ist das Wissen darüber, was die alte Lösung eigentlich alles tut. Die Bestandsaufnahme ist deshalb der wichtigste Arbeitsschritt des Projekts und zugleich der, den man am liebsten überspringt.

1. Alle Dateien finden. Such auf den Netzlaufwerken nach .accdb, .mdb, .accde und .mde. In der Regel existiert neben der „offiziellen“ Datenbank eine Handvoll Kopien und Satelliten: die Auswertungsdatei vom Controlling, die Exportdatei für den Steuerberater, das Frontend, das jemand lokal angepasst hat. Halte fest, welche Datei mit welcher verknüpft ist und wer sie öffnet.

2. Datenmodell und Datenqualität prüfen. Welche Tabellen gibt es, welche Beziehungen sind definiert, wo fehlt referenzielle Integrität? In gewachsenen Datenbanken findest du typischerweise Kundendubletten, Freitextfelder, in denen Zahlen stehen, und Tabellen namens tblAuftrag_alt2. Das ist die Ausgangslage, die den Aufwand der Migration bestimmt.

3. Die Logik ausgraben. Access bringt unter Datenbanktools den Datenbankdokumentierer mit, der Tabellen, Abfragen, Formulare, Berichte, Makros und Module auflistet. Das ist der Startpunkt. Die eigentliche Arbeit beginnt danach, denn Geschäftsregeln verstecken sich gern in Ereignisprozeduren von Formularen. Ein vereinfachtes, typisches Beispiel:

' Formular frmAuftrag: Rabatt wird nach jeder Änderung der Menge berechnet
Private Sub txtMenge_AfterUpdate()
    If Me.txtKundengruppe = "B" And Me.txtMenge >= 50 Then
        Me.txtRabatt = 0.08          ' Staffelrabatt nur für Kundengruppe B
    ElseIf Month(Date) = 12 Then
        Me.txtRabatt = 0.05          ' Dezember-Aktion, irgendwann "vorübergehend" eingeführt
    Else
        Me.txtRabatt = 0
    End If
End Sub

Die Regel greift nur, wenn jemand das Formular benutzt, nicht beim Import aus Excel, und der Bericht rechnet womöglich mit einer eigenen Abfrage etwas anderes. Genau solche Stellen musst du finden, aufschreiben und mit dem Fachbereich klären: Ist das gewollt, oder ist es ein Fossil?

4. Schnittstellen erfassen. Access-Lösungen sind selten Inseln. Typisch sind Excel-Importe per Makro, Serienbriefe über Word, E-Mails per Outlook-Automation, ODBC-Verbindungen ins ERP oder eine CSV-Datei, die nachts ein anderes Programm abholt. Jede dieser Verbindungen braucht im Zielsystem einen Gegenpart oder fällt bewusst weg.

5. Nutzer und tatsächliche Nutzung klären. Sprich mit den Leuten, die täglich damit arbeiten. Welche Formulare benutzen sie wirklich, welche Berichte druckt noch jemand aus, wo gibt es Workarounds am System vorbei? Häufig zeigt sich dabei, dass einige Berichte seit Jahren niemand mehr öffnet. Was nicht migriert werden muss, ist die günstigste Zeile im Budget.

Am Ende steht ein Dokument mit Datenmodell, Geschäftsregeln, Schnittstellen und Nutzerrollen. Im Kern ist das ein Lastenheft, und ohne eines ist jedes Angebot für eine Access-Ablösung geraten. Wie du es aufbaust, zeigt unser Leitfaden zu Lastenheft und Pflichtenheft.

Zielbild Web-App und Parallelbetrieb

Für die meisten Access-Lösungen mit roter Ampel ist das Ziel eine Web-Anwendung mit drei Schichten: eine relationale Server-Datenbank (PostgreSQL oder SQL Server), ein Backend mit einer API, in der die Geschäftsregeln leben, und eine Oberfläche im Browser.

Dazu kommt, was Access nie richtig konnte: Rollen und Rechte bis auf Datensatzebene, ein Änderungsprotokoll, Anmeldung über das Firmenkonto (SSO) und Zugriff von überall ohne VPN. Die Rabattregel aus frmAuftrag steht dann an genau einer Stelle im Backend und gilt für Formular, Import und Bericht gleichermaßen.

Bevor du Access ersetzen lässt, prüf kurz die Alternativen. Ist dein Prozess Standard, etwa Zeiterfassung, CRM oder Lagerverwaltung, deckt ihn wahrscheinlich fertige Software ab; die Abwägung steht in unserer Entscheidungsmatrix SaaS vs. Individualsoftware.

Microsofts Cloud-Variante, Dataverse als Backend mit Access als Oberfläche, verlagert die Daten, lässt das Frontend aber, wie es ist, und kommt in der Vollversion mit Power-Apps-Lizenzen pro Nutzer. Für einfache Formular-Anwendungen ist das eine Option, das Kernproblem der gewachsenen VBA-Logik löst es nicht. Bildet die Access-Lösung dagegen genau das ab, was dein Unternehmen von anderen unterscheidet, etwa eine eigene Kalkulationslogik oder einen speziellen Fertigungsablauf, ist Individualsoftware die bessere Wahl.

Der riskanteste Fehler bei der Umsetzung ist der Big Bang: Freitag Access abschalten, Montag die neue Anwendung starten. Bei Systemen, an denen das Tagesgeschäft hängt, tauchen im Alltag Sonderfälle auf, die in keiner Anforderung standen, und dann gibt es keinen Weg zurück. Ein Parallelbetrieb in drei Phasen ist der sicherere Weg.

Phase 1: Daten umziehen. Die Tabellen wandern auf den Datenbankserver, Access bleibt über verknüpfte Tabellen die Oberfläche. Für die Nutzer ändert sich fast nichts. Für dich ändert sich viel, denn die Daten liegen jetzt dort, wo auch die neue Anwendung sie lesen kann.

Phase 2: Modul für Modul ablösen. Die Web-App übernimmt einen abgegrenzten Bereich nach dem anderen, zum Beispiel zuerst die Angebotserstellung, dann die Auftragserfassung, zuletzt die Auswertungen. Beide Systeme arbeiten auf derselben Datenbank, deshalb braucht es eine harte Regel, welches System welche Tabellen schreiben darf.

Die Rabattregel aus Schritt 3 zeigt, wo das heikel wird. Angenommen, der Fachbereich hat die Dezember-Aktion bei der Bestandsaufnahme gestrichen und das neue Backend kennt sie nicht mehr. Ändert im Dezember jemand im alten Access-Formular die Menge eines Auftrags, setzt txtMenge_AfterUpdate trotzdem 5 % Rabatt und speichert ihn in der gemeinsamen Datenbank. Die Web-App, in der die Angebote schon entstehen, rechnet ohne Aktion, und Angebot und Auftrag nennen für denselben Vorgang zwei verschiedene Preise.

Lass deshalb in der Übergangszeit beide Berechnungen gegeneinander laufen und gleiche Abweichungen ab, bevor das alte Modul abgeschaltet wird.

Das Muster dahinter heißt in der Softwarearchitektur Strangler Fig, benannt nach der Würgefeige, die um einen Baum herumwächst, bis sie ihn ersetzt hat. Die klassische Variante setzt eine Fassade vor das Altsystem, bei Access ist die gemeinsame Datenbank der praktischere Hebel. Die Fassaden-Variante und die Regel „ein schreibendes System pro Tabelle“ erklären wir in unserem Beitrag zu Refactor, Strangler und Rebuild.

Phase 3: Access abschalten. Ist das letzte Modul umgezogen, wird Access auf Lesezugriff gestellt, nach einer vereinbarten Frist archiviert und dann entfernt. Den Archivstand aufzubewahren lohnt sich, falls bei einer Prüfung jemand nach alten Berechnungen fragt.

Kurz gesagt: erst die Daten befreien, dann die Oberfläche ersetzen, zuletzt das Alte abschalten. Dein Geschäft läuft währenddessen weiter, und jede Phase bringt für sich schon einen Nutzen.

Checkliste und Access-Check: Solltest du deine Access-Datenbank ablösen?

Bevor du ein Budget beantragst oder Angebote einholst, beantworte diese Fragen für deine Access-Lösung:

• Welche Prozesse stehen still, wenn die Datenbank einen Tag nicht erreichbar ist?
• Wie viele Personen arbeiten gleichzeitig darin, und wie viele davon über VPN oder von anderen Standorten?
• Wie groß ist die Backend-Datei, und wie schnell ist sie im letzten Jahr gewachsen?
• Wer kann den VBA-Code ändern, und gibt es dafür eine Vertretung?
• Welche Access-Version läuft, und bekommt sie noch Sicherheitsupdates?
• Welche anderen Systeme lesen oder schreiben Daten der Datenbank?
• Speichert die Datenbank personenbezogene Daten, und wer darf welche sehen?
• Wann gab es die letzte Beschädigung, und wie lange hat die Reparatur gedauert?

Wenn dich mehr als zwei Antworten unruhig machen, lohnt eine strukturierte Einordnung. Unser kostenloser Legacy-Check stellt sechs Fragen zu Technik, Wartung, Betrieb und Dokumentation und liefert in zwei Minuten einen Risiko-Score samt passendem Modernisierungspfad. Access- und VBA-Lösungen sind dort ausdrücklich als typisches Altsystem aufgeführt. Wie wir Altsysteme ablösen und dabei den laufenden Betrieb absichern, besprechen wir gern an deinem konkreten Fall.

Der wichtigste erste Schritt kostet allerdings kein Budget. Es ist ein Termin mit der Person, die den VBA-Code geschrieben hat, solange sie noch im Haus ist. Herauskommen sollte eine Liste aller Regeln, die bisher nur sie kennt.