Vom Access-Backend zum versionierten SQL Server: Flyway und Git für Einsteiger

Kurzfassung: Wenn Du als Access-Entwickler irgendwann den Punkt erreichst, an dem Dein Backend auf den SQL Server umziehen muss, stehst Du plötzlich vor einer Disziplin, die in der Access-Welt kaum jemand kennt: Schema-Versionskontrolle. Dieser Beitrag zeigt Dir, wie Du mit Flyway Community Edition und Git Deine SQL-Server-Datenbank nachvollziehbar und sicher pflegst — als Schritt-für-Schritt-Anleitung für ein einzelnes Live-System. Keine Theorie, sondern ein Pfad, den Du ab morgen einschlagen kannst.

Warum überhaupt Versionskontrolle für die Datenbank?

In der Access-Welt ist „Versionskontrolle“ selten ein Thema. Die Access-Datei ist die Anwendung — Formulare, Code, Tabellen, alles in einer .accdb. Man macht Backup-Kopien mit Datum im Dateinamen, und das war’s. Funktioniert bei einer Einzeldatei auch einigermaßen.

Sobald Du aber das Backend auf den SQL Server umziehst, ändert sich die Situation grundlegend:

Die Tabellenstruktur lebt auf dem Server, nicht mehr in einer Datei, die Du einfach kopieren kannst.
Du wirst Stored Procedures, Views, Functions anlegen — echten Code, der irgendwo verwaltet werden muss.
Änderungen passieren oft unter Zeitdruck beim Kunden: „Schnell noch eine Spalte, der Chef will das heute Nachmittag im Bericht sehen.“
Nach ein paar Wochen weißt Du nicht mehr, was Du wann warum geändert hast — und der Kunde fragt.

Versionskontrolle löst genau dieses Problem. Jede Änderung am Schema wird zu einem kleinen, datierten, kommentierten Eintrag. Drei Monate später machst Du git log und siehst, dass Du am 14. März die Spalte UStIdNr hinzugefügt hast, weil der Kunde eine neue Rechnungsvorlage brauchte.

Das ist nicht Kür, das ist Handwerk — und es ist deutlich weniger Aufwand, als es zunächst klingt.

Die Werkzeuge: Was ist Flyway, was ist Git?

Git ist das Standard-Versionskontrollsystem der Softwarewelt. Es merkt sich den Inhalt von Dateien in einem Ordner, wann sich etwas geändert hat, wer es geändert hat und warum. Jede Änderung nennt sich „Commit“ und hat eine Begründung, die Du selbst einträgst.

Flyway ist ein Werkzeug, das auf dieser Basis speziell für Datenbanken etwas Cleveres macht: Du schreibst jede Schema-Änderung in eine .sql-Datei mit einer fortlaufenden Nummer. Flyway merkt sich in einer kleinen Kontrolltabelle in der Datenbank, welche Nummern schon ausgeführt sind, und führt beim nächsten Aufruf nur die noch fehlenden aus.

Das Zusammenspiel ist einfach:

Git speichert den vollständigen Änderungsverlauf Deiner .sql-Dateien.
Flyway bringt diese Änderungen in der richtigen Reihenfolge auf den SQL Server.

Beide sind für Einzelentwickler kostenlos.

Das mentale Modell: Zwei Sorten von Datenbankobjekten

Bevor wir loslegen, ein wichtiges Konzept, das Dir die Hälfte der späteren Arbeit abnimmt. Flyway unterscheidet zwei Arten von Änderungsdateien:

Versioned Migrations: Einmal-Änderungen

Dateiname beginnt mit V, gefolgt von einer Nummer: V1__baseline.sql, V2__kunde_email_spalte.sql. Diese Dateien laufen genau einmal gegen die Datenbank. Typisch für:

Tabelle anlegen
Spalte hinzufügen
Index erstellen
Default-Wert ändern
Constraint anlegen

Sie sind unveränderlich. Einmal ausgeführt, wird die Datei nicht mehr angefasst. Jede neue Änderung bekommt eine neue Nummer.

Repeatable Migrations: Immer-aktualisieren

Dateiname beginnt mit R: R__vw_OffeneRechnungen.sql, R__usp_RechnungAnlegen.sql. Diese Dateien werden jedes Mal neu ausgeführt, wenn sich der Inhalt geändert hat. Perfekt für Objekte, die man per CREATE OR ALTER definiert:

Stored Procedures
Views
Functions
Trigger

Du hast eine Datei pro Objekt, und diese Datei wächst über die Zeit mit jeder Änderung — genau wie Du es von Quellcode gewohnt bist.

