Fast jede Access-Datenbank fängt klein an. Eine Tabelle, ein paar Formulare, schnell zusammengeklickt, um ein konkretes Problem zu lösen. Zehn Jahre später steuert genau diese Datei einen Kernprozess der Firma, hängt in einem Netzlaufwerk, und wenn zwei Leute gleichzeitig speichern, beten alle, dass nichts kaputtgeht.
Wir machen aus dieser gewachsenen Access-Lösung eine richtige Web-Anwendung: mehrbenutzerfähig, von überall erreichbar, mit sauberer Datenhaltung. Backend in Python mit PostgreSQL (alternativ .NET), Frontend in React mit TypeScript.
Automatisiertes Code-Assessment anfragen →
Warum Access irgendwann an die Wand fährt
Access ist nicht für das gebaut, wofür es am Ende benutzt wird. Die typischen Grenzen kennen Sie wahrscheinlich aus eigener Erfahrung:
- Mehrbenutzerbetrieb. Eine
.mdb– oder.accdb-Datei auf dem Netzlaufwerk verträgt nur wenige gleichzeitige Nutzer, bevor es zu Sperren, Beschädigungen und Datenverlust kommt. - Kein echter Fernzugriff. Homeoffice oder mehrere Standorte? Mit Access wird das zur Bastelei aus VPN und Workarounds.
- VBA-Wissen schwindet. Die Makros und Module, in denen die eigentliche Logik steckt, versteht oft nur noch eine Person.
- Datei statt Datenbank. Eine einzelne Datei als Herz eines Geschäftsprozesses ist ein Single Point of Failure. Ein Backup zu spät, und die Arbeit von Tagen ist weg.
Das Wertvolle steckt im VBA-Code
Die Tabellen sind selten das Problem. Wertvoll – und knifflig – ist die Logik in den VBA-Modulen: Berechnungen, Prüfregeln, automatisierte Abläufe, die über Jahre gewachsen sind und nirgends dokumentiert wurden. Genau dieses Wissen darf bei der Migration nicht verloren gehen.
Wir lesen den VBA-Code, machen die darin versteckten Regeln explizit und überführen sie in saubere Service-Logik im neuen Backend. Was vorher in einem Makro vergraben war, wird zu nachvollziehbarem, testbarem Code.
Die Daten: von MDB/ACCDB zu einer echten Datenbank
Access-Daten werden auf eine relationale Datenbank überführt, die für Mehrbenutzerbetrieb gemacht ist. Dabei bereinigen wir, was sich über die Jahre angesammelt hat: doppelte Datensätze, inkonsistente Formate, Felder, die mal so und mal anders befüllt wurden. Das Ziel ist nicht, das Chaos eins zu eins zu übernehmen, sondern ein sauberes Datenmodell, auf dem die neue Anwendung verlässlich arbeitet.
Was Sie nach der Migration gewinnen
Der Sprung von Access ins Web ist mehr als ein Technologiewechsel. Plötzlich können beliebig viele Mitarbeiter gleichzeitig arbeiten, ohne sich gegenseitig die Datei zu sperren. Zugriff geht vom Büro, vom Homeoffice, vom zweiten Standort. Rechte lassen sich vergeben, Änderungen nachvollziehen. Und die Anwendung läuft auf einem System, für das es am Markt Entwickler gibt.
Wie wir vorgehen
- Analyse. Tabellen, Formulare, Berichte und vor allem die VBA-Module werden kartiert.
- Architektur. Relationales Datenmodell, Rechtekonzept, Zielbild auf Python + PostgreSQL (alt. .NET) mit React-Frontend.
- Umsetzung. VBA-Logik wird in Services überführt, Formulare werden zu React-Oberflächen.
- Datenmigration. Von MDB/ACCDB auf die neue Datenbank, mit Bereinigung.
- Qualitätssicherung. Abnahme der Fachlogik gegen das Verhalten der Access-Lösung.
Schrittweise, nicht über Nacht. Ihre Access-Datei bleibt nutzbar, bis die Web-Anwendung jede Funktion übernommen hat.
Vertiefung
- Access in eine Web-Anwendung umwandeln – wie aus Formularen und Berichten eine Web-Oberfläche wird.
- VBA ablösen – was mit der Makro- und Modul-Logik passiert.
Verwandte Technologien
Access steht oft nicht allein. Im Windows-Umfeld teilt es sich die Bühne mit VB6 und Delphi – viele VB6-Anwendungen nutzen sogar dieselbe Access-Datei als Datenspeicher. Und mit Visual FoxPro teilt Access die Grundproblematik der dateibasierten Datenbank. Wo mehrere dieser Systeme zusammenspielen, planen wir die Migration gemeinsam.
Häufige Fragen
Geht die Logik aus unseren VBA-Makros verloren? Nein. Genau diese Logik ist der wertvolle Teil. Wir machen sie explizit und überführen sie in sauberen Code.
Unsere Access-Datei ist über die Jahre unsauber geworden. Ist das ein Problem? Das ist der Normalfall. Datenbereinigung gehört fest zur Migration.
Können danach mehr Leute gleichzeitig arbeiten? Ja, das ist einer der Hauptgewinne. Die Web-Anwendung ist von Grund auf für Mehrbenutzerbetrieb gebaut.
Der erste Schritt: automatisiertes Code-Assessment anfragen →