Zweiphasige Datenbankmigrationen per WinForms GUI —
auch ohne direkte Netzwerkverbindung zwischen Quell- und Zielserver
Uwe Janke · Senior SQL Server DBA · dtcSoftware
SQL Server Migrationen in komplexen Netzwerkumgebungen — manuell, fehleranfällig, nicht reproduzierbar.
Quell- und Zielserver in getrennten Netzsegmenten, DMZ oder unterschiedlichen Rechenzentren — kein direkter SQL-Zugriff möglich
Was wurde migriert? Welche Datenbanken? Welche Version? Kein strukturiertes Log, kein Nachweis
Backup auf Quelle, Datei übertragen, Restore auf Ziel, Logins manuell anlegen, Jobs neu erstellen — jedes Mal anders
Neue Migration? Anderer DBA? Kein definierter Prozess — jedes Mal neu erfunden, jedes Mal anders
Logins, SQL Agent Jobs, Linked Server oder SSIS-Pakete werden vergessen oder inkonsistent migriert
Keine Möglichkeit die Migration vorab zu simulieren — Fehler fallen erst in der Produktion auf
Ein Tool, ein Prozess, ein Log. Rolle wählen — der Rest läuft automatisch. Auch ohne direkte Netzwerkverbindung.
Rollenauswahl beim Start (Source / Target / Auto). Nur die jeweils relevante Seite wird angezeigt
Phase 1 auf dem Quellserver, Phase 2 auf dem Zielserver — JSON-State-Datei als sicheres Bindeglied
Zielserver erreichbar: Direct-Modus. Nicht erreichbar: TwoPhase-Modus. Automatisch, ohne Eingriff
| Vorher | Nachher |
|---|---|
| Manueller mehrstündiger Prozess | Automatisiert, strukturiert |
| Getrennte Netze = manueller Datentransfer | TwoPhase-Modus mit State-Datei |
| Logins / Jobs vergessen | Vollständige Objektmigration |
| Kein Log, kein Nachweis | Strukturiertes Log, jeder Schritt |
| Kein Test möglich | WhatIf simuliert alles vorab |
Migrationen funktionieren — auch wenn sich Quelle und Ziel nicht kennen.
Kernidee: Die Migration wird in zwei unabhängige Phasen aufgeteilt, die über eine JSON-State-Datei kommunizieren.
Alle Datenbanken, Logins, Jobs und Linked Server werden eingelesen und zur Auswahl angeboten
Ausgewählte Datenbanken werden per Backup/Restore oder Detach/Attach gesichert (mit Compression)
Logins, Agent Jobs, Linked Server und optional SSIS-Pakete werden in die State-Datei serialisiert
JSON-Datei mit allen Migrationsinformationen wird vom Exchange-Pfad geladen und validiert
Datenbanken werden auf dem Zielserver wiederhergestellt — inkl. Backup-Pfad-Mapping
Logins anlegen, Jobs importieren, Linked Server einrichten. Vollständiges Log aller Schritte
Klassische, sichere Methode. Datenbank bleibt auf dem Quellserver online während das Backup läuft.
| ✓ | Online-Betrieb möglich |
| ✓ | Compression reduziert Dateigröße |
| ✓ | Checksum-Validierung |
| ~ | Längere Migrationszeit |
Schnelle Methode für geplante Wartungsfenster. Datenbank wird kurz offline gesetzt.
| ✓ | Schneller Datentransfer |
| ✓ | Kein Backup-Overhead |
| ~ | Kurze Downtime nötig |
| ~ | Wartungsfenster erforderlich |
| Objekt | Methode | Besonderheit |
|---|---|---|
| Datenbanken | Backup/Restore oder Detach/Attach | Mit Pfad-Mapping für abweichende Laufwerke |
| Logins | SID-Übertragung via dbaTools | Windows- und SQL-Logins, DB-Berechtigungen |
| SQL Agent Jobs | Export / Import | AG-Sync-Jobs optional ausschliessen |
| Linked Server | Serialisierung via State-Datei | Credentials werden nicht übertragen |
| SSIS-Pakete | SSISDB-Export / Deploy | Optional, nur bei installiertem SSIS |
Alle Pfade und Standardoptionen in einer JSON-Datei — wird beim Start automatisch eingelesen. GUI-Eingaben überschreiben die Konfiguration zur Laufzeit.
// migration.config.json
{
"ExchangePath":
"\\\\FILESERVER\\SQLBackup\\state",
"BackupDirectory":
"\\\\FILESERVER\\SQLBackup",
"LogPath":
"C:\\Logs\\SQLMigration",
"MigrationMethod": "BackupRestore",
"WhatIf": false,
"MigrateLogins": true,
"MigrateAgentJobs":true,
"MigrateLinkedServer":true,
"MigrateSsis": false
}| Modus | Beschreibung |
|---|---|
Source | Nur Phase 1 — Export auf dem Quellserver |
Target | Nur Phase 2 — Import auf dem Zielserver |
Auto | State-Datei vorhanden → Target, sonst → Source |
# Interaktiv (Rollenauswahl per Dialog)
.\SQL-Migration.ps1
# Rolle vorgeben
.\SQL-Migration.ps1 -Role Source
.\SQL-Migration.ps1 -Role Target
# WhatIf-Simulation
.\SQL-Migration.ps1 -WhatIfAlle Migrationsschritte werden vollständig simuliert — ohne eine einzige Änderung am System.
SQL-Verbindung zu Quelle und Ziel wird getestet und protokolliert
Alle zu migrierenden Datenbanken, Logins und Jobs werden aufgelistet
Bereits vorhandene Datenbanken oder Logins auf dem Zielserver werden gemeldet
Vollständiges WhatIf-Log zeigt was passieren würde — ohne Ausführung
-WhatIf testen.
Jeder Schritt wird mit Zeitstempel, Status und Fehlermeldung protokolliert.
| Anforderung | Hinweis |
|---|---|
| Windows Server | 2016 oder neuer — Quell- und Zielserver |
| SQL Server (Quelle) | Ab 2016 — Enterprise oder Standard |
| SQL Server (Ziel) | 2016 bis 2025 — höher oder gleich Quelle |
| PowerShell 5.1 | Vorinstalliert auf WS 2022 |
dbaTools ≥ 2.0 | Wird automatisch installiert |
| Lokaler Administrator | Auf Quell- und Zielserver |
| Netzwerk-Share erreichbar | Für Exchange-Pfad (TwoPhase) |
Beide Server im selben Netz erreichbar → vollautomatisch in einem Lauf
Exchange-Pfad auf gemeinsam zugänglichem Share → State-Datei + Backups automatisch übergeben
State-Datei + Backup-Ordner per SFTP, USB oder Kurier zwischen Standorten übertragen
Das Migration Tool ist Teil einer vollständigen DBA-Toolchain — jedes Tool übernimmt einen klar abgegrenzten Aufgabenbereich.
Standardisierte SQL Server Installation auf dem Zielserver — bevor die Migration beginnt.
Überträgt Datenbanken, Logins, Jobs und Konfiguration vom Alt- auf den Neusystem.
Laufender Betrieb: Backup, Monitoring, Health-Checks, AG-Sync auf dem Zielserver.
✓ Im Scope
✗ Nicht im Scope
Funktioniert auch ohne direkte Netzwerkverbindung — JSON-State-Datei als Bindeglied zwischen Quell- und Zielserver
Datenbanken, Logins, Agent Jobs, Linked Server und SSIS-Pakete in einem kontrollierten Prozess
Vollständige Simulation ohne Systemeingriff — Konflikte und Fehler werden vorab erkannt
Direct oder TwoPhase — das Tool entscheidet anhand der Netzwerkerreichbarkeit automatisch
Jeder Schritt protokolliert — Zeitstempel, Status, Fehlermeldung. Nachweis für alle Änderungen
Ressourcen:
github.com/JankeUwe/SQLMigration www.powershelldba.de