Das ist der entscheidende Punkt: Für die Dinge, die sich am häufigsten ändern (Prozeduren, Views), musst Du nicht für jede Änderung eine neue Datei anlegen. Nur für Tabellen-Änderungen, und davon gibt es pro Jahr vielleicht 20 bis 30.

Die Vorbereitung: Was Du brauchst

Du brauchst:

Einen SQL Server, auf dem Dein Backend läuft (kann SQL Server 2016, 2019, 2022 sein — Flyway unterstützt alle gängigen Versionen).
SSMS 22 (oder jede andere SSMS-Version), um SQL zu schreiben und auszuführen.
Git — entweder als eigenständige Installation oder über die in SSMS 22 eingebaute Git-Komponente.
Flyway Community Edition — ein kostenloses Kommandozeilenwerkzeug.
Java, weil Flyway in Java geschrieben ist. In den aktuellen Flyway-Download-Paketen ist aber eine Java-Runtime bereits enthalten, Du musst also nichts zusätzlich installieren.

Git installieren

Wenn Du bei der SSMS-22-Installation die Komponente „Versionskontrolle – Git“ mitinstalliert hast, bist Du fertig. Ansonsten lade Git von git-scm.com herunter und installiere es mit den Standardeinstellungen.

Einmalige Einrichtung Deiner Identität (damit Commits Deinen Namen tragen), in der Eingabeaufforderung:

git config --global user.name "Dein Name"
git config --global user.email "deine@email.de"

Flyway installieren

Lade Flyway Community Edition von flywaydb.org/download herunter. Es ist ein ZIP-Archiv — entpacke es nach C:\Tools\flyway (oder wo Du magst, nur kein Pfad mit Leerzeichen). Keine Installation nötig.

Zum Testen, ob es läuft, öffnest Du eine Eingabeaufforderung:

C:\Tools\flyway\flyway -v

Wenn eine Versionsnummer erscheint, ist alles gut. Für den Komfort solltest Du C:\Tools\flyway noch zur PATH-Umgebungsvariablen hinzufügen, dann kannst Du überall einfach flyway tippen.

Schritt 1: Das Repository anlegen

Für jedes Kundenprojekt legst Du einen eigenen Ordner an. Nehmen wir als Beispiel einen Kunden „Müller GmbH“:

C:\Projekte\mueller-db\

In dieser Struktur wird es später so aussehen:

mueller-db\
├── .git\                    (versteckt, von Git angelegt)
├── .gitignore
├── flyway.conf
├── flyway.conf.example
├── sql\
│   ├── V1__baseline.sql
│   ├── V2__kunde_ustidnr.sql
│   ├── R__vw_OffeneRechnungen.sql
│   └── R__usp_RechnungAnlegen.sql
└── README.md

Zum Anlegen öffnest Du eine Eingabeaufforderung und tippst:

cd C:\Projekte
mkdir mueller-db
cd mueller-db
mkdir sql
git init

Der Befehl git init macht aus dem Ordner ein Git-Repository. Ab sofort kann Git in diesem Ordner Änderungen verfolgen.

Schritt 2: Die Baseline ziehen

Jetzt kommt der wichtigste konzeptionelle Schritt. Du hast einen bestehenden SQL Server mit einer bestehenden Datenbank. Die willst Du nicht neu aufbauen — Du willst einen „Schnappschuss“ des aktuellen Zustands als Startpunkt im Git ablegen und ab hier saubere Historie aufbauen.

Aktuelles Schema scripten

In SSMS:

Rechtsklick auf die Datenbank → Aufgaben → Skripts generieren
Im Assistenten: Gesamte Datenbank und alle Datenbankobjekte auswählen
In Zwischenablage oder Datei speichern. Nimm Datei, Ziel C:\Projekte\mueller-db\sql\V1__baseline.sql
Vor dem Speichern auf Erweitert klicken und prüfen:
- Skript für Serverversion: Die Version Deines tatsächlichen Servers
- Skripterstellung für Datentypen: Schema und Daten nur Schema (keine Daten!)
- Abhängige Objekte: Ja
- Indizes skripten: Ja
- Trigger skripten: Ja
- CREATE DATABASE skripten: Nein (wichtig — die Datenbank existiert ja schon)
- USE DATABASE skripten: Nein

Fertig. Du hast jetzt eine V1__baseline.sql, die den aktuellen Zustand der Datenbank beschreibt.

Wichtig: Diese Datei nicht ausführen!

