Wenn Access in die Cloud soll – aber niemand weiß, wie

Access läuft.
Seit Jahren. Lokal.
Aber die IT will in die Cloud.
„Mach das mal Azure-fähig.“

Geht das?
Ja.
Aber nicht einfach so.

Ich zeig Dir, wie ich Access-Apps in die Azure-Welt bringe.
Stück für Stück. Ohne All-In-Desaster.

Was geht – und was nicht

Teilbereich	Azure-kompatibel	Einschränkungen
Datenbank-Backend	✅ Azure SQL	Migration nötig, Performance beachten
Frontend (Formulare, VBA)	❌ nur lokal	kein Hosting von ACCDE in der Cloud
ODBC-Verbindung	✅	DSN-less empfohlen, VPN/Azure AD empfohlen
Automatisierung (VBA)	✅ bedingt	Laufzeit nur lokal, keine Cloud-Funktion
Webzugriff	❌	nur per Power Apps/WebView-Ansatz möglich

Fazit: Access bleibt lokal – aber das Backend wandert hoch.

Schritt 1: Azure SQL-Datenbank vorbereiten

Im Azure-Portal:

• Ressourcengruppe erstellen
• SQL-Datenbank erstellen
• Serverzugang einrichten (Firewallregel: Dein Büro-Subnetz)
• Authentifizierung: SQL oder Azure AD (empfohlen)

Beispiel T-SQL zum Anlegen einer Tabelle:

CREATE TABLE Kunden (
  KundenID INT IDENTITY(1,1) PRIMARY KEY,
  Name NVARCHAR(100) NOT NULL,
  PLZ NVARCHAR(10),
  Aktiv BIT DEFAULT 1
);

Schritt 2: Access-Frontend mit Azure verbinden

ODBC-Treiber installieren:
„ODBC Driver 18 for SQL Server“

Dann DSN-less-Connect:

Dim tdf As DAO.TableDef
Set tdf = CurrentDb.CreateTableDef("tblKunden")

tdf.Connect = "ODBC;Driver={ODBC Driver 18 for SQL Server};Server=tcp:meinserver.database.windows.net,1433;Database=meinedb;Encrypt=yes;TrustServerCertificate=no;Authentication=ActiveDirectoryPassword;UID=xyz@firma.de;PWD=Geheim123"

tdf.SourceTableName = "dbo.Kunden"
CurrentDb.TableDefs.Append tdf

Alternativ: manuell verknüpfen → Externe Daten → ODBC → DSN auswählen

Schritt 3: Performance und Fallstricke beachten

Azure SQL hat höhere Latenzen.
Deshalb:

• Keine Formulare direkt auf großen Tabellen
• Abfragen mit WHERE-Klauseln vorfiltern
• Kein ständiges Öffnen/Schließen von Recordsets
• dbOpenSnapshot statt dbOpenDynaset, wenn möglich
• Vorsicht mit DLookup, DCount, ComboBox.RowSource

Beispiel: Suche per parametrischer Abfrage

SELECT * FROM Kunden WHERE PLZ = [Bitte PLZ eingeben];

→ In Access nicht performant
→ Besser: VBA-generierte Abfrage

Dim qdf As DAO.QueryDef
Set qdf = CurrentDb.CreateQueryDef("qryKundenSuche", _
  "SELECT * FROM Kunden WHERE PLZ = '" & Me!txtPLZ & "'")

Schritt 4: Access-Frontend per AutoUpdate verteilen

Cloud heißt nicht, dass die Frontend-Datei mitzieht.
Aber Du kannst eine Verteilung bauen:

• ACCDE lokal speichern
• Update per Script oder Tool (z. B. robocopy, PowerShell)
• Versionierung prüfen beim Öffnen

If CurrentProject.Properties("Version") <> "1.3.7" Then
    MsgBox "Bitte neue Version installieren.", vbExclamation
    Application.Quit
End If

Schritt 5: Alternativen mit Power Platform prüfen

Wenn Access zu eng wird, gibt’s Alternativen:

• Power Apps + Dataverse
• Power Automate für Prozesse
• Power BI für Reporting

Migration ist kein Knopfdruck.
Aber machbar. Schrittweise.

Mein Setup für Access + Azure SQL

Komponente	Umsetzung
Backend	Azure SQL, strukturierter Aufbau mit FK + SP
Frontend	Access ACCDE lokal pro Nutzer
Verbindung	ODBC DSN-less mit Azure AD
Sicherheit	Azure Firewall + Azure AD Authentication
Deployment	Updater-Tool oder Loginskript mit Versionsprüfung
Erweiterung	Power Apps für mobile Nutzung optional

Access in die Cloud heißt: nicht wegwerfen, sondern aufteilen. Backend hoch. Frontend bleibt.

Klingt simpel – ist es nicht.
Aber es funktioniert.
Wenn Du weißt, was Du tust.
Und nicht versuchst, 90er-Logik in die Cloud zu pressen.