SQL Server Migration vorbereiten
Vier Phasen, Rollback zuerst – und warum das Ökosystem das eigentliche Migrationsprojekt ist.
SQL Server Migration vorbereiten
Versions-Upgrade, neue Hardware, Cloud-Pfad: Die vier Phasen, der Rollback-Plan zuerst — und warum der Compatibility Level ein eigener Schritt ist.
Eine SQL-Server-Migration ist wie ein Umzug in eine neue Wohnung: Das Tragen der Möbel ist nicht das Problem. Das Problem sind die tausend Kleinigkeiten, an die niemand denkt — der Schlüssel zum Keller, der noch beim Vormieter liegt, die Waschmaschine, die in der neuen Wohnung einen anderen Anschluss braucht, der Internetvertrag, der erst in drei Wochen umgezogen wird. Genauso ist es beim Server: Die Datenbank von A nach B zu bringen, ist der einfache Teil. Die Logins, die Agent-Jobs, die Linked Server, die Verschlüsselungs-Zertifikate, die Server-Konfiguration — das ganze Ökosystem drumherum mitzunehmen, das ist die eigentliche Arbeit, und genau daran scheitern die meisten Migrationen.
Dieser Beitrag aus dem SQL-Server-Notarztwagen (die Triage-Übersicht liegt unter /sql-server-notarztwagen/) ist die Umzugs-Checkliste, die den Unterschied zwischen einem ruhigen Wochenende und einem Montagmorgen-Albtraum macht: die vier Phasen einer sauberen Migration, die richtige Wahl zwischen In-Place und Side-by-Side, der Compatibility Level als eigener Schritt — und der Rollback-Plan, der vor allem anderen steht. Als Beitrag der GRÜN-Stufe geht es um die gründliche Vorbereitung, die den Notfall verhindert; wenn eine Migration schiefgeht, landet man schnell bei den akuten Beiträgen der ROT-Stufe.
Was eine Migration wirklich umfasst
„Migration“ ist ein Sammelbegriff für mehrere Szenarien, die sich im Detail unterscheiden, aber dieselbe Sorgfalt verlangen: das Versions-Upgrade (von einer älteren SQL-Server-Version auf eine neuere), der Hardware-Wechsel (dieselbe Version, neuer Server), die Plattform-Migration (etwa von einer physischen Maschine in eine VM) und der Cloud-Pfad (in eine Azure SQL Managed Instance oder auf eine VM in der Cloud). Oft kommen mehrere davon zusammen — der typische Fall ist das Versions-Upgrade auf neuer Hardware, also gleich zwei Veränderungen auf einmal.
Der entscheidende Denkfehler, der die meisten Migrationen ins Stolpern bringt, ist die Gleichsetzung von Migration und Datenumzug. Die Datenbank selbst zu bewegen — per Backup/Restore oder Detach/Attach — ist technisch unkompliziert und in den meisten Fällen das kleinste Risiko. Die eigentliche Komplexität steckt in allem, was außerhalb der Datenbankdatei lebt und trotzdem mitmuss: Server-Logins (nicht zu verwechseln mit den Datenbank-Usern, die in der Datenbank stecken — die Logins auf Serverebene müssen separat übertragen werden, sonst stehen die User nach dem Umzug ohne Anmeldung da), die SQL-Agent-Jobs samt Zeitplänen, die Linked Server, die Verschlüsselungs-Schlüssel und Zertifikate, die msdb-Inhalte und die Server-Konfiguration wie MAXDOP und Max Server Memory. Wer nur die Datenbank umzieht, hat eine laufende Datenbank ohne ihr Ökosystem — und merkt das oft erst, wenn nachts der erste Job nicht startet.
Beim Versions-Upgrade kommt ein zweites Risiko hinzu: das veränderte Verhalten. Eine neue SQL-Server-Version bringt einen neuen Kardinalitätsschätzer mit, der Ausführungspläne anders berechnet — und manche Abfrage, die jahrelang schnell lief, kann danach plötzlich einen schlechteren Plan bekommen. Dieses Risiko ist beherrschbar, aber nur, wenn man es kennt und gezielt entschärft, statt es zu übersehen. Genau dafür gibt es die Trennung von Umzug und Compatibility Level, die das Herzstück einer sauberen Versions-Migration ist.
|
Die zwei Risiken jeder Versions-Migration 1. Das Ökosystem geht verloren — Logins, Jobs, Linked Server, Zertifikate, Konfiguration. Die Datenbank kommt an, ihre Umgebung nicht. Lösung: vollständige Inventarliste, nichts vergessen. |
|---|
Die vier Phasen und der Plan B
Eine saubere Migration läuft in vier Phasen — und vor jeder steht der Rollback-Plan. Die folgende Skizze zeigt den Ablauf, die Schlüssel-Entscheidung zum Compatibility Level und die Wahl der Migrationsmethode:
Die Skripte: inventarisieren und vorbereiten
Schritt 1 — Das Ökosystem inventarisieren
Bevor irgendetwas umzieht, brauchst du die vollständige Liste dessen, was mitmuss. Diese Abfragen decken die häufig vergessenen Bestandteile auf:
|
— Server-Logins (muessen separat uebertragen werden!) SELECT name, type_desc, is_disabled, default_database_name FROM sys.server_principals WHERE type IN ('S','U','G') — SQL, Windows-User, Windows-Gruppe AND name NOT LIKE '##%' ORDER BY type_desc, name;
— SQL-Agent-Jobs (Zeitplaene, Schritte muessen mit) SELECT j.name AS Job, j.enabled, c.name AS Kategorie FROM msdb.dbo.sysjobs AS j JOIN msdb.dbo.syscategories AS c ON c.category_id = j.category_id;
— Linked Server SELECT name, product, provider, data_source FROM sys.servers WHERE is_linked = 1; |
|---|
Für die Logins gibt es eine Tücke: Werden SQL-Logins einfach neu angelegt, stimmen die internen Sicherheitskennungen (SIDs) nicht mehr mit den Datenbank-Usern überein — die User werden „verwaist“. Deshalb überträgt man Logins idealerweise mit Skripten, die SID und Passwort-Hash erhalten (Microsofts sp_help_revlogin ist der Klassiker dafür), statt sie von Hand neu zu erstellen.
Schritt 2 — Compatibility Level prüfen und gezielt setzen
|
— Aktuellen Compatibility Level aller Datenbanken pruefen SELECT name, compatibility_level FROM sys.databases WHERE database_id > 4 ORDER BY name;
— NACH der Migration: alten Level zunaechst beibehalten — (Beispiel: 140 = SQL 2017, auch wenn Ziel 160 = SQL 2022 ist) ALTER DATABASE [MeineDB] SET COMPATIBILITY_LEVEL = 140;
— SPAETER, als separater Schritt, kontrolliert anheben: ALTER DATABASE [MeineDB] SET COMPATIBILITY_LEVEL = 160; |
|---|
Diese Trennung ist der wichtigste Einzelschritt einer Versions-Migration: Erst migrieren mit altem Level (die Datenbank verhält sich wie gewohnt), dann in einem separaten, beobachteten Schritt den Level anheben. So weißt du im Problemfall genau, ob der Umzug oder die Verhaltensänderung schuld ist — und der Query Store, vor dem Anheben aktiviert, fängt etwaige Regressionen ab.
Schritt 3 — Logins SID-erhaltend übertragen
|
— Auf dem QUELLSERVER: Skript zum Erhalt von SID + Passwort-Hash — sp_help_revlogin erzeugt CREATE-LOGIN-Statements, — die SID und Hash beibehalten (verhindert verwaiste User). EXEC sp_help_revlogin; — Microsofts Standard-Prozedur
— Auf dem ZIELSERVER nach dem Restore: verwaiste User finden SELECT dp.name AS DBUser, dp.type_desc FROM sys.database_principals AS dp LEFT JOIN sys.server_principals AS sp ON sp.sid = dp.sid WHERE dp.type IN ('S','U') AND sp.sid IS NULL AND dp.name NOT IN ('dbo','guest','sys','INFORMATION_SCHEMA'); |
|---|
In-Place oder Side-by-Side — die Methodenwahl
In-Place-Upgrade — schnell, aber riskant
Beim In-Place-Upgrade wird die bestehende Installation direkt auf die neue Version gehoben — derselbe Server, dieselben Datenbanken, nur die Engine wird getauscht. Der Reiz ist offensichtlich: kein neuer Server, kein Datenumzug, scheinbar weniger Aufwand. Die Kehrseite wiegt aber schwer: Es gibt keinen einfachen Rollback — ist das Upgrade einmal durch, führt der Weg zurück nur über eine vollständige Wiederherstellung, was im Problemfall teure Zeit kostet. Und sämtliche Altlasten ziehen mit: jede Fehlkonfiguration, jeder angesammelte Müll, jede suboptimale Einstellung bleibt erhalten. In-Place ist deshalb eine vertretbare Wahl für kleine, unkritische Systeme, bei denen der Aufwand eines Parallel-Servers nicht lohnt — für alles Wichtige ist es der riskantere Weg.
Side-by-Side — der empfohlene Weg
Bei der Side-by-Side-Migration richtest du einen frischen Zielserver ein und ziehst die Datenbanken dorthin um, während der alte Server unberührt bestehen bleibt. Das hat drei große Vorteile: Der Rollback ist trivial — geht etwas schief, schwenkst du einfach auf den alten Server zurück, der ja noch läuft. Du bekommst die Chance auf einen sauberen Neuanfang — der neue Server wird von Beginn an richtig konfiguriert, ohne die Altlasten mitzuschleppen. Und du kannst in Ruhe testen, weil Produktion und Ziel parallel existieren. Der Preis ist der zusätzliche Server und der explizite Datenumzug — per Backup/Restore, Detach/Attach oder, für minimale Ausfallzeit, per Log Shipping oder temporärer Always-On-Konstellation, bei der nur noch im Wartungsfenster umgeschwenkt wird. Für jedes wichtige System ist Side-by-Side die richtige Wahl.
Der Rollback-Plan — vor dem Umzug, nicht danach
Die wichtigste Regel der ganzen Migration: Der Rollback-Plan wird zuerst geschrieben, nicht im Problemfall improvisiert. Er beantwortet vier Fragen konkret: Bei welchen Symptomen brechen wir ab? Wer trifft die Abbruch-Entscheidung? Wie genau kommen wir zum alten Stand zurück, und wie lange dauert das? Und wo liegt der Point of no Return — der Zeitpunkt, ab dem ein Rollback teurer wäre als das Durchziehen? Bei Side-by-Side ist der Plan angenehm einfach (zurückschwenken), bei In-Place aufwändiger (Restore aus dem Pre-Migration-Backup). Und so wie ein Backup erst durch den Restore-Test verlässlich wird, wird ein Rollback-Plan erst verlässlich, wenn der Rückweg einmal geprobt wurde. Ein nie getesteter Plan B ist nur ein gut gemeinter Wunsch.
Was du auf keinen Fall tun solltest
|
Die drei häufigsten Anfängerfehler 1. Die Migration als Datenumzug missverstehen. Die Datenbank zu bewegen ist leicht — ihr Ökosystem mitzunehmen ist die eigentliche Arbeit, an der die meisten Umzüge scheitern. |
|---|
Nach der Migration: stabilisieren und aufräumen
Der Umzug ist nicht mit dem Umschwenken beendet. Drei Schritte gehören zur Nachsorge: Erstens, die Performance beobachten — der Query Store zeigt nach der Compatibility-Level-Anhebung im Regressed-Queries-Bericht, ob Pläne gekippt sind; Ausreißer lassen sich per Plan-Forcing entschärfen, bis sie geprüft sind. Zweitens, den vollen Health Check auf dem neuen Server fahren — eine Migration ist genau der Anlass, bei dem Konfiguration und Pläne kippen, und der Selbsttest prüft, ob alles richtig steht. Drittens, den alten Server kontrolliert stilllegen — aber erst nach einer Bewährungsfrist, in der er als Rückfalloption verfügbar bleibt, und mit einem finalen Backup als Archiv. Wie der Query Store Migrationen absichert, steht im Query-Store-Beitrag; wie der Health Check aussieht, im gleichnamigen Beitrag der GRÜN-Stufe.
Vertiefung in der Buchreihe
Migration, Versions-Upgrades und Cloud-Pfade füllen in der Buchreihe „SQL Server in der Praxis“ einen eigenen Band — alle Bände in der Übersicht auf der SQL-Pillar-Seite unter /sql-server/.
|
Empfohlene Bände Band 4: Migration — das Heimatbuch dieses Beitrags: Versions-Upgrades und Plattform-Wechsel im Detail, der Database Migration Assistant, In-Place vs. Side-by-Side, Compatibility Level und Kardinalitätsschätzer, Cloud-Pfade und die vollständige Ökosystem-Checkliste. |
|---|
Verwandte Beiträge im Notarztwagen
Die Migration berührt viele Themen — diese Beiträge aus dem Cluster lohnen den Blick:
Drei Wege zur sicheren Migration
Selbst-Diagnose-Kit
Eine Migration selbst sauber vorzubereiten ist gut investierte Zeit — und genau dafür gibt es das Diagnose-Kit. Es bündelt die Skripte aus diesem Beitrag — Ökosystem-Inventar (Logins, Jobs, Linked Server), Compatibility-Level-Prüfung, verwaiste-User-Suche — plus die Vier-Phasen-Checkliste zum Ausdrucken, eine vollständige Ökosystem-Mitnahmeliste und eine Rollback-Plan-Vorlage. Damit verwandelst du den riskanten Umzug in einen abgehakten Prozess mit Plan B.
Festpreis-Analyse
Du planst eine Migration und willst sie nicht zum Glücksspiel machen — mit einer fundierten Bewertung, was bricht und wie der sichere Weg aussieht? Die Festpreis-Analyse liefert genau das: Ich führe die DMA-Bewertung durch, erstelle die vollständige Ökosystem-Inventur, empfehle Methode und Compatibility-Level-Strategie, entwerfe den Rollback-Plan und liefere einen Migrations-Fahrplan mit priorisierten Schritten und Risiken. Zum vereinbarten Festpreis, ohne Stundenzähler.
Akut-Hotline
Wenn eine Migration gerade jetzt im Wartungsfenster aus dem Ruder läuft und die Rollback-Entscheidung ansteht: anrufen. Halte den Migrations-Plan und den Stand bereit — was ist umgezogen, was noch nicht? In diesem Moment zählt jede richtige Entscheidung, und die wichtigste ist oft, rechtzeitig den geprobten Rückweg zu nehmen statt sich durchzukämpfen.
|
Ein letzter Tipp Bevor du die nächste Migration planst, stell deinem Team eine einzige Frage: „Wenn wir nach dem Umzug feststellen, dass etwas grundlegend nicht funktioniert — wie genau kommen wir zum alten Stand zurück, und wie lange dauert das?“ Wenn darauf keine klare, geprobte Antwort kommt, plant ihr gerade einen Sprung ohne Netz. Die gute Nachricht: Mit einer Side-by-Side-Migration ist das Netz fast geschenkt — der alte Server bleibt einfach stehen, und der Rückweg ist ein Umschalten. |
|---|
Häufige Fragen (FAQ)
Diese Sektion ist auf häufige Suchanfragen abgestimmt. Sie hilft dir, schnell den Punkt zu finden, der dir gerade akut weiterhilft — und sie ist gleichzeitig die Eingabe für das FAQPage-Schema auf der Seite.
Wie bereite ich eine SQL-Server-Migration vor?
In vier Phasen: bewerten, planen, testen, umziehen. In der Bewertung klärst du mit dem Database Migration Assistant, was beim Versionswechsel bricht (veraltete Features, Breaking Changes). In der Planung wählst du die Methode (In-Place oder Side-by-Side) und schreibst — noch vor allem anderen — den Rollback-Plan. Im Test machst du einen vollständigen Probelauf auf einer Kopie, prüfst Funktion und Performance. Erst dann der eigentliche Umzug im Wartungsfenster, mit Checkliste und griffbereitem Plan B. Der häufigste Fehler ist, eine Migration als reinen Datenumzug zu sehen — in Wahrheit ist das Mitnehmen des ganzen Ökosystems (Logins, Jobs, Konfiguration) die eigentliche Arbeit.
Was ist der Database Migration Assistant?
Der Database Migration Assistant (DMA) ist ein kostenloses Microsoft-Werkzeug, das eine bestehende Datenbank vor der Migration analysiert und einen Bericht über mögliche Probleme erstellt. Er findet zwei Arten von Befunden: Compatibility Issues (Dinge, die auf der Zielversion nicht mehr oder anders funktionieren — veraltete Syntax, entfernte Features) und Feature Recommendations (neue Möglichkeiten der Zielversion). Damit weißt du vor dem Umzug, was angepasst werden muss, statt es im Produktivbetrieb zu entdecken. Der DMA ist der Standard-Einstieg in jede Versions-Migration und gehört in die Bewertungsphase — er ersetzt aber nicht den echten Testlauf, sondern ergänzt ihn.
Wann ändere ich den Compatibility Level?
Bewusst getrennt vom Umzug, als eigener Schritt danach. Der Trick: Migriere zunächst und behalte den alten Compatibility Level bei — dann läuft die Datenbank auf der neuen Version, verhält sich aber wie auf der alten, weil der alte Kardinalitätsschätzer aktiv bleibt. Erst wenn der Umzug stabil ist, hebst du den Level in einem separaten, kontrollierten Schritt an. Das aktiviert den neuen Kardinalitätsschätzer, der Ausführungspläne anders berechnet und Regressionen verursachen kann. Indem du „Umzug“ und „Verhaltensänderung“ trennst, hast du im Problemfall immer nur eine Variable verändert — und der Query Store fängt etwaige Plan-Regressionen ab.
Wie führe ich einen Migrations-Test durch?
Auf einer vollständigen Kopie der Produktion, auf der Zielversion und -hardware, mit zwei Schwerpunkten: Funktion und Performance. Funktional prüfst du, ob die Anwendung läuft, ob die DMA-Befunde behoben sind und ob alle Abhängigkeiten (Jobs, Linked Server, Logins) mitgekommen sind. Für die Performance ist der Query Store das beste Werkzeug: vor der Migration eine Baseline der bewährten Pläne sammeln, nach der Migration den Regressed-Queries-Bericht prüfen. Wichtig ist eine realistische Last im Test — eine leere Datenbank verhält sich anders als eine mit Produktionsdatenmenge. Der Test ist die Phase, in der Überraschungen billig sind; im Produktivbetrieb sind sie es nicht.
Was ist ein In-Place-Upgrade?
Beim In-Place-Upgrade wird die bestehende SQL-Server-Installation direkt auf die neue Version gehoben — derselbe Server, dieselben Datenbanken, nur die Engine wird ausgetauscht. Der Vorteil: kein neuer Server nötig, kein Datenumzug. Die gewichtigen Nachteile: Es gibt keinen einfachen Rollback (ist das Upgrade einmal durch, kommt man nur über eine Wiederherstellung zurück), und alle bestehenden Altlasten und Fehlkonfigurationen ziehen unverändert mit. In-Place eignet sich deshalb für kleine, unkritische Systeme; für alles Wichtige ist die Side-by-Side-Migration auf einen frischen Server der sicherere Weg, weil der alte Server als Rückfalloption unberührt bleibt.
Welche Side-by-Side-Migration-Methoden gibt es?
Bei der Side-by-Side-Migration richtest du einen neuen Server parallel ein und ziehst die Datenbanken dorthin um — der alte bleibt als Rückfalloption bestehen. Die gängigen Methoden für den Datenumzug: Backup und Restore (der Klassiker, einfach und robust), das Loslösen und Anhängen der Datenbankdateien (Detach/Attach), oder für minimale Ausfallzeit Log Shipping bzw. eine temporäre Always-On-Konstellation, bei der die Zieldatenbank kontinuierlich synchron gehalten und im Wartungsfenster nur noch umgeschwenkt wird. Welche Methode passt, hängt von der erlaubten Ausfallzeit (RTO) ab. Der gemeinsame Vorteil aller Side-by-Side-Wege: Der Rollback ist trivial — man schwenkt einfach auf den alten Server zurück.
Wie erstelle ich einen Rollback-Plan?
Indem du ihn vor dem Umzug schreibst, nicht danach — ein Rollback-Plan, der erst im Problemfall improvisiert wird, ist keiner. Er beantwortet konkret: Bei welchen Symptomen brechen wir ab? Wer entscheidet das? Wie genau kommen wir zum alten Stand zurück, und wie lange dauert das? Bei einer Side-by-Side-Migration ist der Plan einfach (auf den alten, unberührten Server zurückschwenken), bei In-Place aufwändiger (Wiederherstellung aus dem Pre-Migration-Backup). Wichtig ist ein definierter Point of no Return — der Zeitpunkt, ab dem ein Rollback teurer wäre als das Durchziehen — und ein Test des Rollback-Wegs selbst. Ein nie geprobter Rückweg ist so verlässlich wie ein nie getestetes Backup.