Die Baseline-Datei ist ein Dokument, keine Anweisung. Dein Live-System ist bereits in diesem Zustand. Flyway soll die Datei kennen, aber nicht ausführen. Das erreichen wir gleich über den baseline-Befehl.

Schritt 3: Flyway konfigurieren

Im Projektordner legst Du eine Datei flyway.conf an (einfach mit Notepad oder SSMS):

flyway.url=jdbc:sqlserver://SERVERNAME;databaseName=MuellerDB;encrypt=true;trustServerCertificate=true
flyway.user=mueller_deploy
flyway.password=GeheimesPasswort123!
flyway.locations=filesystem:./sql
flyway.schemas=dbo
flyway.defaultSchema=dbo
flyway.baselineVersion=1
flyway.baselineDescription=baseline

Ein paar Erklärungen:

flyway.url ist die JDBC-Verbindungszeichenfolge zum SQL Server. SERVERNAME ersetzt Du durch Deinen tatsächlichen Servernamen, MuellerDB durch Deinen Datenbanknamen. Die Optionen encrypt=true;trustServerCertificate=true sind für moderne SQL-Server-Treiber notwendig, auch bei lokalen Verbindungen.
flyway.user / flyway.password — ein SQL-Server-Login mit Rechten auf die Datenbank. Für die Produktivnutzung empfehle ich ein dediziertes Deploy-Konto, nicht Deinen persönlichen Account.
flyway.locations zeigt auf den Ordner, in dem Deine Migrationen liegen.
flyway.schemas — das Schema, in dem Flyway arbeiten soll (bei klassischen Access-Migrationen fast immer dbo).
flyway.baselineVersion — die Version, die als Startpunkt gilt.

Credentials nicht ins Git!

Die Datei flyway.conf enthält das Passwort und darf niemals ins Git-Repository. Dafür legen wir eine .gitignore im Projektordner an:

flyway.conf
*.log

Zusätzlich kopierst Du flyway.conf nach flyway.conf.example und entfernst dort das Passwort. Die Example-Datei kommt ins Git, damit Du (oder ein Kollege) später weißt, welche Einstellungen nötig sind.

Schritt 4: Flyway die Baseline beibringen

Jetzt sagst Du Flyway: „Dieser Zustand ist Version 1, bitte nicht ausführen, sondern nur merken.“

In der Eingabeaufforderung im Projektordner:

flyway baseline

Flyway verbindet sich mit der Datenbank, legt die Kontrolltabelle flyway_schema_history an und trägt dort Version 1 als „Baseline“ ein. Die V1__baseline.sql wird dabei nicht ausgeführt — das ist die ganze Magie.

Zur Kontrolle:

flyway info

Du solltest eine Tabellenansicht sehen, in der V1 mit Status „Baseline“ steht.

Und in SSMS siehst Du jetzt in der Müller-Datenbank eine neue Tabelle dbo.flyway_schema_history — die kleine Buchhaltung, die Flyway für Dich führt.

Schritt 5: Der erste Commit

Jetzt kommt Git ins Spiel. Du hast einen sauberen Ausgangszustand: ein Projektordner mit einer Baseline-Datei, einer Konfigurationsvorlage, einer .gitignore. Den packst Du in den ersten Commit.

git add .
git commit -m "Initiales Projekt für Müller GmbH: Baseline und Flyway-Konfiguration"

git add . sagt: „Alle Änderungen im aktuellen Ordner für den nächsten Commit vormerken“ (außer die in .gitignore ausgeschlossenen, also außer der echten flyway.conf).

git commit -m "..." macht daraus einen Eintrag in der Historie, mit der angegebenen Begründung.

Wenn Du git log tippst, siehst Du Deinen ersten Commit. Herzlichen Glückwunsch — ab hier ist jede weitere Änderung nachvollziehbar.

Schritt 6: Die erste echte Änderung

Stell Dir vor, der Kunde ruft an: „Wir brauchen auf der Kunde-Tabelle ein Feld für die Umsatzsteuer-ID.“ Ab jetzt folgst Du immer demselben Muster.

Neue Migration anlegen

Im Ordner sql legst Du eine neue Datei an:

V2__kunde_ustidnr.sql

Der Dateiname ist wichtig: V wie Versioned, 2 als nächste freie Nummer, doppelter Unterstrich, beschreibender Name (keine Leerzeichen, Unterstriche statt Bindestrichen empfiehlt sich), Endung .sql.

Inhalt:

ALTER TABLE dbo.Kunde
    ADD UStIdNr nvarchar(20) NULL;
GO

Migration ausführen

flyway migrate

