SQL Server Migration
Automation
Enterprise-Migrationen zwischen SQL-Server-Instanzen — auch ohne direkte Netzwerkverbindung. GUI-geführt, vollständig automatisiert, mit WhatIf-Modus und lückenlosem Audit-Trail.
Das Migrationsproblem
SQL-Server-Migrationen in Enterprise-Umgebungen scheitern selten an der Technologie — sondern an den organisatorischen und infrastrukturellen Rahmenbedingungen. Drei Kernprobleme stehen dabei immer wieder im Mittelpunkt.
Quell- und Zielserver sind nicht gleichzeitig erreichbar — Cross-Domain-Szenarien, Air-Gap-Umgebungen oder Sicherheitszonen verhindern eine direkte Verbindung. Klassische Migrationswerkzeuge versagen hier vollständig.
- Cross-Domain ohne Vertrauensstellung
- Air-Gapped Server
- Getrennte Sicherheitszonen (DMZ/intern)
- Kein gemeinsamer UNC-Pfad erreichbar
Manuell durchgeführte Migrationen sind fehleranfällig, nicht reproduzierbar und hinterlassen keinen verwertbaren Audit-Trail. Bei nächtlichen Wartungsfenstern ist das Risiko menschlicher Fehler besonders hoch.
- Vergessene Objekte (Logins, Jobs, Proxies)
- Inkonsistente Ergebnisse
- Kein strukturiertes Rollback
- Fehlende Dokumentation
Eine SQL-Server-Instanz besteht nicht nur aus Datenbanken. Logins, SQL Agent Jobs, Linked Server, Credentials, Agent Proxies und DB-User müssen vollständig und in der richtigen Reihenfolge migriert werden — sonst bricht die Produktion.
- Abhängigkeiten zwischen Objekten
- Reihenfolge der Migration kritisch
- Orphaned Users nach Login-Migration
- Proxy/Credential-Abhängigkeiten bei Agent Jobs
Zweiphasige Migration
Der zentrale Architektur-Ansatz des Tools: Die Migration wird in zwei voneinander unabhängige Phasen aufgeteilt, die nicht gleichzeitig laufen müssen. Ein JSON-State-File auf einem gemeinsamen Exchange-Pfad verbindet beide Phasen — auch über Server-Neustarts hinweg.
- Verbindung zu Quell-SQL-Server
- Objekte inventarisieren & auswählen
- Datenbank-Backup erstellen (UNC oder lokal)
- Logins, Jobs, Credentials exportieren
- State File schreiben (JSON)
- Phase 1 abgeschlossen — Server kann neu starten
+ Backup-Dateien
- State File vom Exchange Path lesen
- Verbindung zu Ziel-SQL-Server
- Datenbanken restoren / attachen
- Logins, Jobs, Credentials importieren
- DB-User reparieren (Orphaned Users)
- Migration als abgeschlossen markieren
In Cross-Domain- und Air-Gap-Szenarien können Quell- und Zielserver niemals gleichzeitig vom selben Rechner aus erreicht werden. Das Tool löst dieses Problem, indem Phase 1 auf dem Quell-Server-Netz ausgeführt wird und alle Ergebnisse in einem State File auf einem gemeinsamen Pfad (USB-Stick, freigegebener Ordner, SFTP) hinterlegt werden. Phase 2 läuft dann vollständig unabhängig auf dem Ziel-Server-Netz — auch Tage später oder nach einem Reboot der Quell-Maschine.
Migrationsmethoden
Das Tool unterstützt zwei bewährte SQL-Server-Migrationsmethoden. Die Wahl hängt von der Datenbankgröße, dem gewünschten Downtime-Fenster und den Zugriffsrechten ab.
Die bevorzugte Methode für Produktivmigrationen. Das Tool erstellt ein COPY_ONLY-Backup direkt auf den UNC-Exchange-Pfad. Falls der Service Account keinen UNC-Zugriff hat, greift ein automatischer Fallback: lokales Backup mit anschließendem Datei-Copy unter Admin-Credentials.
- COPY_ONLY-Backup — beeinflusst keine Backup-Kette
- Direkte UNC-Sicherung (bevorzugt)
- Fallback: lokal sichern + Admin-Copy zu Exchange-Pfad
- Komprimierung aktivierbar
- Backup-Verifikation nach Erstellung
- Restore auf Ziel mit optionalem MOVE
Für Szenarien mit sehr großen Datenbanken und minimalem Downtime-Fenster, wenn die Backup-Dauer das Wartungsfenster übersteigen würde. Die Datenbank wird vom Quell-Server getrennt, die Datenbankdateien kopiert und am Ziel-Server wieder angehängt.
- Detach vom Quell-Server
- MDF/LDF-Dateien zum Exchange-Pfad kopieren
- Attach am Ziel-Server
- Optional: Re-Attach am Quell-Server (für Rollback)
- Geeignet für sehr große Datenbanken (>500 GB)
- Erfordert kompatible SQL-Server-Versionen
Migrierbare Objekte
Das Tool migriert nicht nur Datenbanken. Alle für den Betrieb einer SQL-Server-Instanz relevanten Objekte werden erkannt, selektiv ausgewählt und in der richtigen Abhängigkeits-Reihenfolge übertragen.
Die GUI
Die WinForms-Oberfläche ist bewusst im Dark-Theme von Visual Studio Code gehalten — vertraut für PowerShell-Entwickler. Alle Operationen laufen als Background-Jobs, sodass die UI während langer Migrationen vollständig reaktionsfähig bleibt.
VS Code-ähnliches Erscheinungsbild (#181a20 Hintergrund, #21252b Panels). Reduziert Augenermüdung bei nächtlichen Wartungsfenstern.
Jeder migrierbare Objekttyp hat einen eigenen Tab mit Checkbox-Liste. Selektive Auswahl einzelner Objekte möglich.
Alle Migrationsoperationen laufen als PowerShell-Background-Jobs. Die GUI friert nie ein — Fortschritt wird live angezeigt.
Intelligente Szenario-Erkennung
Das Tool erkennt automatisch, ob eine direkte Migration möglich ist oder ob die zweiphasige Architektur notwendig ist. Die Erkennung basiert auf einer sequenziellen Netzwerk-Teststrategie.
Das Tool testet zunächst eine direkte TCP-Verbindung zum Ziel-Server auf Port 1433. Ist der Test erfolgreich, ist der Ziel-SQL-Server grundsätzlich erreichbar. Schlägt er fehl, ist eine direkte Migration ausgeschlossen.
Bei erfolgreichem TCP-Test wird geprüft, ob der Exchange-Pfad (UNC) sowohl vom Quell- als auch vom Ziel-Server aus erreichbar und beschreibbar ist. Dieser Test bestimmt die Methode des Dateitransfers.
Auf Basis beider Tests wird das Migrationsszenario automatisch gesetzt und in der GUI angezeigt. Der Benutzer kann das erkannte Szenario bei Bedarf manuell überschreiben.
TCP-Test erfolgreich und UNC-Zugriff möglich. Quell- und Zielserver können gleichzeitig angesprochen werden. Beide Phasen laufen in einer einzigen GUI-Session nacheinander ab — kein manueller Wechsel nötig.
TCP-Test fehlgeschlagen oder kein gemeinsamer UNC-Zugriff. Zweiphasige Migration notwendig: Phase 1 auf Quell-Server-Netz, Phase 2 separat auf Ziel-Server-Netz. State File verbindet die beiden Phasen.
State Management
Das Herzstück der zweiphasigen Architektur ist das JSON-State-File. Es wird nach Abschluss von Phase 1 auf dem Exchange-Pfad abgelegt und enthält alle Informationen, die Phase 2 für eine vollständige Wiederherstellung benötigt — unabhängig vom Zustand der Quell-Maschine.
{
"SchemaVersion": "1.1",
"Phase1Server": "SRV-SQL-PROD-01\\MSSQLSERVER",
"Phase2Server": "SRV-SQL-NEW-01\\MSSQLSERVER",
"ExchangePath": "\\\\FILESERVER\\Migration\\2026-05-17",
"MigrationMethod": "BackupRestore",
"Scenario": "TwoPhase",
"Databases": [
"AdventureWorks2022",
"FinanzDB_Produktion",
"AuditLog_2025"
],
"BackupFiles": {
"AdventureWorks2022": "\\\\FILESERVER\\Migration\\2026-05-17\\AdventureWorks2022.bak",
"FinanzDB_Produktion": "\\\\FILESERVER\\Migration\\2026-05-17\\FinanzDB_Produktion.bak",
"AuditLog_2025": "\\\\FILESERVER\\Migration\\2026-05-17\\AuditLog_2025.bak"
},
"Logins": ["AppUser", "ReportUser", "sa"],
"AgentJobs": ["Nightly_Backup", "Weekly_Integrity"],
"LinkedServers": ["REMOTE_SAP_DB"],
"Credentials": ["ProxyAccount_SSIS"],
"Phase1Completed": "2026-05-17T10:23:45",
"Phase2Completed": null,
"Phase2StartedAt": null
}Phase 2 kann völlig unabhängig von Phase 1 starten — auch nach einem Neustart der Quell-Maschine. Alle benötigten Informationen stehen im State File.
Das Tool prüft beim Start von Phase 2, ob Phase 1 abgeschlossen ist (Phase1Completed gesetzt) und schützt vor versehentlichem Doppel-Ausführen.
Das State File dient gleichzeitig als Audit-Artefakt. Wann welche Phase begann und endete ist lückenlos nachvollziehbar — ISO-27001-konform.
Logging & Audit
Jeder Schritt der Migration wird thread-sicher protokolliert — über einen Mutex, der konkurrierende Schreibzugriffe aus parallelen Background-Jobs verhindert. Das Logging erfolgt in zwei Formaten gleichzeitig.
Jeder Log-Eintrag enthält Zeitstempel, Kategorie und Meldungstext. Kategorien (INFO, OK, WARN, ERROR) erlauben eine schnelle visuelle Auswertung im Log-File oder in der integrierten Log-Anzeige der GUI.
[2026-05-17 10:22:04] [INFO] Szenario erkannt: TwoPhase
[2026-05-17 10:22:11] [OK] Backup AdventureWorks2022 abgeschlossen (387 MB)
[2026-05-17 10:23:02] [WARN] UNC-Pfad nicht erreichbar, Fallback auf lokales Backup
[2026-05-17 10:23:44] [OK] State File geschrieben: migration-state.json
[2026-05-17 10:23:45] [OK] Phase 1 abgeschlossen.
Parallel zum Text-Log schreibt das Tool eine strukturierte CSV-Datei. Diese ist direkt in Excel importierbar und eignet sich für Reporting, Auswertung und Compliance-Dokumentation.
2026-05-17 10:22:01,INFO,Connect,Verbindung hergestellt,—
2026-05-17 10:22:04,INFO,Scenario,TwoPhase erkannt,0.3s
2026-05-17 10:22:11,OK,Backup,AdventureWorks2022,98.2s
2026-05-17 10:23:02,WARN,FileTransfer,Fallback aktiv,—
2026-05-17 10:23:44,OK,State,State File geschrieben,0.1s
2026-05-17 10:23:45,OK,Phase1,Abgeschlossen,101.4s
WhatIf-Modus
Der WhatIf-Modus ist eine vollständige Dry-Run-Simulation der gesamten Migration. Kein einziger destruktiver Befehl wird ausgeführt — aber das Tool zeigt exakt, was passieren würde. Ideal für Tests vor dem Produktions-Migrationsfenster.
Der WhatIf-Modus wird in der GUI über den entsprechenden Button aktiviert oder beim CLI-Aufruf mit dem Parameter -WhatIf übergeben. Im WhatIf-Modus wird jede Aktion mit dem Präfix [WHATIF] geloggt — ohne reale Ausführung.
### WhatIf-Simulation — keine realen Änderungen ###
[2026-05-17 09:15:00] [WHATIF] WÜRDE Verbindung zu SRV-SQL-PROD-01 aufbauen
[2026-05-17 09:15:00] [WHATIF] WÜRDE Backup-Restore-Methode verwenden
[2026-05-17 09:15:00] [WHATIF] WÜRDE Backup erstellen: AdventureWorks2022
[2026-05-17 09:15:00] [WHATIF] Ziel: \\FILESERVER\Migration\2026-05-17\AdventureWorks2022.bak
[2026-05-17 09:15:00] [WHATIF] Geschätzte Größe: ~387 MB, Dauer: ~98 Sekunden
[2026-05-17 09:15:00] [WHATIF] WÜRDE Backup erstellen: FinanzDB_Produktion
[2026-05-17 09:15:00] [WHATIF] Ziel: \\FILESERVER\Migration\2026-05-17\FinanzDB_Produktion.bak
[2026-05-17 09:15:00] [WHATIF] Geschätzte Größe: ~12,4 GB, Dauer: ~420 Sekunden
[2026-05-17 09:15:00] [WHATIF] WÜRDE 3 Logins migrieren: AppUser, ReportUser, sa
[2026-05-17 09:15:00] [WHATIF] WÜRDE 2 Agent Jobs migrieren: Nightly_Backup, Weekly_Integrity
[2026-05-17 09:15:00] [WHATIF] WÜRDE State File schreiben: migration-state.json
[2026-05-17 09:15:00] [WHATIF] Simulation abgeschlossen — keine Änderungen vorgenommenModul-Übersicht
Das Tool ist in fünf spezialisierte PowerShell-Module aufgeteilt. Jedes Modul hat eine klar definierte Zuständigkeit und kann unabhängig getestet werden.
| Modul | Funktionen | Zweck |
|---|---|---|
| Connect-SqlServer.psm1 |
New-SqlConnection
Test-SqlConnection
|
SQL-Server-Verbindungen aufbauen und testen. Unterstützt Windows Auth und SQL Login mit SecureString. |
| Get-SqlObjects.psm1 |
Get-SqlDatabases
Get-SqlLogins
Get-SqlDbUsers
Get-SqlLinkedServers
Get-SqlAgentJobs
Get-SqlCredentials
Get-SqlProxies
|
Inventarisierung aller migrierbaren Objekte auf einem SQL-Server. Gibt strukturierte Objekte für die GUI zurück. |
| Invoke-Migration.psm1 |
Invoke-DatabaseMigrationBackupRestore
Invoke-DatabaseMigrationDetachAttach
Invoke-LoginMigration
Invoke-AgentJobMigration
Invoke-CredentialMigration
Invoke-ProxyMigration
Invoke-LinkedServerMigration
|
Kernmodul — führt alle Migrationsmethoden aus. Unterstützt WhatIf-Modus für alle Funktionen. |
| Invoke-MigrationState.psm1 |
Get-MigrationScenario
Write-MigrationState
Read-MigrationState
Complete-MigrationState
|
Verwaltung des JSON-State-Files. Szenario-Erkennung (TCP-Test + UNC-Test) und State-Lebenszyklus. |
| Write-MigrationLog.psm1 |
Write-MigrationLog
|
Thread-sicheres Logging via Mutex. Schreibt gleichzeitig in Text-Log und CSV-Export-Datei. |
Technische Voraussetzungen
Das Tool ist bewusst schlank gehalten — die einzige externe Abhängigkeit ist die dbaTools-Community-Library. Alle anderen Voraussetzungen sind in einer Standard-Windows-Umgebung bereits vorhanden.
| Komponente | Anforderung | Hinweis |
|---|---|---|
| SQL Server | SQL Server 2012+ | Quelle und Ziel. Versions-Upgrades (z.B. 2016 → 2022) werden unterstützt. |
| PowerShell | 5.1 oder höher | PowerShell 7+ ebenfalls kompatibel. Kein Upgrade zwingend erforderlich. |
| dbaTools | 1.x oder 2.x | Installation: Install-Module dbaTools aus PowerShell Gallery. |
| Betriebssystem | Windows 10/11 oder Server 2016+ | WinForms-GUI erfordert Windows. PowerShell Core auf Linux nicht unterstützt. |
| .NET Framework | 4.5 oder höher | Standardmäßig auf Windows 10/11 und Server 2016+ vorhanden. |
| Netzwerk-Zugriff | Exchange Path erreichbar | UNC-Pfad oder lokaler Ordner als Exchange Path. Für Two-Phase: von beiden Seiten lesbar. |
| SQL-Berechtigungen | sysadmin | Für Backup/Restore und Login-Migration werden sysadmin-Rechte auf Quelle und Ziel benötigt. |