Migration von Access zu SQL Server – Stand September 2026

1 Executive Summary

Microsoft Access ist in vielen Unternehmen das, was der Keller für den Privathaushalt ist: Da steht Zeug, das niemand mehr angefasst hat, aber wehe, man wirft es weg. Über Jahre gewachsene Access-Datenbanken tragen Kernprozesse – Angebotskalkulation, Reklamationsverwaltung, Produktionsplanung – und sie tun das mit einer Dateidatenbank, die auf einer Netzwerkfreigabe liegt, 2 GB nie überschreiten darf und bei jedem WLAN-Aussetzer beschädigt werden kann.

Die Migration der Datenhaltung nach SQL Server ist der pragmatischste Ausweg: Die Anwendung (Formulare, Berichte, VBA) bleibt in Access, die Tabellen wandern auf eine echte Server-Engine mit Transaktionsprotokoll, Backup, Rechteverwaltung und Skalierung. Das Werkzeug dafür ist der SQL Server Migration Assistant for Access (SSMA), das Bindeglied sind verknüpfte Tabellen über ODBC.

Die Erfahrung aus zahlreichen Projekten zeigt: Die reine Datenmigration ist ein Nachmittag. Der Aufwand steckt in der Bereinigung vorher (Primärschlüssel, Datentypen, mehrwertige Felder, Anlagen) und in der Anwendungsanpassung danach (Abfragen, die plötzlich Millionen Zeilen über das Netz ziehen; Formulare, die „#Gelöscht“ anzeigen; VBA, das ohne dbSeeChanges stolpert). Wer das unterschätzt, erlebt die klassische Enttäuschung: „Seit der Migration ist alles langsamer.“

Kernaussagen

Datenhaltung ja, Anwendung optional: Die Migration nach SQL Server ist fast immer der erste Schritt – auch wenn die Access-Oberfläche später durch Power Apps oder eine .NET-Anwendung abgelöst werden soll.

SSMA ist gut, aber kein Autopilot: Typmapping, rowversion-Spalten, Yes/No-Felder und Beziehungen wollen bewusst entschieden werden.

Performance ist Architektur, nicht Hardware: Pass-Through-Abfragen, Views und gefilterte Formulare machen den Unterschied, nicht ein schnellerer Server.

Access Services sind Geschichte: Access Web Apps auf SharePoint sind eingestellt und keine Zielplattform mehr – die Alternativen heißen Power Apps/Dataverse oder klassische Entwicklung.

Lizenz und Betrieb: SQL Server 2025 Express deckt mit 50 GB je Datenbank (vorher 10 GB) praktisch jeden Access-Nachfolger kostenlos ab; Standard Edition darf jetzt 32 Kerne und 256 GB Puffer. Zielversion ist SQL Server 2025 – seit November 2025 GA, inzwischen mit mehreren kumulativen Updates gereift.

Der 13. Oktober 2026 steht vor der Tür: Support-Ende für Access und Office 2021, sechs Wochen nach Stand dieses Dokuments. Access 2016/2019 sind seit Oktober 2025 ohne Updates. Wer heute noch Access-Frontends auf solchen Clients betreibt, hat neben der Datenbank ein zweites Problem – Client-Rollout und Migration gehören in ein Projekt.

KI hilft bei der Anpassung, nicht bei der Entscheidung: Access-SQL nach T-SQL übersetzen, VBA auf ODBC-Fallen prüfen, Views und Prozeduren generieren, Testkataloge schreiben – das erledigen Sprachmodelle und agentische Werkzeuge (Claude Code, GitHub Copilot Agent Mode in SSMS 22) 2026 zuverlässig. Typmapping, Schlüsseldesign, Gate A und Cutover bleiben Handarbeit.

 

☕ Aus der Praxis Ein mittelständischer Zulieferer hatte 14 Access-Datenbanken „im Umlauf“, davon drei geschäftskritisch. Die eigentliche Migration der drei Datenbanken dauerte inklusive Test vier Beratertage. Die Inventur und Bereinigung vorher: sieben. Und die Diskussion, welche der anderen elf Datenbanken man einfach abschalten kann: zwei Workshops und ein Kuchen.

2 Ausgangssituation und Scope

Typische Ausgangslage

Dieses Dokument beschreibt das Vorgehen für Access-Datenbanken (.mdb/.accdb), die als Fachanwendung im Mehrbenutzerbetrieb eingesetzt werden. Die typischen Symptome, die ein Migrationsprojekt auslösen:

Datenbankdatei nähert sich der 2-GB-Grenze oder muss regelmäßig komprimiert werden.

Wiederkehrende Beschädigungen („Nicht erkennbares Datenbankformat“, verwaiste .laccdb-Sperrdateien).

Sperrkonflikte und Schreibkonflikte ab etwa 10 bis 15 gleichzeitigen Benutzern.

Kein sauberes Backup: Die Datei wird im laufenden Betrieb kopiert und ist im Restore-Fall inkonsistent.

Compliance: Kein Rechtekonzept, keine Protokollierung, jeder Benutzer mit Netzlaufwerkzugriff hat Vollzugriff auf alle Daten.

Homeoffice und VPN: Access über WAN-Latenz ist praktisch unbenutzbar.

Integration: Andere Systeme (Power BI, ERP-Schnittstellen, Web-Portale) sollen auf die Daten zugreifen.

Scope dieses Dokuments

Im Scope	Nicht im Scope
Migration der Tabellen und Daten nach SQL Server 2019/2022 (on-premises) oder Azure SQL Database	Neuentwicklung der Anwendungsoberfläche (wird als Alternative bewertet, nicht ausgeführt)
Anbindung des bestehenden Access-Frontends über ODBC (verknüpfte Tabellen)	Migration nach anderen Datenbanksystemen (PostgreSQL, MySQL)
Anpassung von Abfragen, Formularen und VBA für den Serverbetrieb	Betriebskonzept für SQL Server im Detail (Wartungspläne, HA/DR) – nur soweit für die Migration relevant
Bewertung der Alternativen Power Apps/Dataverse, SharePoint-Listen, Neubau	Lizenzberatung im Einzelfall (Hinweise ja, Preise nein)
Typische Fallen und deren Vermeidung	Access Services/Access Web Apps – nur als Randnotiz, da eingestellt

 

Annahmen

Access 2016 oder neuer beziehungsweise Access aus Microsoft 365 Apps ist im Einsatz; Bitness (32/64 Bit) ist bekannt.

Ein SQL Server (mindestens Express) kann bereitgestellt werden, oder Azure SQL ist organisatorisch zulässig.

Die Fachbereiche stehen für Test und Abnahme zur Verfügung – Access-Migrationen ohne die „Eigner“ der Datenbank scheitern regelmäßig an unbekannten Sonderfällen.

 

⚠ Randnotiz: Access Services Access Services (Access Web Apps auf SharePoint 2010/2013/2016 und SharePoint Online) sind keine Option. Microsoft hat die Erstellung neuer Web Apps in SharePoint Online 2017 gestoppt und den Dienst 2018 abgeschaltet; SharePoint Server 2019 und Subscription Edition enthalten die Access Services nicht mehr. Wer noch Access-Web-App-Reste auf einem SharePoint 2016 betreibt, migriert deren Daten – die liegen ohnehin in einer SQL-Server-Datenbank – und baut die Oberfläche neu, sinnvollerweise in Power Apps.

3 Technischer Hintergrund

Dieses Kapitel liefert das Warum. Wer versteht, wie Access mit einem SQL Server spricht, erkennt die meisten Fallen aus Kapitel 4 von selbst.

3.1 Architektur: Monolith, Split, Zielbild

Access kann in drei Ausbaustufen betrieben werden. Die meisten Bestandsanwendungen stecken in Stufe 0 oder 1; Stufe 2 ist das Ziel dieses Dokuments.

Skizze 1: Vom Access-Monolithen zum Zielbild – die Anwendung bleibt, die Datenhaltung wandert.

Der Frontend/Backend-Split (Stufe 1) ist Voraussetzung für die Migration: Erst wenn Tabellen und Anwendungsobjekte getrennt sind, lassen sich die Tabellen austauschen, ohne Formulare und Code zu berühren. Ist der Split noch nicht erfolgt, ist er die erste Maßnahme (siehe Kapitel 5). In Stufe 2 ersetzt SQL Server die Backend-Datei; das Frontend enthält statt lokaler Tabellen verknüpfte Tabellen, die per ODBC auf den Server zeigen.

3.2 Wie Access mit SQL Server spricht

Access nutzt seine eigene Datenbank-Engine (ACE, früher Jet) als Vermittler. Eine verknüpfte Tabelle ist aus Sicht von ACE eine „fremde“ Datenquelle, die über einen ODBC-Treiber angesprochen wird. Das hat drei Konsequenzen, die man kennen muss:

Abfrageübersetzung: ACE versucht, Access-SQL in T-SQL zu übersetzen und an den Server zu senden. Gelingt das nicht (VBA-Funktionen, Access-eigene Funktionen wie Nz oder Format, Joins mit lokalen Tabellen), holt ACE die Rohdaten und verarbeitet lokal.

Zeilenidentifikation: Access braucht einen eindeutigen Schlüssel, um Zeilen zu aktualisieren. Ohne Primärschlüssel oder eindeutigen Index ist die verknüpfte Tabelle schreibgeschützt.

Optimistische Sperrung: Access schreibt eine Änderung als UPDATE … WHERE alle Spalten alte Werte. Bei Gleitkommazahlen und Textfeldern führt das zu Schreibkonflikten. Eine rowversion-Spalte (Datentyp timestamp) ändert das Verhalten: Access vergleicht dann nur noch Schlüssel und rowversion.

ODBC-Treiber

Treiber	Status April 2024	Empfehlung
„SQL Server“ (sqlsrv32.dll, Windows-Bordmittel)	Uralt, kennt keine neuen Typen (datetime2 wird als Text geliefert), kein TLS 1.2 in älteren Windows-Versionen	Nicht verwenden
SQL Server Native Client 11.0	Deprecated, kein Support mehr	Nicht verwenden
ODBC Driver 17 for SQL Server	Weiter gepflegt (17.11.x, 2026), Verschlüsselung optional, keine neuen Funktionen	Nur noch Übergangslösung; Neuinstallationen mit 18
ODBC Driver 18 for SQL Server	Standard (18.5.x); Encrypt=yes voreingestellt; TDS 8.0 mit Encrypt=strict produktionsreif; Entra-Auth für SQL Server 2025 on-premises	Empfohlen; Zertifikat aus der PKI vorab, dann Encrypt=strict (Falle 4.1.4)

 

ℹ Bitness ist nicht verhandelbar Ein 32-Bit-Access braucht den 32-Bit-ODBC-Treiber, ein 64-Bit-Access den 64-Bit-Treiber. Beide Treiber können parallel installiert sein. Der ODBC-Administrator existiert ebenfalls doppelt (odbcad32.exe unter System32 ist der 64-Bit-, unter SysWOW64 der 32-Bit-Administrator). Wer DSN-los verknüpft, braucht den ODBC-Administrator ohnehin nur zum Testen.

 

DSN oder DSN-los?

Eine System- oder Benutzer-DSN muss auf jedem Client eingerichtet werden – bei 40 Arbeitsplätzen ein Pflegealbtraum. DSN-lose Verbindungen tragen alle Parameter in der Verbindungszeichenfolge der verknüpften Tabelle; sie werden beim Start des Frontends per VBA gesetzt (Relink-Routine, Maßnahme 8). Beispiel:

ODBC;DRIVER={ODBC Driver 17 for SQL Server};SERVER=SQL01\ACCESS;DATABASE=Reklamation;Trusted_Connection=Yes;

3.3 Datentypen: Das Mapping entscheidet über Ruhe oder Ärger

SSMA schlägt ein Standardmapping vor. Es ist meist brauchbar, aber an einigen Stellen sollte man bewusst abweichen:

Access-Typ	SSMA-Standard	Empfehlung	Hinweis
AutoWert (Long)	int IDENTITY	int IDENTITY(1,1)	Zählerlücken sind normal; DAO braucht dbSeeChanges
AutoWert (Replikations-ID)	uniqueidentifier	uniqueidentifier mit DEFAULT NEWSEQUENTIALID()	Als Clustered Key ungünstig – Fragmentierung
Ja/Nein	bit	bit NOT NULL DEFAULT 0	NULL in bit-Spalten führt in Access zu Anzeige-/Filterproblemen
Zahl (Long Integer)	int	int	unkritisch
Zahl (Double)	float	float oder decimal	Gleitkomma erzeugt Schreibkonflikte ohne rowversion
Zahl (Dezimal)	decimal(p,s)	decimal(p,s) prüfen	Access-Dezimal hat eigene Grenzen, Skalierung nachprüfen
Währung	money	decimal(19,4)	money rundet in Berechnungen unangenehm
Datum/Uhrzeit	datetime2 (neuere SSMA) / datetime	datetime oder datetime2(3)	datetime2 nur mit ODBC Driver 13+; datetime reicht für Access-Bereich meist
Datum/Uhrzeit erweitert	datetime2(7)	datetime2(7)	Nur Access 2019+/M365
Kurzer Text (255)	nvarchar(255)	nvarchar(n) nach Bedarf	Leerstring vs. NULL beachten (Falle 4.2.3)
Langer Text (Memo)	nvarchar(max)	nvarchar(max)	Rich-Text bleibt HTML-Markup im Text
OLE-Objekt	varbinary(max)	varbinary(max) oder Dateiablage	Oft besser: Dateien ins Dateisystem, Pfad in die DB
Anlage	nicht unterstützt	eigene Tabelle varbinary(max) + Metadaten	Vor der Migration auflösen
Mehrwertiges Feld (MVF)	nicht unterstützt	Zwischentabelle (n:m)	Vor der Migration auflösen
Hyperlink	nvarchar(max)	nvarchar(max) + FE-Anpassung	Verliert die Hyperlink-Semantik
Berechnetes Feld	nicht unterstützt	Computed Column oder View	Formel nach T-SQL übersetzen

 

⚠ Die drei Klassiker, die jede Migration bremsen 1. Fehlender Primärschlüssel: Verknüpfte Tabelle ist schreibgeschützt oder zeigt „#Gelöscht“. 2. Ja/Nein-Felder als NULL-fähiges bit: Filter „= Falsch“ findet die NULL-Zeilen nicht, Kontrollkästchen zeigen den unbestimmten Zustand. 3. Fehlende rowversion-Spalte: Schreibkonflikte („Die Daten wurden von einem anderen Benutzer geändert“) bei Double-, Memo- oder bit-Spalten – auch wenn niemand sonst eingeloggt ist.

 

3.4 Vorgehensmodell

Skizze 2: Vorgehensmodell mit Entscheidungspunkten.

Die sechs Phasen sind in Kapitel 5 als konkrete Maßnahmen ausgearbeitet. Wichtig sind die drei Gates: Nach der Bereinigung wird bewusst entschieden, ob die Migration in dieser Form Sinn hat oder ob ein Neubau günstiger ist (Gate A). Vor dem Cutover muss der Fachbereich auf einer Testumgebung abgenommen haben (Gate B). Der Cutover selbst findet in einem Wartungsfenster statt, mit definiertem Rollback (Gate C).

3.5 Performance: Wo die Zeit wirklich bleibt

Der häufigste Einwand nach einer Migration lautet: „Vorher war es schneller.“ Das stimmt gelegentlich sogar – und liegt fast nie am Server. Skizze 4 zeigt den Mechanismus.

Skizze 4: Lokale versus serverseitige Verarbeitung.

Bei einer lokalen Backend-Datei liest ACE die Tabellenseiten direkt von der Freigabe und filtert lokal – das ist bei 50.000 Zeilen schnell genug. Am SQL Server zieht dasselbe Vorgehen jede Zeile einzeln über den ODBC-Kanal. Die Lösung besteht darin, Filter und Joins zum Server zu verlagern:

Technik	Wann einsetzen	Einschränkung
Pass-Through-Abfrage	Berichte, Listen, Auswertungen, Massenoperationen	Schreibgeschützt; T-SQL statt Access-SQL; Parameter per VBA setzen
View als verknüpfte Tabelle	Komplexe Joins, die in Formularen aktualisierbar bleiben sollen	Beim Verknüpfen eindeutigen Index angeben, sonst schreibgeschützt
Stored Procedure	Geschäftslogik, Massenupdates, Löschkaskaden	Aufruf per Pass-Through oder ADO; Rückgabe von Recordsets möglich
Formular mit WhereCondition	Bearbeitungsformulare	Recordsource darf nicht die ganze Tabelle sein; Öffnen mit Filter
Lokale Nachschlagetabellen	Kombinationsfelder mit stabilen Stammdaten	Aktualisierung beim FE-Start (kleine Tabellen kopieren)
dbSeeChanges / dbOpenDynaset	Alle DAO-Recordsets auf Tabellen mit IDENTITY	Pflicht, sonst Laufzeitfehler 3622

 

⚠ 25.000 holen, 4 behalten – was der Server dabei erleidet In Access ist es gelebte Praxis, ein Formular oder Kombinationsfeld auf die komplette Tabelle zu setzen und dann per Filter, Suchfeld oder VBA-Schleife auf die vier Zeilen zu kommen, die man eigentlich wollte. Gegen eine lokale Backend-Datei fällt das kaum auf. Gegen einen SQL Server ist es nicht nur langsam, sondern schädlich – und zwar nicht nur für den einen Anwender: Table Scans statt Index Seeks: Der Server liest die gesamte Tabelle, bei jedem Öffnen, für jeden Benutzer. Indizes helfen nicht, weil keine WHERE-Klausel ankommt. Buffer Pool wird geflutet: Bei SQL Server Express (1,4 GB Puffer) verdrängen 25.000 vollständige Zeilen alles andere aus dem Cache – die nächste Abfrage geht wieder auf die Platte. Sperren und Blockierungen: Access hält beim Durchblättern Shared Locks auf gelesenen Seiten; ein Update eines Kollegen wartet. Bei 20 Anwendern mit offenen Formularen entstehen Blockierungsketten, die kein Admin dem Access-Frontend zuordnet. Netz und CPU: 25.000 Zeilen mal 30 Formulare mal 40 Anwender – der Server verbringt den Tag mit dem Serialisieren von Datensätzen, die niemand ansieht. Kollateralschaden: Läuft die Datenbank auf einer gemeinsam genutzten Instanz (ERP, Web-Anwendung), leidet die gesamte Instanz unter dem einen schlecht gebauten Client. Aus einer Access-Migration wird dann ein Ticket beim ERP-Team. Faustregel für die Anwendungsanpassung: Kein Formular, keine Rowsource und kein Recordset darf ohne serverseitigen Filter geöffnet werden, der die Ergebnismenge auf das beschränkt, was der Anwender tatsächlich sieht. Was der Anwender nicht sieht, darf den Server nicht verlassen.

 

3.6 Sicherheit und Authentifizierung

Mit der Migration entsteht erstmals ein echtes Rechtekonzept. Empfohlen wird die integrierte Windows-Authentifizierung über AD-Gruppen: Eine Gruppe „APP_Reklamation_Benutzer“ erhält db_datareader/db_datawriter beziehungsweise besser gezielte Rechte auf Views und Prozeduren; eine Gruppe „APP_Reklamation_Admins“ mehr. SQL-Authentifizierung mit einem gemeinsamen Konto, das im VBA steht, ist die schlechteste Variante – das Kennwort liegt dann im Klartext in jeder Frontend-Kopie.

Azure SQL: Entra-ID-Authentifizierung (Active Directory Interactive oder Integrated) wird von ODBC Driver 17/18 unterstützt; Access übergibt die Parameter in der Verbindungszeichenfolge.

Transportverschlüsselung: ODBC Driver 18 verschlüsselt standardmäßig. Auf dem SQL Server sollte ein von der internen PKI ausgestelltes Zertifikat hinterlegt sein, sonst scheitert die Verbindung an der Zertifikatsprüfung.

Frontend-Schutz: Das Access-Frontend selbst bleibt weich – als .accde kompilieren, Navigationsbereich ausblenden, aber keine Illusionen: Die Sicherheit liegt im SQL Server, nicht in Access.

3.7 Alternativen zur Access-Oberfläche

Die Datenmigration nach SQL Server ist fast immer richtig. Ob das Access-Frontend bleibt, ist eine eigene Entscheidung.

Skizze 3: Entscheidungspfad Zielplattform.

Option	Stärken	Schwächen	Passt, wenn …
Access-FE auf SQL Server (Standardpfad)	Geringster Aufwand, Fachbereich kennt die Oberfläche, VBA-Logik bleibt	Access-Client nötig, WAN-Latenz, keine Web-/Mobilnutzung	… die Anwendung funktional passt und die Benutzer im LAN oder per RDS/AVD arbeiten
Azure SQL Database / Managed Instance	Kein eigener Server, Backup und HA inklusive, Entra-ID-Auth	Latenz für Access-Clients spürbar; Kosten laufend; Datenschutzprüfung	… Cloud gesetzt ist und Clients über AVD/Cloud PC nahe an der Datenbank laufen
Power Apps + Dataverse	Web und mobil, Rechtekonzept, Low-Code, Integration in M365	Premium-Lizenzen, Dataverse-Grenzen, Reports schwächer als Access	… die Anwendung Formular- und Listen-zentriert ist und Mobilität gewünscht ist
Power Apps auf SQL Server	SQL bleibt Datenquelle, Access-FE parallel möglich	Premium-Connector nötig, Delegierungsgrenzen	… ein schrittweiser Umstieg mit Parallelbetrieb gewünscht ist
Neubau .NET (Blazor/WPF/ASP.NET Core)	Volle Kontrolle, Performance, Web	Höchster Aufwand, Entwicklerkapazität	… die Fachlogik komplex ist und die Anwendung strategisch ist
SharePoint-Listen als Access-Backend	Ohne Server, ohne Lizenzkosten	Keine Relationen mit Integrität, 5000-Elemente-Schwellen, langsam	… es eine Kleinstlösung mit wenigen Tabellen ist – sonst nicht
Access Services / Web Apps	–	Eingestellt	nie

 

✔ Empfehlung Daten zuerst, Oberfläche später. Wer SQL Server als Datenhaltung etabliert, hat alle Türen offen: Das Access-Frontend läuft weiter, Power Apps und Power BI können sofort andocken, und ein späterer Neubau findet saubere, dokumentierte Tabellen vor. Wer dagegen mit dem Neubau der Oberfläche beginnt, hat zwei Baustellen gleichzeitig.

4 Analysebefunde: Typische Fallen und ihre Bewertung

Die folgenden Befunde stammen aus wiederkehrenden Migrationsprojekten. Sie sind nach Schwere klassifiziert: Kritisch verhindert den Betrieb oder gefährdet Daten, Mittel kostet Zeit und Nerven, Niedrig ist Kosmetik mit Spätfolgen.

4.1 Kritische Befunde

Nr.	Schwere	Befund	Auswirkung	Gegenmaßnahme
4.1.1	Kritisch	Tabellen ohne Primärschlüssel	Verknüpfte Tabelle schreibgeschützt, Anzeige „#Gelöscht“, Formulare nicht editierbar	Vor Migration Schlüssel ergänzen (AutoWert); SSMA meldet betroffene Tabellen
4.1.2	Kritisch	Kein Frontend/Backend-Split	Tabellen können nicht ausgetauscht werden; jede FE-Änderung berührt Daten	Maßnahme 2: Split mit dem Assistenten oder manuell
4.1.3	Kritisch	Mehrwertige Felder und Anlagefelder	SSMA migriert sie nicht oder nur als Text; Datenverlust droht	Vorab in Zwischen- beziehungsweise Anlagentabellen auflösen
4.1.4	Kritisch	ODBC Driver 18 mit selbstsigniertem Serverzertifikat	Verbindung scheitert mit SSL-Zertifikatsfehler, Anwendung startet nicht	PKI-Zertifikat auf SQL Server; übergangsweise TrustServerCertificate=yes oder Driver 17
4.1.5	Kritisch	Alte Backend-Datei nach Cutover weiter beschreibbar	Benutzer mit alter FE-Kopie schreiben in die alte Datei – Datenspaltung	Alte BE umbenennen/schreibschützen, FE-Versionsprüfung beim Start
4.1.6	Kritisch	Access Data Project (.adp) oder Access Web App im Bestand	ADP seit Access 2013 nicht mehr geöffnet, Web Apps eingestellt	Daten liegen bereits in SQL Server; Frontend neu aufbauen (.accdb oder Power Apps)
4.1.8	Kritisch	Access 2016/2019 (seit 14.10.2025) oder Access 2021 (ab 13.10.2026) beziehungsweise Windows 10 ohne ESU auf den Clients	Keine Sicherheitsupdates; ODBC Driver 18.x und Zertifikatsanforderungen auf Alt-Clients nur eingeschränkt testbar; NIS2-/Audit-Befund	Client-Rollout (Access aus M365 oder LTSC 2024, 64 Bit, auf Windows 11) vor oder mit dem Cutover
4.1.7	Kritisch	Formulare, Kombinationsfelder und Recordsets ohne serverseitigen Filter („25.000 holen, 4 behalten“)	Table Scans bei jedem Öffnen, Buffer Pool geflutet, Shared Locks blockieren Schreiber, gesamte Instanz leidet – auch fremde Anwendungen	Jede Datenquelle im FE mit WHERE/WhereCondition, gefilterter View oder Pass-Through; Profiler-Lauf im Test auf SELECT ohne WHERE (Kasten in Kapitel 3.5)

 

4.2 Mittlere Befunde

Nr.	Schwere	Befund	Auswirkung	Gegenmaßnahme
4.2.1	Mittel	Ja/Nein-Felder als NULL-fähiges bit	Kontrollkästchen unbestimmt, Filter liefern falsche Mengen	bit NOT NULL DEFAULT 0; bestehende NULL-Werte auf 0 setzen
4.2.2	Mittel	Fehlende rowversion-Spalte	Schreibkonflikte bei Double-/Memo-/bit-Spalten	Je Tabelle eine rowversion-Spalte (SSMA-Option „Add timestamp“ aktivieren)
4.2.3	Mittel	Leerstring vs. NULL	Access erlaubt „Leere Zeichenfolge“ und NULL; Abfragen mit = "" oder Is Null verhalten sich anders	Vor Migration vereinheitlichen (Update-Abfrage); Regel festlegen
4.2.4	Mittel	VBA-/Access-Funktionen in WHERE-Klauseln	Vollständiger Tabellentransfer, Formulare extrem langsam	Pass-Through, Views, Filter in T-SQL ausdrücken
4.2.5	Mittel	Heterogene Joins (lokal + verknüpft)	Langsam, teils nicht aktualisierbar	Lokale Tabelle ebenfalls migrieren oder als Temp-Tabelle am Server
4.2.6	Mittel	DAO.OpenRecordset ohne dbSeeChanges	Laufzeitfehler 3622 bei IDENTITY-Tabellen	Codeweite Suche, Option ergänzen
4.2.7	Mittel	datetime2 mit altem „SQL Server“-Treiber	Datumsfelder werden als Text angezeigt, Sortierung/Filter kaputt	ODBC Driver 17/18 verwenden oder datetime als Zieltyp
4.2.8	Mittel	Feste DSN auf jedem Client	Rollout- und Wartungsaufwand, Fehler bei Servertausch	DSN-lose Verbindungen mit Relink-Routine
4.2.9	Mittel	Gemeinsames SQL-Login im VBA-Code	Kennwort im Klartext in jeder FE-Kopie, kein Audit	Windows-Auth über AD-Gruppen
4.2.10	Mittel	Kaskadierende Beziehungen nicht übernommen	Waisen entstehen, Löschen schlägt fehl	Beziehungen in SSMA prüfen; ON DELETE CASCADE bewusst setzen
4.2.11	Mittel	Geschäftslogik in Formularereignissen ohne Transaktion	Teil-Updates bei Fehlern	Kritische Abläufe in Stored Procedures mit Transaktion

 

4.3 Niedrige Befunde

Nr.	Schwere	Befund	Auswirkung	Gegenmaßnahme
4.3.1	Niedrig	Tabellennamen mit Leerzeichen, Umlauten, Sonderzeichen	Eckige Klammern überall, Verwechslungen	Umbenennen vor Migration; Access-Aliasnamen für verknüpfte Tabellen nutzen
4.3.2	Niedrig	Verknüpfte Tabellen heißen dbo_Tabelle	Alle Abfragen und Formulare zeigen ins Leere	Nach Verknüpfung dbo_-Präfix per VBA entfernen
4.3.3	Niedrig	Access-Validierungsregeln nicht als CHECK-Constraints	Prüfung nur noch im FE	CHECK-Constraints ergänzen, Meldungstexte im FE
4.3.4	Niedrig	Währung als money	Rundungsdifferenzen in Summen	decimal(19,4)
4.3.5	Niedrig	OLE-Objekte (eingebettete Word-/Bild-Dateien)	Aufgeblähte Datenbank	Dateien ins Dateisystem/SharePoint, Pfad speichern
4.3.6	Niedrig	Keine Indizes außer Primärschlüssel	Server scannt, Formulare warten	Fremdschlüsselspalten und Filterspalten indizieren; Missing-Index-DMVs nach zwei Wochen prüfen
4.3.7	Niedrig	Dokumentation der Datenbank nicht vorhanden	Niemand weiß, welche Felder noch genutzt werden	Datenbank-Dokumentierer exportieren, Objektinventar pflegen

 

☕ Aus der Praxis: Der Freitag der 400 Schreibkonflikte Nach einer scheinbar erfolgreichen Migration meldete der Fachbereich montags 400 Schreibkonflikte – bei drei angemeldeten Benutzern. Ursache: Eine Tabelle mit sieben Double-Spalten (Kalkulationsfaktoren) und ohne rowversion. Access verglich beim Speichern alle alten Werte, und 0,1 + 0,2 ist im Gleitkomma nun einmal nicht exakt 0,3. Eine Spalte, ein ALTER TABLE, Tabellen neu verknüpft – Problem weg. Seither: rowversion ist Pflicht, nicht Option.

5 Aktionsplan: Click-by-Click

Die Maßnahmen folgen dem Vorgehensmodell aus Kapitel 3.4. Jede Maßnahme nennt Priorität, Ziel, konkrete Schritte, ein Erfolgskriterium und einen Rollback-Pfad. Bezeichnungen der Menüs beziehen sich auf Access aus Microsoft 365 (Stand September 2026) und SSMA for Access 10.6.

Maßnahme 1: Inventur der Access-Landschaft

Priorität: Hoch · Ziel: Vollständiges Bild aller Datenbanken, Nutzer und Abhängigkeiten

Schritte (Click-by-Click):

Dateisuche auf allen Freigaben nach *.mdb, *.accdb, *.accde, *.adp (PowerShell: Get-ChildItem -Recurse -Include). Zuletzt-geändert-Datum notieren.

Für jede Kandidatin: Access öffnen › Datenbanktools › Datenbank dokumentieren › alle Objekttypen wählen › Bericht als PDF exportieren.

Datenbanktools › Objektabhängigkeiten prüfen, um tote Objekte zu erkennen.

VBA-Editor (Alt+F11) › Suchen in „Aktuelles Projekt“ nach OpenRecordset, CurrentDb.Execute, DoCmd.RunSQL, TransferSpreadsheet, DLookup – Trefferzahlen notieren.

Fachbereich befragen: Wer nutzt die Datenbank, wann, wofür, welche Excel-/Outlook-Anbindungen existieren?

Ergebnis in Inventartabelle (Anhang B) eintragen und je Datenbank klassifizieren: migrieren / abschalten / archivieren.

Erfolgskriterium: Jede aktive Datenbank hat einen Eigner, eine Klassifizierung und einen Dokumentierer-Export.

Rollback: Nicht erforderlich – rein lesende Maßnahme.

Maßnahme 2: Frontend/Backend-Split herstellen

Priorität: Hoch · Ziel: Tabellen und Anwendungsobjekte getrennt, Grundlage für den Austausch der Datenhaltung

Schritte (Click-by-Click):

Sicherungskopie der Datenbank anlegen (Datei kopieren, Access geschlossen).

Datenbanktools › Access-Datenbank verschieben › Access-Datenbank. Backend-Namen wählen (z. B. Reklamation_BE.accdb), auf Freigabe speichern.

Ergebnis prüfen: Im Frontend erscheinen die Tabellen mit Pfeilsymbol (verknüpft).

Frontend je Benutzer lokal verteilen (nicht gemeinsam von der Freigabe öffnen).

Externe Daten › Tabellenverknüpfungs-Manager öffnen, Pfad kontrollieren.

Erfolgskriterium: Frontend startet ohne Fehler, alle Tabellen sind verknüpft, Backend enthält nur Tabellen und Beziehungen.

Rollback: Sicherungskopie aus Schritt 1 zurückspielen.

Maßnahme 3: Bereinigung des Datenmodells

Priorität: Hoch · Ziel: Migrationsfähiges Schema ohne SSMA-Blocker

Schritte (Click-by-Click):

Jede Tabelle ohne Primärschlüssel: Entwurfsansicht › AutoWert-Feld ID hinzufügen › als Primärschlüssel setzen.

Mehrwertige Felder auflösen: Neue Zwischentabelle (n:m) anlegen, Werte per Anfüge-Abfrage über Feld.Value übertragen, Feld entfernen, Formulare auf Unterformular umstellen.

Anlagefelder auflösen: Tabelle Anlagen (ID, ParentID, Dateiname, Inhalt) anlegen; Inhalte per VBA (Recordset2.Fields("Anlage").Value) exportieren – oder Dateien ins Dateisystem/SharePoint auslagern.

Berechnete Felder notieren (Formel dokumentieren) und entfernen; später als View oder Computed Column.

Leerstring vs. NULL vereinheitlichen: UPDATE Tabelle SET Feld = Null WHERE Feld = "" (oder umgekehrt, je nach Regel).

Ja/Nein-Felder: Prüfen, ob Standardwert gesetzt ist; Regel „immer NOT NULL“ dokumentieren.

Objektnamen mit Leerzeichen/Sonderzeichen umbenennen (Objektabhängigkeiten oder Werkzeug zur Namensänderung nutzen).

Datenbank komprimieren und reparieren.

Erfolgskriterium: SSMA-Assessment (Maßnahme 4) meldet keine Fehler der Kategorie „nicht unterstützt“.

Rollback: Sicherungskopie vor Bereinigung; Änderungen sind im Backend isoliert.

Maßnahme 4: SQL Server vorbereiten

Priorität: Hoch · Ziel: Zielinstanz mit Datenbank, Rechten und Zertifikat

Schritte (Click-by-Click):

Version und Edition festlegen: SQL Server 2025 mit aktuellem CU (2022 nur, wenn eine vorhandene Instanz mitgenutzt wird; 2019 nicht mehr neu installieren); Express (50 GB je Datenbank, 4 Kerne, 1,4 GB Puffer, kein Agent) oder Standard. Instanz mit Standardkollation Latin1_General_CI_AS installieren (entspricht Access-Verhalten: nicht case-sensitiv).

SQL Server-Konfigurations-Manager › SQL Server-Netzwerkkonfiguration › TCP/IP aktivieren; bei benannter Instanz SQL Browser-Dienst starten oder festen Port setzen.

Windows-Firewall: TCP 1433 (bzw. fester Port) und UDP 1434 (Browser) freigeben.

Zertifikat: In der internen PKI ein Serverzertifikat (Serverauthentifizierung, FQDN als SAN) ausstellen; im Konfigurations-Manager unter Protokolle › Zertifikat auswählen; Dienst neu starten.

SSMS: Neue Datenbank anlegen (Wiederherstellungsmodell Vollständig, Dateien getrennt von System-DBs).

AD-Gruppen APP_<Name>_Benutzer und APP_<Name>_Admins anlegen; als Windows-Logins hinzufügen; Datenbankbenutzer mit Rollen db_datareader/db_datawriter (Benutzer) bzw. db_owner (Admins) erstellen.

Backup-Job (Voll täglich, Log alle 15 Minuten) einrichten – bei Express per Aufgabenplanung und sqlcmd.

Erfolgskriterium: Testverbindung mit ODBC Driver 18 von einem Client ohne Zertifikatswarnung möglich; Backup läuft.

Rollback: Instanz oder Datenbank löschen – noch keine Produktivdaten betroffen.

Maßnahme 5: Schema und Daten mit SSMA migrieren

Priorität: Hoch · Ziel: Tabellen, Daten, Indizes und Beziehungen im SQL Server

Schritte (Click-by-Click):

SSMA for Access 10.6 (September 2026) installieren; Bitness passend zur Access Database Engine – bei 32-Bit-Access ausdrücklich die x86-MSI wählen (im Sommer 2026 startete die x86-Variante fehlerhaft als 64-Bit-Prozess). Als Zielversion SQL Server 2025 wählen; Azure SQL Database ebenfalls möglich.

Neues Projekt › Zielversion (SQL Server 2019/2022 oder Azure SQL Database) wählen.

Datei › Datenbanken hinzufügen › Backend-Datei wählen (nicht das Frontend!).

Extras › Projekteinstellungen › Allgemein: „Add timestamp columns“ = Always. Typmapping gemäß Tabelle 3.3 anpassen (Währung › decimal(19,4); Datum/Uhrzeit › datetime2(3) oder datetime).

Datenbank auswählen › Bericht erstellen. Bericht durcharbeiten: Warnungen zu Beziehungen, Indizes, Validierungsregeln notieren.

Mit SQL Server verbinden (Windows-Auth, Zieldatenbank wählen).

Schema konvertieren › Ergebnis im SQL-Server-Metadaten-Explorer prüfen › Mit Datenbank synchronisieren.

Daten migrieren. Protokoll auf Zeilenzahlen prüfen: Quelle und Ziel je Tabelle vergleichen (SELECT COUNT(*)).

In SSMS nacharbeiten: CHECK-Constraints aus Validierungsregeln, Indizes auf Fremdschlüssel, DEFAULT-Werte, Kaskadenregeln.

Noch nicht verknüpfen lassen (SSMA bietet das an) – Verknüpfung erfolgt gezielt in Maßnahme 6.

Erfolgskriterium: Zeilenzahlen aller Tabellen identisch; keine Konvertierungsfehler; Stichproben mit Datum, Umlauten, NULL-Werten korrekt.

Rollback: Zieldatenbank leeren oder neu anlegen; Quelle ist unverändert.

Maßnahme 6: Tabellen DSN-los verknüpfen und Relink-Routine einbauen

Priorität: Hoch · Ziel: Frontend zeigt auf SQL Server, unabhängig von Client-DSNs

Schritte (Click-by-Click):

Test-Frontend-Kopie anlegen. Alle bisher verknüpften Backend-Tabellen löschen.

Externe Daten › Neue Datenquelle › Aus anderen Quellen › ODBC-Datenbank › Verknüpfen › Datei-DSN mit ODBC Driver 17/18 erstellen (nur für den Import-Dialog nötig).

Alle Tabellen markieren, „Kennwort speichern“ nicht nötig bei Windows-Auth. Bei Views: eindeutigen Datensatzbezeichner im Dialog auswählen.

Präfix dbo_ entfernen: VBA-Schleife über CurrentDb.TableDefs, Name = Mid(Name, 5) für Tabellen mit Connect <> "".

Relink-Routine in Autoexec/Startformular: Für jede verknüpfte TableDef Connect-String auf DSN-lose Zeichenfolge setzen (Server, Datenbank aus lokaler Konfigurationstabelle lesen), RefreshLink ausführen, Fehler protokollieren.

Tabellenverknüpfungs-Manager prüfen: Alle Verknüpfungen zeigen ODBC;DRIVER=… ohne DSN.

Erfolgskriterium: Frontend startet auf einem Client ohne jede ODBC-DSN und öffnet alle Tabellen; Servername lässt sich über die Konfigurationstabelle umstellen.

Rollback: Test-Frontend verwerfen; produktives Frontend bleibt auf altem Backend.

Maßnahme 7: Abfragen, Formulare und VBA anpassen

Priorität: Hoch · Ziel: Serverseitige Verarbeitung, keine Laufzeitfehler

Schritte (Click-by-Click):

VBA-Editor: Suche nach OpenRecordset › überall dbOpenDynaset, dbSeeChanges ergänzen. Suche nach .Execute › dbFailOnError + dbSeeChanges.

Abfragen mit VBA-/Access-Funktionen im WHERE identifizieren (Dokumentierer-Export durchsuchen nach Nz(, Format(, DLookup(, IIf(). In Pass-Through umbauen oder Funktion durch T-SQL-Äquivalent (ISNULL, CASE) in einer View ersetzen.

Berichte auf Pass-Through-Abfragen umstellen: Neue Abfrage › SQL-spezifisch › Pass-Through › ODBC-Verbindungszeichenfolge setzen › T-SQL eintragen › ReturnsRecords = Ja.

Formulare: Recordsource prüfen. Bei Tabellen > 10.000 Zeilen Öffnen mit DoCmd.OpenForm …, WhereCondition oder Suchformular vorschalten.

Kombinationsfelder auf große Tabellen: Rowsource auf gefilterte View oder lokale Nachschlagetabelle umstellen.

Vollabzüge aufspüren: Profiler/Extended Events während einer typischen Anwendersitzung mitlaufen lassen, nach SELECT-Anweisungen ohne WHERE filtern, Zeilenzahlen prüfen; jede Quelle mit mehr als etwa 1.000 zurückgegebenen Zeilen für ein Formular ist ein Umbaukandidat.

Heterogene Joins entfernen: Verbleibende lokale Tabellen ebenfalls migrieren.

Fehlerbehandlung: ODBC-Fehler (3146) mit DBEngine.Errors-Sammlung ausgeben, nicht nur Err.Description.

Kritische Mehrschritt-Operationen als Stored Procedure mit Transaktion implementieren; Aufruf per Pass-Through oder ADODB.Command.

Erfolgskriterium: Alle Formulare öffnen in unter zwei Sekunden im LAN; keine Laufzeitfehler 3622/3146 im Test; Berichte liefern identische Ergebnisse wie vorher.

Rollback: Test-Frontend verwerfen; produktives Frontend unverändert.

Maßnahme 8: Test und Abnahme

Priorität: Hoch · Ziel: Fachliche Freigabe auf Testumgebung

Schritte (Click-by-Click):

Testdatenbank auf dem SQL Server aus aktueller Migration bereitstellen (frischer SSMA-Lauf oder Restore).

Testkatalog mit dem Fachbereich: je Formular Anlegen, Ändern, Löschen, Suchen; je Bericht Vergleich mit Altbericht; Monats-/Jahresabschlussfunktionen.

Mehrbenutzertest: Zwei Benutzer bearbeiten denselben Datensatz – erwartetes Verhalten dokumentieren.

Lasttest: Größte Liste, größter Bericht, Zeit messen; SQL Server Profiler oder Extended Events mitlaufen lassen, um SELECT * ohne WHERE zu finden.

Rechte-Test: Benutzer außerhalb der AD-Gruppe darf nicht verbinden.

Abnahmeprotokoll unterschreiben lassen (Gate B).

Erfolgskriterium: Alle Testfälle bestanden oder mit akzeptierter Abweichung dokumentiert; Abnahme liegt vor.

Rollback: Testumgebung – kein Rollback nötig.

Maßnahme 9: Cutover

Priorität: Hoch · Ziel: Produktivbetrieb auf SQL Server, alte Datenhaltung eingefroren

Schritte (Click-by-Click):

Wartungsfenster ankündigen; alle Benutzer schließen Access (Sperrdatei .laccdb prüfen).

Altes Backend kopieren (Sicherung) und die Originaldatei umbenennen (Reklamation_BE_ALT_2024-04-12.accdb) sowie schreibschützen.

Zieldatenbank leeren; SSMA-Datenmigration mit dem finalen Stand erneut ausführen; Zeilenzahlen prüfen.

IDENTITY-Werte prüfen (DBCC CHECKIDENT), damit keine Kollisionen mit hohen alten AutoWerten entstehen.

Neues Frontend (.accde) verteilen – Versionsnummer in Konfigurationstabelle; altes Frontend verweigert Start bei falscher Version.

Vollsicherung der SQL-Datenbank unmittelbar nach Cutover.

Smoke-Test mit zwei Anwendern aus dem Fachbereich; Freigabe per Mail.

Erfolgskriterium: Benutzer arbeiten produktiv auf dem SQL Server; alte Backend-Datei ist unerreichbar; Backup vorhanden.

Rollback: Alte Backend-Datei zurückbenennen, altes Frontend verteilen – funktioniert, solange niemand auf dem SQL Server Daten erfasst hat; danach Delta-Rückübertragung nötig (vermeiden!).

Maßnahme 10: Nachlauf und Betrieb

Priorität: Mittel · Ziel: Stabiler Betrieb, Performance-Feinschliff, Dokumentation

Schritte (Click-by-Click):

Nach zwei Wochen: sys.dm_db_missing_index_details auswerten, sinnvolle Indizes ergänzen.

Wartungsplan: Integritätsprüfung wöchentlich, Indexpflege, Statistiken; Backup-Restore einmal tatsächlich testen.

Monitoring: Blockierungen und lange Abfragen (Query Store aktivieren).

Alte Backend-Datei nach 90 Tagen archivieren (nicht löschen).

Dokumentation: Verbindungszeichenfolge, AD-Gruppen, Backup-Plan, Verteilungsweg des Frontends.

Roadmap-Entscheidung: Bleibt Access-FE, oder startet ein Power-Apps-/.NET-Projekt auf der neuen Datenbasis?

Erfolgskriterium: Kein Incident in 30 Tagen; Restore-Test dokumentiert; Roadmap entschieden.

Rollback: Entfällt.

6 Risiken

Risiko	Eintritt	Auswirkung	Vorbeugung / Reaktion
Unbekannte Sonderfunktionen im Fachbereich („die Jahresabschlussabfrage macht nur Frau Müller“)	Hoch	Mittel	Inventur mit Interviews, Testkatalog vom Fachbereich mitschreiben lassen
Performanceeinbruch nach Migration	Hoch	Hoch	Maßnahme 7 konsequent; Profiler im Test; Erwartungsmanagement vorab
Access-Frontend belastet eine gemeinsam genutzte SQL-Instanz (ungefilterte Vollabzüge, Blockierungen)	Hoch	Kritisch	Eigene Instanz oder Ressourcenkontrolle (Resource Governor ab Standard/Enterprise); Befund 4.1.7 vor Cutover abgearbeitet
Datenspaltung durch parallele Nutzung des alten Backends	Mittel	Kritisch	Umbenennen und Schreibschutz; FE-Versionsprüfung
Zertifikats-/TLS-Probleme beim Rollout des ODBC Driver 18	Mittel	Hoch	PKI-Zertifikat vorab; Treiber zentral per Softwareverteilung
Bitness-Chaos (32-Bit-Office trifft 64-Bit-Treiber)	Mittel	Mittel	Inventur der Office-Installationen; Treiber in beiden Bitness-Varianten bereitstellen
Datenverlust bei MVF/Anlagen	Mittel	Kritisch	Auflösung vor Migration, Zeilenzahlprüfung, Stichproben
Lizenzüberraschung (Express-Grenze erreicht, Standard nötig)	Niedrig	Mittel	Datenvolumen und Wachstum in der Inventur erfassen
Cloud-Variante: Latenz macht Access-FE unbenutzbar	Hoch (bei Azure SQL ohne AVD)	Hoch	Clients nahe an die Datenbank (AVD/Cloud PC) oder on-premises bleiben
Schlüsselperson (Access-Entwickler) nicht verfügbar	Mittel	Hoch	Dokumentation, Pairing, Code-Kommentare während der Anpassung
Access-2021-Support-Ende am 13.10.2026 zwingt zu einem überhasteten Client-Rollout parallel zur Migration	Hoch	Mittel	Reihenfolge festlegen: erst Client (Access aus M365/LTSC 2024), dann Cutover – oder umgekehrt, aber nie beides in derselben Woche
Express Edition wird wegen 50 GB als „reicht immer“ gewählt, der 1,4-GB-Puffer aber ignoriert	Mittel	Mittel	Befund 4.1.7 konsequent abarbeiten; Buffer-Pool-Trefferquote im Nachlauf messen; Standard als Ausweichoption einplanen
Scope-Explosion („wenn wir schon dabei sind, bauen wir das FE neu“)	Hoch	Hoch	Gate A: Daten zuerst, Oberfläche als eigenes Projekt

 

✔ Erwartungsmanagement Vor dem Projekt sollte allen Beteiligten klar sein: Der Server macht die Datenbank sicher, robust und mehrbenutzerfähig. Schnell macht sie erst die Anwendungsanpassung. Wer das vorher sagt, erspart sich hinterher die Diskussion.

7 Offene Punkte

Diese Punkte sind im konkreten Projekt zu klären, bevor der Aktionsplan startet.

Nr.	Offener Punkt	Verantwortlich	Entscheidungsbedarf bis	Status
OP-1	Zielplattform: SQL Server on-premises (Edition?) oder Azure SQL Database	IT-Leitung	Vor Maßnahme 4	offen
OP-2	Authentifizierung: Windows-Auth via AD-Gruppen (Empfehlung) oder Entra ID (Cloud)	IT-Sicherheit	Vor Maßnahme 4	offen
OP-3	Verbleib des Access-Frontends: dauerhaft, Übergang oder Ablösung durch Power Apps/.NET	Fachbereich + IT	Gate A	offen
OP-4	Umgang mit Anlage-/OLE-Feldern: Datenbank oder Dateisystem/SharePoint	Fachbereich	Vor Maßnahme 3	offen
OP-5	Bitness der Office-Installationen und Verteilungsweg der ODBC-Treiber	Client-Management	Vor Maßnahme 6	offen
OP-6	Regel Leerstring vs. NULL	Anwendungsverantwortlicher	Vor Maßnahme 3	offen
OP-7	Wartungsfenster für Cutover, Rückfallfrist	Fachbereich	Vor Maßnahme 9	offen
OP-8	Backup-Verantwortung und Aufbewahrungsfristen der alten Backend-Datei	IT-Betrieb	Vor Maßnahme 9	offen
OP-10	Client-Strategie vor dem 13.10.2026: Access aus Microsoft 365 oder LTSC 2024, 64 Bit, Windows-11-Stand	Client-Management	Sofort	offen
OP-11	KI-Werkzeuge: Welche Dienste sind für Schema-/Code-Analyse freigegeben (AVV, Datenklassifizierung)?	IT-Sicherheit / Datenschutz	Vor Maßnahme 7	offen
OP-9	Weitere Consumer der Daten (Power BI, Schnittstellen) – Rechte- und View-Konzept	IT + Fachbereich	Maßnahme 10	offen

8 Anhang

8.1 Glossar

Begriff	Bedeutung
ACE / Jet	Access Database Engine; die Dateidatenbank-Engine hinter .accdb/.mdb, auch Vermittler zu ODBC-Quellen
SSMA	SQL Server Migration Assistant; kostenloses Microsoft-Werkzeug für die Migration von Access, Oracle, MySQL u. a. nach SQL Server
Verknüpfte Tabelle	Tabelle im Access-Frontend, deren Daten in einer externen Quelle (hier SQL Server) liegen
Pass-Through-Abfrage	Abfrage, deren SQL unverändert an den Server gesendet wird; Ergebnis ist schreibgeschützt
rowversion / timestamp	SQL-Server-Spaltentyp mit automatischem Änderungszähler; ermöglicht Access eine effiziente Konfliktprüfung
dbSeeChanges	DAO-Option, die bei Recordsets auf Tabellen mit IDENTITY-Spalten erforderlich ist
DSN	Data Source Name; zentral oder je Benutzer gespeicherte ODBC-Verbindungsdefinition
MVF	Mehrwertiges Feld (Multi-Value Field), Access-spezifisch, in SQL Server nicht vorhanden
FE / BE	Frontend (Formulare, Berichte, Code) / Backend (Tabellen)
Access Services	Ehemaliger SharePoint-Dienst zum Betrieb von Access Web Apps; eingestellt

 

8.2 Checkliste Inventur (Vorlage)

Feld	Beispielwert
Dateiname / Pfad	\\FS01\Fachbereich\Reklamation_BE.accdb
Dateigröße / Wachstum pro Jahr	1,4 GB / ca. 200 MB
Access-Version, Bitness	M365 Apps, 32 Bit
Eigner (fachlich / technisch)	Leitung Qualitätssicherung / Herr Schmidt (Abteilung IT)
Anzahl Benutzer (gleichzeitig / gesamt)	8 / 25
Anzahl Tabellen / Abfragen / Formulare / Berichte / Module	42 / 118 / 36 / 22 / 9
Tabellen ohne Primärschlüssel	3
Mehrwertige Felder / Anlagefelder / OLE / berechnete Felder	2 / 1 / 0 / 4
Externe Anbindungen	Excel-Export monatlich, Outlook-Mailversand, ODBC-Link auf ERP-Sicht
Geschäftskritikalität	hoch – Reklamationsbearbeitung mit Kundenfristen
Entscheidung	migrieren / abschalten / archivieren

 

8.3 Nützliche T-SQL- und VBA-Schnipsel

rowversion-Spalte nachträglich ergänzen:

ALTER TABLE dbo.Reklamation ADD RowVer rowversion NOT NULL;

Ja/Nein-Feld korrigieren:

UPDATE dbo.Reklamation SET Erledigt = 0 WHERE Erledigt IS NULL; ALTER TABLE dbo.Reklamation ALTER COLUMN Erledigt bit NOT NULL; ALTER TABLE dbo.Reklamation ADD CONSTRAINT DF_Reklamation_Erledigt DEFAULT 0 FOR Erledigt;

DAO-Recordset korrekt öffnen:

Set rs = CurrentDb.OpenRecordset("SELECT * FROM Reklamation WHERE ID = " & lngID, dbOpenDynaset, dbSeeChanges)

Relink-Routine (Kern):

For Each tdf In CurrentDb.TableDefs: If Len(tdf.Connect) > 0 Then tdf.Connect = strConnect: tdf.RefreshLink: End If: Next

9 FAQ – Häufige Fragen zur Access-Migration

Muss ich Access aufgeben, wenn ich nach SQL Server migriere?

Nein. Der Standardpfad behält Access als Frontend. Nur die Tabellen wandern auf den Server. Formulare, Berichte und VBA bleiben – mit den Anpassungen aus Kapitel 5, Maßnahme 7.

Reicht SQL Server Express?

Mit SQL Server 2025 fast immer: 50 GB je Datenbank (vorher 10 GB), 1 Socket/4 Kerne, 1,4 GB RAM für den Puffer. Kein SQL Server Agent – Backups laufen über die Aufgabenplanung. Wer die 10 GB oder professionelle HA braucht, geht auf die Standard Edition.

Wie lange dauert eine Migration?

Die Datenübertragung mit SSMA: Stunden. Bereinigung und Anwendungsanpassung: Tage bis wenige Wochen, abhängig von der Anzahl der Formulare und der VBA-Menge. Als Daumenregel für eine mittelgroße Fachanwendung (40 Tabellen, 30 Formulare): 8 bis 15 Beratertage inklusive Test.

Warum ist meine Anwendung nach der Migration langsamer?

Weil Access lokal filtert, wo der Server filtern sollte. VBA-Funktionen in Abfragen, Formulare auf ganzen Tabellen und heterogene Joins ziehen komplette Tabellen über das Netz. Pass-Through-Abfragen, Views und gefilterte Formulare beheben das – siehe Skizze 4.

Was ist mit dem Upsizing-Assistenten in Access?

Der ist seit Access 2013 nicht mehr enthalten. Das Werkzeug der Wahl ist SSMA for Access, kostenlos von Microsoft.

Kann ich das Access-Frontend weiter von der Netzwerkfreigabe starten?

Sollte man nicht. Jeder Benutzer braucht seine eigene lokale Kopie des Frontends; sonst gibt es genau die Beschädigungen, die man mit der Migration loswerden wollte. Ein kleines Startskript, das das FE aus einem Freigabeordner kopiert und startet, löst das Verteilungsproblem.

Windows-Authentifizierung oder SQL-Login?

Windows-Authentifizierung über AD-Gruppen. SQL-Logins bedeuten in Access fast immer ein Kennwort im Klartext im Code oder in der Verbindungszeichenfolge – das kann jeder Benutzer auslesen.

Brauche ich wirklich in jeder Tabelle eine rowversion-Spalte?

Ja. Sie kostet 8 Byte je Zeile und erspart den Großteil der Schreibkonflikte, besonders bei Double-, bit- und Memo-Spalten. SSMA setzt sie auf Wunsch automatisch.

Was passiert mit mehrwertigen Feldern und Anlagen?

SQL Server kennt beides nicht. Mehrwertige Felder werden zu einer Zwischentabelle (n:m), Anlagen zu einer eigenen Tabelle mit varbinary(max) oder – besser – zu Dateien im Dateisystem oder in SharePoint mit Pfad in der Datenbank. Das muss vor der Migration geschehen.

Kann ich direkt nach Azure SQL migrieren?

Technisch ja, SSMA unterstützt Azure SQL Database als Ziel. Praktisch ist die Latenz das Problem: Access ist ein „gesprächiger“ Client, und 30 ms Round-Trip je Zeile summieren sich. Sinnvoll wird es, wenn die Access-Clients ebenfalls in der Cloud laufen (Azure Virtual Desktop, Windows 365).

Wie gehe ich mit Access Services beziehungsweise Access Web Apps um?

Als Migrationsquelle, nicht als Ziel. Die Daten einer Web App liegen bereits in einer SQL-Datenbank (on-premises oder Azure). Die Oberfläche ist weg und wird neu gebaut – in Access Desktop oder in Power Apps.

Sollte ich lieber gleich Power Apps nehmen?

Nur wenn die Oberfläche ohnehin neu gebaut werden soll und Mobil-/Webzugriff gewünscht ist. Auch dann gilt: Daten zuerst nach SQL Server oder Dataverse, dann die Oberfläche. Power Apps erfordert für SQL Server und Dataverse Premium-Lizenzen.

Was tun mit datetime2?

Mit ODBC Driver 17 oder 18 funktioniert datetime2 einwandfrei. Mit dem alten Windows-Treiber „SQL Server“ erscheint es als Text. Wer den Treiberwechsel nicht sofort schafft, nimmt datetime als Zieltyp – der Wertebereich reicht für praktisch alle Access-Daten.

Access holt sich 25.000 Zeilen und zeigt vier – ist das wirklich so schlimm?

Ja, und zwar für alle. Für den Anwender ist es langsam, für den Server ist es ein Table Scan mit vollem Buffer Pool und Shared Locks, bei jedem Öffnen, für jeden Benutzer. Auf einer geteilten Instanz trifft das auch das ERP nebenan. Die Regel lautet: Was der Anwender nicht sieht, darf den Server nicht verlassen – Filter gehören in die WHERE-Klausel, nicht in die Formularlogik.

Wie erkenne ich, welche Abfragen der Server tatsächlich sieht?

SQL Server Profiler oder Extended Events mitlaufen lassen und die Anwendung bedienen. Wer dort SELECT-Anweisungen ohne WHERE-Klausel auf große Tabellen sieht, hat seine Performance-Kandidaten gefunden.

Kann ich das Frontend als .accde ausliefern?

Ja, und das ist empfehlenswert: kompilierter Code, kein Zugriff auf Formularentwurf. Achtung: Die .accde muss mit derselben Bitness und möglichst derselben Access-Version erzeugt werden, die die Clients nutzen.

Wie viele gleichzeitige Benutzer verträgt die Lösung dann?

Der SQL Server ist nicht der Engpass; 100 und mehr gleichzeitige Access-Benutzer sind bei sauberem Frontend-Design unproblematisch. Der Engpass sind schlecht gefilterte Formulare – siehe Skizze 4.

SQL Server 2022 oder 2025?

2025. Seit November 2025 GA, mehrere kumulative Updates, Express mit 50 GB, Standard mit 32 Kernen. Für ein Access-Frontend ändert sich zwischen 2022 und 2025 nichts – die Editionsgrenzen sind der Grund, 2025 zu nehmen. 2022 nur, wenn eine bestehende 2022-Instanz mitgenutzt werden soll.

Meine Anwender haben noch Access 2016/2019 oder 2021 – ist das ein Problem?

2016 und 2019 sind seit dem 14. Oktober 2025 ohne Sicherheitsupdates, 2021 folgt am 13. Oktober 2026. Technisch verbinden sich alle weiter mit SQL Server, aber ein Migrationsprojekt, das unsupportete Clients hinterlässt, ist ein halbes Projekt. Access aus Microsoft 365 oder Access LTSC 2024 (Support bis Oktober 2029) sind die Ziele, in 64 Bit.

Wird Access eingestellt?

Nein. Access ist Teil von Microsoft 365 und von Office LTSC 2024 mit Support bis Oktober 2029. Was eingestellt ist, sind Access Services/Web Apps und Access Data Projects. Neue Funktionen kommen in kleinen Schritten (angekündigt sind Breitbildunterstützung und Formularzoom) – aber der Client als Frontend auf SQL Server ist auf Jahre tragfähig.

Kann ich die VBA-Anpassung einer KI überlassen?

Die Analyse und den Großteil der mechanischen Umstellung ja: dbSeeChanges ergänzen, Access-SQL in T-SQL-Views übersetzen, Prozeduren entwerfen. Die Abnahme nicht. Und keine echten Daten in den Chat – Schema und Code reichen.

Was kostet das an Lizenzen?

SQL Server Express: nichts. Standard Edition: je Kern oder Server plus CAL (Lizenzmodell mit SQL Server 2025 unverändert, Web Edition entfallen) – im Einzelfall zu prüfen. Access selbst ist in Microsoft 365 Apps for Business/Enterprise enthalten; für reine Nutzer ohne Access-Lizenz gibt es die kostenlose Access Runtime.