Flyway vergleicht die Dateien im sql-Ordner mit der Kontrolltabelle, sieht, dass V2 noch nicht gelaufen ist, führt sie aus und trägt sie als erledigt ein. Zur Kontrolle nochmal flyway info — jetzt steht V2 mit Status „Success“ drin.

Ins Git committen

git add sql/V2__kunde_ustidnr.sql
git commit -m "Kunde: Spalte UStIdNr für Rechnungsvorlage hinzugefügt (Anforderung Müller, 14.03.)"

Fertig. Das war der komplette Zyklus einer einfachen Änderung. Dauer: 2 Minuten, davon eine Minute für das SQL selbst.

Schritt 7: Eine Stored Procedure pflegen

Jetzt wird es interessant. Der Kunde braucht eine Prozedur, die zum Monatsende offene Rechnungen auflistet. Weil sich solche Prozeduren häufig ändern, nutzen wir eine Repeatable Migration.

Datei anlegen

sql\R__usp_OffeneRechnungen.sql

Inhalt, in der ersten Fassung:

CREATE OR ALTER PROCEDURE dbo.usp_OffeneRechnungen
    @Stichtag date = NULL
AS
BEGIN
    SET NOCOUNT ON;

    IF @Stichtag IS NULL
        SET @Stichtag = GETDATE();

    SELECT
        r.RechnungID,
        r.Rechnungsnummer,
        r.Rechnungsdatum,
        r.Betrag,
        k.Kundenname
    FROM dbo.Rechnung r
        INNER JOIN dbo.Kunde k ON k.KundeID = r.KundeID
    WHERE r.Bezahlt = 0
      AND r.Rechnungsdatum <= @Stichtag
    ORDER BY r.Rechnungsdatum;
END;
GO

Ausführen und committen

flyway migrate
git add sql/R__usp_OffeneRechnungen.sql
git commit -m "Neue Prozedur usp_OffeneRechnungen für Mahnwesen"

Zwei Wochen später: die Prozedur wird erweitert

Der Kunde will zusätzlich die Tage der Überfälligkeit sehen. Du öffnest dieselbe Datei R__usp_OffeneRechnungen.sql und erweiterst den SELECT:

CREATE OR ALTER PROCEDURE dbo.usp_OffeneRechnungen
    @Stichtag date = NULL
AS
BEGIN
    SET NOCOUNT ON;

    IF @Stichtag IS NULL
        SET @Stichtag = GETDATE();

    SELECT
        r.RechnungID,
        r.Rechnungsnummer,
        r.Rechnungsdatum,
        r.Betrag,
        DATEDIFF(DAY, r.Rechnungsdatum, @Stichtag) AS TageUeberfaellig,
        k.Kundenname
    FROM dbo.Rechnung r
        INNER JOIN dbo.Kunde k ON k.KundeID = r.KundeID
    WHERE r.Bezahlt = 0
      AND r.Rechnungsdatum <= @Stichtag
    ORDER BY r.Rechnungsdatum;
END;
GO

Dann:

flyway migrate

Flyway erkennt an einer Checksum, dass der Inhalt der R__-Datei sich geändert hat, und führt sie erneut aus. Die Prozedur auf dem Server ist jetzt aktualisiert.

git add sql/R__usp_OffeneRechnungen.sql
git commit -m "usp_OffeneRechnungen: Spalte TageUeberfaellig ergänzt"

Das ist der entscheidende Vorteil der Repeatable Migrations: Du hast eine Datei pro Objekt, die mit der Zeit wächst. Drei Monate später kannst Du mit git log sql/R__usp_OffeneRechnungen.sql die vollständige Entwicklungsgeschichte dieser Prozedur sehen, mit Deinen eigenen Commit-Nachrichten als Dokumentation.

Der tägliche Ablauf — zusammengefasst

Ab jetzt folgst Du immer demselben Muster. Egal ob neue Spalte, neuer Index oder geänderte Prozedur:

Datei anlegen oder öffnen im sql-Ordner
- Neue Tabellen-/Strukturänderung: V{nächste Nummer}__{beschreibung}.sql
- Prozedur/View/Function neu oder geändert: R__{objektname}.sql
SQL schreiben — bei V-Dateien die reine Änderung, bei R-Dateien immer CREATE OR ALTER ...
flyway migrate — bringt die Änderung auf den Server
In SSMS prüfen, dass das Ergebnis passt
git add + git commit -m "..." mit aussagekräftiger Nachricht

Fünf Schritte, nach zwei Wochen Übung geht das in weniger als einer Minute zusätzlich zur reinen SQL-Arbeit.

Die eine wichtige Disziplin

