SSISDB auf einen anderen SQL Server migrieren – meine bewährte Vorgehensweise

Eine Aufgabe, die jedem SQL Server DBA früher oder später mehrfach begegnet: SSISDB auf einen neuen Server migrieren. Egal ob System-Upgrade, Hardware-Austausch oder Umzug in die Cloud – diese Migration gehört zum Alltag. Ich habe sie über die Jahre mehrfach durchgeführt – und versuche jedes Mal, den Ablauf weiter zu verbessern.

In diesem Beitrag zeige ich dir meinen typischen Ansatz – was sich bewährt hat, worauf du achten solltest und wie du alle Projekte, Konfigurationen und Historien vollständig übernimmst.

Warum die SSISDB-Migration so wichtig ist

Die SSISDB – auch bekannt als Integration Services Catalog – ist weit mehr als nur ein Speicherort für SSIS-Pakete. Sie stellt die zentrale Verwaltungs- und Ausführungsplattform für alle deployten SSIS-Projekte dar. Hier werden nicht nur die Pakete selbst gespeichert, sondern auch alle Umgebungen, Parameter, Ausführungsprotokolle, Projektversionen und Sicherheitseinstellungen.

Wer nur die Packages „irgendwie rüberkopiert“, ohne die SSISDB zu migrieren, verliert schnell wichtige Konfigurationen und Metadaten, die für eine stabile und wartbare SSIS-Umgebung essenziell sind:

• Ausführungsprotokolle und Historie
• Umgebungs-Referenzen und Variablen
• Ordnerstruktur und Berechtigungen
• Versionshistorie von Projekten

Daher empfehle ich immer eine saubere SSISDB-Migration auf einen anderen Server, statt alle Projekte händisch neu zu deployen.

Vorbereitung: Die Pre-Migration-Checkliste

Bevor ich loslege, prüfe ich folgende Punkte:

• SSIS ist auf dem Ziel-Server installiert (Katalog wurde erstellt)
• Ziel-Server ist mindestens gleich oder neuer in der Version
• Ich habe Rechte für BACKUP, RESTORE und Projektbereitstellung
• Servicekonten und Zugangsdaten sind geklärt
• Alle Abhängigkeiten und Custom Assemblies sind dokumentiert

Und ganz wichtig: Ich mache immer zuerst eine Test-Wiederherstellung auf einer Non-Prod-Instanz.

Mein Migrationsablauf – Schritt für Schritt

Ich orientiere mich stark an dem sehr guten Beitrag auf MSSQLTips – habe aber über die Jahre eigene Erfahrungen eingebaut.

1. SSISDB-Datenbank sichern

BACKUP DATABASE SSISDB TO DISK = 'D:\Backup\SSISDB.bak' WITH COMPRESSION;

Wichtig: auch den Verschlüsselungsschlüssel sichern:

BACKUP MASTER KEY TO FILE = 'D:\Backup\SSISDB_MasterKey.bak'
ENCRYPTION BY PASSWORD = 'StarkesPasswort123';

Ohne den Master Key lässt sich SSISDB später nicht wiederherstellen!

2. Wiederherstellen auf dem Ziel-Server

RESTORE DATABASE SSISDB FROM DISK = 'D:\Backup\SSISDB.bak'
WITH MOVE 'SSISDB_data' TO 'D:\Data\SSISDB.mdf',
     MOVE 'SSISDB_log' TO 'D:\Log\SSISDB.ldf';

Dann den Master Key wiederherstellen:

RESTORE MASTER KEY FROM FILE = 'D:\Backup\SSISDB_MasterKey.bak'
DECRYPTION BY PASSWORD = 'StarkesPasswort123'
ENCRYPTION BY PASSWORD = 'NeuesSicheresPasswort456';

3. SSIS-Katalog ggf. manuell neu erstellen

CREATE CATALOG SSISDB
    AUTHORIZATION [DeineDomäne\DeinSQLUser]
    ENCRYPTION BY PASSWORD = 'NeuesSicheresPasswort456';

Hinweis: Das ist nicht immer nötig – meist reicht das Wiederherstellen von SSISDB + Master Key aus.

4. Nachkontrolle nach der Migration

Nach der technischen Wiederherstellung kommt für mich der wichtigste Teil: das strukturierte Testen. Ich nehme mir bewusst Zeit, um die SSIS-Umgebung gründlich zu prüfen. Dafür verwende ich in der Regel ein eigenes Testskript und führe einige Standardpakete mit unterschiedlichen Umgebungen aus.

• Sind alle Ordner und Projekte sichtbar?
• Lassen sich Pakete fehlerfrei ausführen – sowohl manuell als auch über SQL Agent Jobs?
• Funktionieren die Umgebungsvariablen korrekt, inklusive Parameterzuweisungen?
• Ist die Ausführungshistorie vollständig und abrufbar?

Ich teste auch gezielt Pakete mit Abhängigkeiten zu Dateien, FTP-Quellen, Netzwerklaufwerken oder anderen Servern. Wenn Proxys oder gespeicherte Credentials verwendet wurden, kontrolliere ich diese separat.

Mein Tipp: Nicht nur eine Erfolgsmeldung im Deployment reicht. Simuliere im Idealfall eine komplette Nachtverarbeitung oder eine produktionsnahe Ausführungssituation. Nur so findest du eventuelle Seiteneffekte frühzeitig und kannst sie stressfrei beheben, bevor es ernst wird.

• Lässt sich ein Projekt bereitstellen und ausführen?
• Funktionieren die Umgebungsvariablen korrekt?
• Ist die Ausführungshistorie vorhanden?

Wichtige Learnings aus der Praxis

Nach etlichen Migrationen habe ich mir Folgendes angewöhnt:

• Trockenlauf durchführen: Immer vorher in einer Testumgebung prüfen
• SQL Agent Jobs prüfen: Oft sind darin SSIS-Pakete referenziert
• Achtung bei Proxies und Credentials: Besonders bei anderen Servicekonten
• Logins und Berechtigungen: Eigene Rollen und Benutzer ggf. neu zuweisen
• Dokumentation: Ich arbeite mit einer eigenen Migrations-Checkliste

Fazit: Mit Struktur zur erfolgreichen Migration

Eine saubere SSISDB-Migration auf einen anderen Server ist absolut machbar – wenn man sie gut vorbereitet und weiß, worauf es ankommt. Die größte Fehlerquelle ist oft das Vergessen des Master Keys oder falsche SQL-Versionen beim Restore.

Ich hoffe, dieser Leitfaden hilft dir bei deinem nächsten Migrationsprojekt. Wenn du Fragen hast, Unterstützung brauchst oder deine eigene Methode teilen willst – schreib mir gerne!

Björn Peters

Björn arbeitet auch weiterhin aus Griechenland als Senior Consultant – Microsoft Data Platform und Cloud für die Kramer&Crew in Köln. Auch der Community bleibt er aus der neuen Heimat treu, er engagiert sich auf Data Saturdays oder in unterschiedlichen Foren. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure SQL für Science-Fiction, Backen 😉 und Radfahren.