Migration zu SQL Server 2025 –
Risiken, Probleme und
sicheres Vorgehen
Ein Direktupgrade ist möglich – aber SQL Server 2025 bringt mehr Breaking Changes als jedes vorherige Release. Dieser Artikel beschreibt versionsspezifische Risiken, die häufigsten Fallstricke aus der Praxis und einen sicheren, stufenweisen Migrationsplan.
SQL Server 2025 ist ein direktes In-Place-Upgrade von SQL Server 2016 SP3 und neuer – Microsoft hat diesen Migrationspfad explizit unterstützt. Trotzdem ist es kein routinemäßiges Maintenance-Upgrade. Die Sicherheitsänderungen rund um TLS 1.3, Verschlüsselung und Verbindungsstandards sind so tiefgreifend, dass Verbindungen, Linked Server und Replikation ohne Vorbereitung nach dem Upgrade schlicht nicht mehr funktionieren.
Dazu kommen für SQL Server 2016-Umgebungen bis zu neun übersprungene Kompatibilitätslevel und hunderte veränderte Optimizer-Verhaltensweisen. Dieser Artikel behandelt alle drei Ausgangspunkte getrennt – denn die Risiken und der Aufwand unterscheiden sich erheblich je nachdem, ob man von 2016, 2019 oder 2022 startet.
Ausgangslage und Migrationspfade
Microsoft unterstützt einen Direktupgrade von SQL Server 2016 SP3 (und neuer) zu SQL Server 2025. Ältere Versionen als 2016 SP3 erfordern einen Zwischenschritt. Die Ausgangssituation der drei häufigsten Quellversionen unterscheidet sich erheblich:
End of Support: 14. Juli 2026
Kompatibilitätslevel 130. Höchste Risikokategorie – größte Lücke zu SQL 2025. Benötigt SP3.
Support bis Juli 2030
Kompatibilitätslevel 150. Mittlere Risikokategorie – IQP-Unterschiede, aber vertraute Sicherheitsarchitektur.
Support bis Juli 2033
Kompatibilitätslevel 160. Geringste Risikokategorie – bekanntes IQP, Hauptrisiken bei Linked Servern und Verbindungen.
GA: November 2025
Kompatibilitätslevel 170. Ziel der Migration. CU1 Frühjahr 2026 für Produktivumgebungen empfohlen.
Unterstützte Direktupgrade-Pfade
| Quellversion | Direktupgrade zu 2025 | Mindestvoraussetzung | Risikostufe |
|---|---|---|---|
| SQL Server 2016 | Ja | SP3 oder höher | Hoch |
| SQL Server 2017 | Ja | Aktuelles CU empfohlen | Mittel |
| SQL Server 2019 | Ja | Aktuelles CU empfohlen | Mittel |
| SQL Server 2022 | Ja | Kein Mindest-CU | Gering |
| SQL Server 2014 | Ja | SP3 erforderlich | Sehr hoch |
| SQL Server 2012 und älter | Nein | Kein direktes Upgrade | Side-by-Side-Migration nötig |
Breaking Changes – was sofort nach dem Upgrade brechen kann
Die folgenden Breaking Changes treffen alle Quellversionen – unabhängig davon, ob die Migration von 2016, 2019 oder 2022 kommt. Sie müssen vor dem Upgrade adressiert sein, nicht danach.
SQL Server 2025 erfordert standardmäßig Encrypt=True. Verbindungen ohne explizite Verschlüsselung werden abgelehnt. Betrifft alle Anwendungen, ODBC-Verbindungen, SSMS-Verbindungen ohne Encrypt-Flag und Linked Server.
Linked Server mit OLE DB Driver < 19 können nach dem Upgrade fehlschlagen. Der neue Driver setzt TrustServerCertificate=False als Default – auf Zielen ohne vertrauenswürdiges Zertifikat schlagen Verbindungen sofort fehl.
Transaktionale, Snapshot- und Merge-Replikation mit Remote-Distributor schlägt fehl, wenn kein vertrauenswürdiges Zertifikat konfiguriert ist. sp_adddistributor schlägt mit SSL-Fehler fehl.
Alle Word-Breaker-Binaries wurden ersetzt. Bestehende FTS-Indizes werden als Version 1 markiert und erzeugen sofort nach dem Upgrade Fehler (Msg 30010). Ein vollständiger Rebuild aller FTS-Kataloge ist zwingend erforderlich.
Wenn der Monitor-Server ein SQL Server 2025-Instanz ist und andere Instanzen in der Topologie ältere Versionen haben, kann der Log Shipping Monitor die Verbindung verweigern (Verschlüsselungskonflikte).
Custom DLL-Aufrufe via Extended Stored Procedures sind vollständig blockiert. Migration auf CLR oder externe Services erforderlich. Betrifft Legacy-Systeme, die direkt Windows-DLLs aufrufen.
SQL Server 2025 Setup startet den Dienst während der Health-Check-Phase neu – noch bevor das eigentliche Upgrade beginnt. Das ist neu und überrascht DBAs, die das Setup bis kurz vor dem letzten Schritt vorbereiten.
DQS, MDS, SSRS (kein neues Release), SQL Mail (sp_makewebtask), Web Edition, Lightweight Pooling (deprecated), Oracle Connector für SSIS, PolyBase-Änderungen. Installationen dieser Komponenten schlagen fehl oder sind nicht mehr vorhanden.
Verbindungs-Diagnose vor dem Upgrade
-- 1. Alle unverschlüsselten aktiven Verbindungen anzeigen SELECT s.session_id, s.login_name, s.program_name, s.host_name, c.encrypt_option AS Verschlüsselung, c.auth_scheme, c.protocol_version FROM sys.dm_exec_sessions s INNER JOIN sys.dm_exec_connections c ON s.session_id = c.session_id WHERE s.is_user_process = 1 AND c.encrypt_option = 'FALSE' ORDER BY s.program_name, s.login_name; -- 2. Alle Linked Server und deren Provider anzeigen SELECT ls.[name] AS LinkedServer, ls.product AS Produkt, ls.provider AS Provider, ls.data_source AS Datenquelle, lso.is_rpc_out_enabled, lso.is_data_access_enabled FROM sys.servers ls INNER JOIN sys.linked_logins ll ON ls.server_id = ll.server_id LEFT JOIN sys.linked_logins lso ON ls.server_id = lso.server_id WHERE ls.is_linked = 1 ORDER BY ls.[name]; -- 3. Replikations-Publisher und Remote-Distributor-Status SELECT srv.[name] AS Publisher, dist.distribution_db AS DistributionDB, dist.working_directory FROM distribution.dbo.MSdistributiondbs dist CROSS JOIN sys.servers srv WHERE srv.is_distributor = 1;
Versionsspezifische Risiken
Über die allgemeinen Breaking Changes hinaus hat jede Quellversion ihre eigenen spezifischen Probleme – bedingt durch die Versionslücke, veraltete Funktionen und unterschiedliche IQP-Reifestadien.
Migration von SQL Server 2016 → 2025
Das ist die risikoreichste Migration. SQL Server 2016 wurde zu einer Zeit entwickelt, als viele der heutigen Sicherheitsstandards noch nicht existierten. Die Lücke umfasst neun Kompatibilitätslevel (130 → 170) und drei große Optimizer-Generationen.
=*, *=), nicht-standardkonforme Aggregatfunktionen und Nutzung von Trace Flags, die in SQL 2025 ignoriert werden oder andere Bedeutung haben.
| Risikopunkt | SQL 2016 → 2025 | SQL 2019 → 2025 | SQL 2022 → 2025 |
|---|---|---|---|
| Optimizer-Verhaltensänderungen | Sehr hoch | Mittel | Gering |
| Deprecated Features (TEXT/IMAGE etc.) | Hoch | Mittel | Gering |
| Verbindungsverschlüsselung | Kritisch | Kritisch | Kritisch |
| Linked Server | Hoch | Hoch | Mittel |
| Full-Text Search Rebuild | Kritisch | Kritisch | Kritisch |
| IQP / OPPO-Anpassung | Hoch | Mittel | Gering |
| Replikation mit Remote-Distributor | Hoch | Hoch | Hoch |
| SSRS → PBRS Migration | Mittel | Mittel | Gering |
| OS-Kompatibilität (Win Server 2019+) | Hoch | Mittel | Gering |
Migration von SQL Server 2019 → 2025
SQL Server 2019 führte Intelligent Query Processing (IQP) ein. Die IQP-Erweiterungen in SQL 2025 können für Abfragen, die bisher von einem spezifischen Plan profitiert haben, unerwartete Plan-Änderungen auslösen. Das Risiko ist deutlich geringer als von 2016, aber nicht null.
Migration von SQL Server 2022 → 2025
Das ist die „einfachste" Migration – die Optimizer-Verhalten sind weitgehend vertraut, viele IQP-Features aus 2025 haben ihre Wurzeln in 2022. Die Hauptrisiken bleiben aber: Verbindungsverschlüsselung, Linked Server und Full-Text Search. „Einfachste" bedeutet nicht „trivial".
-- Verwendung deprecated Features im SQL Server Error Log / Trace SELECT instance_name AS Feature, cntr_value AS NutzungsZaehler FROM sys.dm_os_performance_counters WHERE object_name LIKE '%Deprecated%' AND cntr_value > 0 ORDER BY cntr_value DESC; -- TEXT/NTEXT/IMAGE Spalten in allen Tabellen finden SELECT SCHEMA_NAME(t.schema_id) + '.' + t.[name] AS Tabelle, c.[name] AS Spalte, tp.[name] AS Datentyp FROM sys.columns c INNER JOIN sys.tables t ON c.object_id = t.object_id INNER JOIN sys.types tp ON c.user_type_id = tp.user_type_id WHERE tp.[name] IN ('text', 'ntext', 'image') ORDER BY Tabelle, Spalte; -- Extended Stored Procedures identifizieren (in SQL 2025 geblockt) SELECT [name] AS XP_Name, dll_name AS DLL, type_desc FROM sys.extended_procedures ORDER BY [name];
Der Kompatibilitätslevel als zentrales Sicherheitsnetz
Der Datenbankkompatibilitätslevel ist das wichtigste Werkzeug für eine risikoarme Migration. Nach einem Upgrade bleibt der Kompatibilitätslevel einer bestehenden Datenbank unverändert – erst wenn er explizit auf 170 (SQL Server 2025) angehoben wird, aktivieren sich neue Optimizer-Verhaltensweisen und IQP-Features.
Die empfohlene Strategie: Instanz upgraden, Kompatibilitätslevel beibehalten, stabilisieren, dann schrittweise anheben. Das schützt vor Optimizer-Regressionen, die durch neue IQP-Features entstehen könnten.
-- Nach dem Upgrade: aktuellen Level aller Datenbanken prüfen SELECT name, compatibility_level, CASE compatibility_level WHEN 170 THEN 'SQL Server 2025' WHEN 160 THEN 'SQL Server 2022' WHEN 150 THEN 'SQL Server 2019' WHEN 140 THEN 'SQL Server 2017' WHEN 130 THEN 'SQL Server 2016 (Kompatibilitätsmodus)' ELSE 'Älter / Unbekannt' END AS EffektivVersion FROM sys.databases WHERE database_id > 4 ORDER BY name; -- Query Store aktivieren BEVOR der Level angehoben wird (Baseline erfassen) ALTER DATABASE [MeineDatenbank] SET QUERY_STORE = ON ( OPERATION_MODE = READ_WRITE, CLEANUP_POLICY = (STALE_QUERY_THRESHOLD_DAYS = 30), MAX_STORAGE_SIZE_MB = 1024, QUERY_CAPTURE_MODE = ALL -- Alles erfassen für Baseline ); -- Level anheben – nach ausreichend Testzeit mit dem alten Level ALTER DATABASE [MeineDatenbank] SET COMPATIBILITY_LEVEL = 170; -- Bei Plan-Regression: Level zurücksetzen (von 2016 kommend: auf 130) ALTER DATABASE [MeineDatenbank] SET COMPATIBILITY_LEVEL = 130; -- Rollback-Option
Migrationsmethoden – In-Place vs. Side-by-Side
Es gibt drei grundlegende Methoden für die Migration. Die Wahl hängt von Verfügbarkeitsanforderungen, vorhandener Infrastruktur und der Risikobereitschaft ab.
Methode 1: In-Place Upgrade
Der Setup-Assistent von SQL Server 2025 upgraded die bestehende Instanz direkt auf dem vorhandenen Server. Einfachste Methode, aber kein einfacher Rollback möglich.
| Aspekt | Beurteilung |
|---|---|
| Downtime | Serviceunterbrechung während des Upgrades (typisch 15–60 Min.) |
| Rollback | Nur durch Restore eines Backups möglich – kein automatischer Rückweg |
| Aufwand | Gering – ein Schritt |
| Risiko | Mittel – Breaking Changes müssen vorher adressiert sein |
| Geeignet für | Einfache Umgebungen ohne Linked Server, Replikation oder komplexe AG-Topologien |
Methode 2: Side-by-Side Migration (Backup/Restore)
Neuer SQL Server 2025-Server wird aufgesetzt, Datenbanken werden per Backup/Restore migriert. Maximale Kontrolle, einfacher Rollback – aber mehr Infrastrukturaufwand und längere Cutover-Phase.
| Aspekt | Beurteilung |
|---|---|
| Downtime | Nur Cutover-Downtime (wenige Minuten bis Stunden je nach DB-Größe und Methode) |
| Rollback | Einfach – alter Server bleibt bis zur finalen Abschaltung aktiv |
| Aufwand | Höher – zweiter Server, Login-Migration, Job-Migration |
| Risiko | Gering – vollständige Testmöglichkeit vor Cutover |
| Geeignet für | Produktivumgebungen mit hohen Verfügbarkeitsanforderungen, AS 2016-Migrationen |
-- Logins auf Quellserver skripten (sp_help_revlogin oder DMA) USE master; GO -- Alle SQL Logins mit Hashes exportieren (für Passwort-Migration) SELECT 'IF NOT EXISTS (SELECT * FROM sys.server_principals WHERE name = ''' + [name] + ''') CREATE LOGIN [' + [name] + '] WITH PASSWORD = ' + CONVERT(VARCHAR(512), [password_hash], 1) + ' HASHED, SID = ' + CONVERT(VARCHAR(512), [sid], 1) + ', CHECK_EXPIRATION = OFF, CHECK_POLICY = OFF;' AS CreateScript FROM sys.sql_logins WHERE [name] NOT LIKE '##%' AND [name] != 'SA' ORDER BY [name]; -- SQL Agent Jobs exportieren (für Import auf Zielserver) SELECT OBJECT_DEFINITION(OBJECT_ID('msdb.dbo.sp_get_composite_job_info')); -- Alternativ: SSMS → SQL Agent → Alle Jobs skripten
Methode 3: Rolling Upgrade via AlwaysOn (empfohlen für AG-Umgebungen)
Für Umgebungen mit Availability Groups ist das Rolling Upgrade der beste Ansatz: minimale Downtime (nur eine Failover-Dauer), vollständige Kontrolle, Rollback durch erneuten Failover auf den alten Primary möglich.
Diese Methode wird in Abschnitt 08 detailliert beschrieben.
Sicheres Vorgehen – der stufenweise Migrationsplan
Eine sichere Migration zu SQL Server 2025 erfolgt in fünf Phasen. Jede Phase hat ein definiertes Go/No-Go-Kriterium, bevor die nächste beginnt.
Phase 1: Assessment und Inventur (2–4 Wochen)
SSMS 22 Migration Component Assessment auf Quellinstanz ausführen. Alle Breaking Changes identifizieren und dokumentieren. Verbindungsstrings inventarisieren, Linked Server auflisten, Replikations-Topologie dokumentieren, FTS-Nutzung prüfen. Go/No-Go: Alle Breaking Changes bekannt und Behebungsplan erstellt.
Phase 2: Staging-Umgebung aufbauen und testen (4–8 Wochen)
SQL Server 2025 auf einem isolierten Staging-Server installieren. Produktionsdatenbanken (anonymisiert oder vollständig) per Backup/Restore einspielen. Kompatibilitätslevel beibehalten. Alle Breaking Changes in der Staging-Umgebung beheben. Anwendungstests gegen Staging durchführen. Query Store aktivieren und Baseline erfassen. Go/No-Go: Alle Tests erfolgreich, keine ungelösten Breaking Changes.
Phase 3: Breaking Changes in Produktion vorbereiten (1–2 Wochen vor Upgrade)
Verbindungsstrings aller Anwendungen auf Encrypt=True umstellen. OLE DB Driver auf Applikationsservern aktualisieren. Zertifikate für Linked Server und Replikation konfigurieren. FTS-Rebuild-Skripte vorbereiten. SQL Server Agent-Jobs und Wartungspläne exportieren. Vollständiges Backup aller Datenbanken erstellen und Restore testen. Go/No-Go: Backup verifiziert, alle Vorab-Maßnahmen abgeschlossen.
Phase 4: Upgrade durchführen (Wartungsfenster)
Dienste stoppen, abschließendes Backup erstellen. SQL Server 2025 Setup ausführen (In-Place oder Side-by-Side). Post-Upgrade: FTS-Kataloge neu aufbauen, Verbindungen testen, SQL Agent starten, Error Log prüfen. Kompatibilitätslevel bleibt auf Quellversion. Anwendungs-Smoketests ausführen. Go/No-Go: Alle Anwendungen funktionieren, Error Log sauber.
Phase 5: Kompatibilitätslevel schrittweise anheben (4–8 Wochen nach Upgrade)
Datenbankweise auf Level 170 umstellen. Nach jeder Umstellung: 1–2 Wochen Query Store-Monitoring auf Plan-Regressionen. Bei Regression: Level zurücksetzen, problematische Abfragen identifizieren, mit Query Store Hints oder Query Plan Forcing stabilisieren. Go/No-Go: Keine Performance-Regressionen über 48 Stunden nach Level-Anhebung.
Post-Upgrade Monitoring-Abfragen
-- Plan-Regressionen im Query Store identifizieren -- Abfragen deren Laufzeit nach dem Level-Wechsel gestiegen ist WITH Baseline AS ( SELECT q.query_id, AVG(rs.avg_duration) AS avg_dur_baseline FROM sys.query_store_query q INNER JOIN sys.query_store_plan p ON q.query_id = p.query_id INNER JOIN sys.query_store_runtime_stats rs ON p.plan_id = rs.plan_id WHERE rs.last_execution_time BETWEEN DATEADD(DAY, -14, GETUTCDATE()) AND DATEADD(DAY, -1, GETUTCDATE()) -- Vor Level-Wechsel GROUP BY q.query_id ), Aktuell AS ( SELECT q.query_id, AVG(rs.avg_duration) AS avg_dur_aktuell FROM sys.query_store_query q INNER JOIN sys.query_store_plan p ON q.query_id = p.query_id INNER JOIN sys.query_store_runtime_stats rs ON p.plan_id = rs.plan_id WHERE rs.last_execution_time > DATEADD(DAY, -1, GETUTCDATE()) -- Nach Level-Wechsel GROUP BY q.query_id ) SELECT TOP 20 qt.query_sql_text, b.avg_dur_baseline / 1000.0 AS baseline_ms, a.avg_dur_aktuell / 1000.0 AS aktuell_ms, (a.avg_dur_aktuell - b.avg_dur_baseline) / b.avg_dur_baseline * 100 AS Verschlechterung_Pct FROM Baseline b INNER JOIN Aktuell a ON b.query_id = a.query_id INNER JOIN sys.query_store_query q ON b.query_id = q.query_id INNER JOIN sys.query_store_query_text qt ON q.query_text_id = qt.query_text_id WHERE a.avg_dur_aktuell > b.avg_dur_baseline * 1.25 -- > 25% langsamer ORDER BY Verschlechterung_Pct DESC;
Assessment-Tools und Hilfsmittel
Microsoft hat mit SQL Server 2025 den früheren Data Migration Assistant (DMA) in das SSMS 22 Migration Component integriert. Das ist jetzt das primäre Assessment-Tool.
| Tool | Funktion | Empfehlung |
|---|---|---|
| SSMS 22 Migration Component | Assessment + Migration in einem. Erkennt Breaking Changes für SQL 2025 spezifisch. Empfiehlt Gegenmaßnahmen. Ersetzt DMA. | Primäres Tool |
| Database Experimentation Assistant (DEA) | Replay der Produktions-Workload auf SQL 2025. Vergleicht Query-Performance vor/nach. Findet Plan-Regressionen | Für Performance-Validierung |
| Query Store Reports (SSMS 22) | Plan-Regressions-Report, Top Resource Consumers, Plan-Vergleich vor/nach Level-Anhebung | Für Post-Migration-Monitoring |
| sys.dm_db_missing_index_details | Fehlende Indizes, die durch neue Optimizer-Entscheidungen entstehen könnten | Post-Migration Monitoring |
| sp_BlitzCache / sp_BlitzIndex (Ola Hallengren Tools) | Community-Tools für schnelles Query-Tuning und Index-Analyse. Funktionieren auf SQL 2025. | Bewährt in der Praxis |
| Alter Data Migration Assistant (DMA) – alt | Vorgänger von SSMS Migration Component. Noch nutzbar, aber nicht mehr primär empfohlen für SQL 2025. | Nur als Ergänzung |
-- SSMS 22 Migration Component Assessment (GUI-Schritte): -- 1. Quellinstanz verbinden -- 2. Im Objekt-Explorer: Rechtsklick auf Instanz → Migrate SQL Server -- 3. "New Assessment" wählen -- 4. Zielversion: SQL Server 2025 auswählen -- 5. Assessment ausführen → Report enthält: -- - Breaking Changes (mit Priorität) -- - Deprecated Features -- - Linked Server-Warnungen (OLE DB 19) -- - Empfohlene Maßnahmen mit T-SQL-Snippets -- Alternativ: Verbindungsstring-Scan mit PowerShell (Schnellcheck) -- PowerShell: Alle Verbindungsstrings in .config-Dateien suchen -- Get-ChildItem -Path "C:\Apps" -Recurse -Filter "*.config" | -- Select-String -Pattern "Encrypt=False|Trusted_Connection" | -- Select-Object Path, LineNumber, Line -- Full-Text Indizes vorbereiten: Rebuild-Skript generieren SELECT 'ALTER FULLTEXT CATALOG [' + fc.[name] + '] REBUILD;' AS RebuildScript, fc.[name] AS KatalogName, fi.change_tracking_state_desc FROM sys.fulltext_catalogs fc INNER JOIN sys.fulltext_indexes fi ON fc.fulltext_catalog_id = fi.fulltext_catalog_id ORDER BY fc.[name];
Migration von AlwaysOn Availability Groups
Das Rolling Upgrade ist die empfohlene Methode für Availability Groups. Die Downtime beschränkt sich auf die Dauer eines einzigen geplanten Failovers. Der alte Primary bleibt bis zum Ende aktiv und dient als Rollback-Option.
Sekundärrepliken upgraden (keine Downtime)
SQL Server 2025 auf allen Sekundärrepliken installieren, beginnend mit der niedrigst priorisierten Replika. Nach jedem Upgrade: Synchronisierungsstatus prüfen, Fehlerlog kontrollieren. Gemischte AG-Versionen (2022 + 2025) sind temporär unterstützt.
Geplanter Failover auf SQL 2025-Sekundäre (Downtime = Failover-Dauer)
Wenn alle Sekundärrepliken auf 2025 sind, geplanten manuellen Failover auf eine 2025-Sekundäre durchführen. Ab diesem Zeitpunkt ist SQL Server 2025 der Primary. Anwendungstests sofort nach dem Failover ausführen.
Alten Primary upgraden
Den ehemaligen Primary (jetzt Sekundäre auf alter Version) auf SQL Server 2025 upgraden. Danach wieder in die AG aufnehmen und synchronisieren lassen.
Zertifikate für TLS 1.3 konfigurieren (optional, aber empfohlen)
Wenn die AG-interne Kommunikation auf TLS 1.3 / Encrypt=Strict umgestellt werden soll: Zertifikate auf allen Repliken installieren, AG-Eigenschaft anpassen, Failover zur Aktivierung durchführen.
-- AG-Zustand und Versionsmix während Rolling Upgrade prüfen SELECT ag.[name] AS AG_Name, ar.replica_server_name AS Replika, ars.role_desc AS Rolle, ars.synchronization_health_desc AS SyncHealth, SERVERPROPERTY('ProductVersion') AS InstanzVersion, ars.connected_state_desc AS Verbindung FROM sys.availability_groups ag JOIN sys.availability_replicas ar ON ag.group_id = ar.group_id JOIN sys.dm_hadr_availability_replica_states ars ON ar.replica_id = ars.replica_id ORDER BY ag.[name], ars.role_desc; -- Geplanten manuellen Failover auf SQL 2025-Sekundäre ausführen -- Auf der Ziel-Sekundäre ausführen (nicht auf dem Primary): ALTER AVAILABILITY GROUP [AG_Produktion] FAILOVER; -- Nach Failover: Automatischen Failover-Modus wieder aktivieren ALTER AVAILABILITY GROUP [AG_Produktion] MODIFY REPLICA ON N'SQL2025-PRIMARY' WITH (FAILOVER_MODE = AUTOMATIC);
Rollback – was geht, was nicht geht
Ein Downgrade von SQL Server 2025 auf eine ältere Version ist nicht möglich. SQL Server kennt kein Deinstallieren einer Version mit automatischer Wiederherstellung des Vorgängers. Der einzige Weg zurück ist über Backups.
Rollback-Optionen und ihre Grenzen
| Rollback-Szenario | Machbarkeit | Datenstand | Voraussetzung |
|---|---|---|---|
| Kompatibilitätslevel zurücksetzen | Jederzeit | Keine Auswirkung auf Daten | Kein Backup nötig |
| Instanz-Rollback via Backup/Restore | Möglich | Datenverlust seit Backup | Vollständiges Pre-Upgrade-Backup + alter Server/OS |
| Side-by-Side: alter Server reaktivieren | Möglich | Datenverlust seit Cutover | Alter Server wurde noch nicht abgebaut |
| AG Rolling: Failover auf alten Primary | Möglich (temporär) | Kein Datenverlust | Alter Primary noch nicht upgraded |
| In-Place Downgrade | Nicht möglich | — | Nicht unterstützt von Microsoft |
-- Vollbackup aller Datenbanken unmittelbar vor dem Upgrade DECLARE @BackupPath NVARCHAR(260) = N'\\backup\PreUpgrade_20260419\'; SELECT 'BACKUP DATABASE [' + name + '] TO DISK = ''' + @BackupPath + name + '_PreUpgrade_20260419.bak'' WITH COMPRESSION, CHECKSUM, STATS = 5;' FROM sys.databases WHERE database_id > 4 -- Benutzerdatenbanken AND state_desc = 'ONLINE'; -- Nach dem Backup: Restore-Fähigkeit prüfen (ohne tatsächlichen Restore) RESTORE VERIFYONLY FROM DISK = N'\\backup\PreUpgrade_20260419\MeineDatenbank_PreUpgrade_20260419.bak' WITH CHECKSUM; -- msdb (Jobs, Maintenance Plans) und master (Logins, Linked Server) sichern BACKUP DATABASE msdb TO DISK = N'\\backup\PreUpgrade_20260419\msdb_PreUpgrade.bak' WITH CHECKSUM; BACKUP DATABASE master TO DISK = N'\\backup\PreUpgrade_20260419\master_PreUpgrade.bak' WITH CHECKSUM;
Migrations-Checkliste
Die folgende Checkliste fasst die wichtigsten Maßnahmen in der empfohlenen Reihenfolge zusammen.
Phase 1: Assessment
- SSMS 22 Migration Component Assessment auf Quellinstanz ausgeführt, Ergebnisse dokumentiert
- Verbindungsstrings aller Anwendungen auf
Encrypt=Falseund fehlendes Encrypt-Flag geprüft - Linked Server inventarisiert: Provider-Version, Zertifikatstatus, Zielsystem-Version
- Replikations-Topologie dokumentiert: Alle Publisher, Subscriber, Distributor mit Remote-Distributor-Status
- Full-Text Search: Alle Kataloge und Indizes identifiziert, Rebuild-Aufwand abgeschätzt
- Deprecated Features: TEXT/NTEXT/IMAGE-Spalten, Extended Stored Procedures, alte JOIN-Syntax
- Entfernte Komponenten: DQS, MDS, SSRS, SQL Mail in Umgebung aktiv? Migrationsplan vorhanden?
- OS-Version: Windows Server 2019 oder neuer auf Zielserver sichergestellt
Phase 2: Staging
- SQL Server 2025 (mindestens CU1) auf isoliertem Staging-Server installiert
- Produktionsdaten (anonymisiert) nach Staging migriert und Kompatibilitätslevel beibehalten
- Alle Breaking Changes in Staging behoben und erneut getestet
- Anwendungstests gegen Staging-Umgebung erfolgreich abgeschlossen
- Query Store aktiviert und Baseline-Daten erfasst
- FTS-Rebuild in Staging durchgeführt und Funktionalität verifiziert
Phase 3: Vorbereitung Produktion
- Verbindungsstrings aller Produktionsanwendungen auf
Encrypt=Trueumgestellt - OLE DB Driver 19+ auf allen Applikationsservern und Datenbankservern installiert
- Zertifikate für Linked Server und Replikation mit Remote-Distributor konfiguriert und getestet
- Log Shipping-Topologie auf Verschlüsselungskompatibilität geprüft
- SQL Agent Jobs und Wartungspläne exportiert und gesichert
- Pre-Upgrade-Backup aller Datenbanken (inkl. master, msdb) erstellt und Restore verifiziert
Phase 4: Upgrade (Wartungsfenster)
- Alle Dienste gestoppt, abschließendes Transaktionslog-Backup erstellt
- SQL Server 2025 Setup ausgeführt, alle Schritt-Ergebnisse als "Success" verifiziert
- Error Log unmittelbar nach Upgrade auf kritische Fehler geprüft
- FTS-Kataloge sofort nach Upgrade neu aufgebaut (
ALTER FULLTEXT CATALOG ... REBUILD) - Verbindungstest aller Anwendungen durchgeführt
- SQL Agent gestartet und alle Jobs auf Status "Enabled" geprüft
- Anwendungs-Smoketests erfolgreich durchgeführt
- Kompatibilitätslevel auf Quell-Level belassen
Phase 5: Stabilisierung und Level-Anhebung
- Query Store auf Produktionsinstanz aktiviert, Baseline-Erfassung gestartet
- Monitoring für mindestens 1–2 Wochen auf Quell-Kompatibilitätslevel
- Kompatibilitätslevel 170 datenbankweise angehoben, nach jeder Anhebung 48h Monitoring
- Plan-Regressionen mit Query Store Forcing oder Hints stabilisiert
- SSMS 22 auf allen DBA-Workstations installiert
- Backup-Strategie aktualisiert (ZSTD-Kompression aktiviert, Backup-Ziel-Kompatibilität geprüft)