Der ganze Ansatz funktioniert nur unter einer Bedingung: Jede Änderung am Live-System geht über Flyway. Kein „ich mach das schnell mal manuell in SSMS“. Sobald Du einmal manuell an der Produktivdatenbank herumschraubst, ohne es in eine Migrationsdatei zu schreiben, ist der Zustand im Git nicht mehr synchron mit der Realität, und Deine Versionskontrolle ist nur noch halb die Wahrheit.

Das ist die größte Umgewöhnung aus der Access-Welt. In Access wirfst Du den Tabellen-Entwurf auf und klickst eine Spalte dazu. In der SQL-Server-Welt mit Flyway schreibst Du eine ALTER TABLE-Anweisung in eine Datei.

Der Gewinn ist: Du weißt immer, in welchem Zustand Dein System ist. Und wenn der Kunde in sechs Monaten fragt, warum die Spalte Rabatt jetzt decimal(5,2) statt decimal(4,2) ist, hast Du es schwarz auf weiß im Git — mit Datum und Grund.

Git-Bedienung innerhalb von SSMS

Wenn Du die Komponente „Versionskontrolle – Git“ bei der SSMS-22-Installation mitgewählt hast, kannst Du die oben gezeigten Git-Schritte direkt in SSMS erledigen, ohne die Kommandozeile zu bemühen:

Ansicht → Git-Änderungen öffnet ein Fenster, in dem Du alle geänderten Dateien siehst.
Commit-Nachricht oben eintragen, „Alle committen“ klicken.
Ansicht → Git-Repository zeigt die Historie an.

Für den Anfang reicht das vollkommen. Kommandozeilen-Git musst Du nicht zwingend lernen, solltest es aber später einmal zumindest in Grundzügen tun, weil jede Anleitung im Internet in Kommandozeilenbefehlen geschrieben ist.

Was dieser Beitrag bewusst weglässt

Damit Du nicht erschlagen wirst, habe ich einige Themen bewusst ausgeklammert. Sie werden relevant, sobald Du über ein einzelnes Live-System hinausgehst:

Test- und Entwicklungsumgebungen. Der nächste logische Schritt ist eine zweite Datenbank, auf der Du Migrationen erst prüfst, bevor sie auf den Live-Server gehen. Das ist mit Flyway trivial — eine zweite flyway.conf-Datei reicht.
Branches in Git. Feature-Branches, Merging, Pull Requests. Für Einzelentwickler auf einem Live-System nicht nötig. Wenn Du ins Team-Umfeld wechselst, kommt das Thema automatisch.
Remote-Repositories. GitHub, GitLab, Azure DevOps. Ein reines lokales Repo ist für den Einstieg völlig in Ordnung, aber für die eigene Datensicherheit solltest Du relativ bald ein Remote anlegen — und sei es ein privates GitHub-Repo für Dich allein.
Rollback-Strategien. Flyway unterstützt Undo-Migrationen, aber nur in der kommerziellen Edition. Für Einzelentwickler auf einem Live-System ist die bessere Strategie ohnehin: vor jeder nicht-trivialen Migration ein Datenbank-Backup ziehen.
Mehrere Kunden parallel. Pro Kunde ein eigenes Repo mit eigener flyway.conf. Skalierung ist einfach, aber das ist Stoff für einen Folgebeitrag.

Fazit

Der Umstieg von Access-Backend auf versionierten SQL Server ist weniger ein technisches als ein konzeptionelles Upgrade. Das Tooling ist kostenlos, die Bedienung nach kurzer Eingewöhnung trivial, der Gewinn aber erheblich: Du weißt jederzeit, was auf Deinem Server passiert ist, Du kannst Änderungen nachvollziehen, und Du legst die Grundlage dafür, später mit Test-Umgebungen, mehreren Kunden und echten Deployment-Prozessen zu arbeiten.

Das Wichtigste ist der Anfang. Nimm einen bestehenden Kunden, ziehe eine Baseline, mach den ersten Commit — und ab der nächsten Schema-Änderung läuft alles über Flyway. Nach vier Wochen ist es Gewohnheit, nach drei Monaten willst Du nicht mehr zurück.

Struktur vor KI. Und in diesem Fall: Struktur vor Klickerei.

Wenn Du als Access-Entwickler Dein erstes SQL-Server-Backend versionieren willst und Unterstützung bei der initialen Einrichtung brauchst — von der Baseline über die Flyway-Konfiguration bis zum ersten sauberen Workflow — melde Dich gern. Ein halber Nachmittag reicht, und Du hast einen Prozess, der Dich die nächsten Jahre trägt.