Migration zu SQL Server 2025 – Risiken, Probleme, sicheres Vorgehen

Migration SQL 2016 → 2025 SQL 2019 → 2025 SQL 2022 → 2025 Breaking Changes

Migration zu SQL Server 2025 –
Risiken, Probleme und
sicheres Vorgehen

SQL Server 2025 (17.x) · Stand April 2026 · Direktupgrade ab SQL Server 2016 SP3

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.

01
Kontext

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:

SQL Server 2016

End of Support: 14. Juli 2026

Kompatibilitätslevel 130. Höchste Risikokategorie – größte Lücke zu SQL 2025. Benötigt SP3.

SQL Server 2019

Support bis Juli 2030

Kompatibilitätslevel 150. Mittlere Risikokategorie – IQP-Unterschiede, aber vertraute Sicherheitsarchitektur.

SQL Server 2022

Support bis Juli 2033

Kompatibilitätslevel 160. Geringste Risikokategorie – bekanntes IQP, Hauptrisiken bei Linked Servern und Verbindungen.

SQL Server 2025

GA: November 2025

Kompatibilitätslevel 170. Ziel der Migration. CU1 Frühjahr 2026 für Produktivumgebungen empfohlen.

SQL Server 2016 End of Support am 14. Juli 2026: Wer noch auf SQL Server 2016 betreibt, hat dringenden Handlungsbedarf. Nach dem End of Support gibt es keine Sicherheitspatches mehr – jede neu entdeckte Sicherheitslücke bleibt dauerhaft offen. Eine Migration ist keine optionale Modernisierungsmaßnahme, sondern eine Sicherheitspflicht.

Unterstützte Direktupgrade-Pfade

QuellversionDirektupgrade zu 2025MindestvoraussetzungRisikostufe
SQL Server 2016JaSP3 oder höherHoch
SQL Server 2017JaAktuelles CU empfohlenMittel
SQL Server 2019JaAktuelles CU empfohlenMittel
SQL Server 2022JaKein Mindest-CUGering
SQL Server 2014JaSP3 erforderlichSehr hoch
SQL Server 2012 und älterNeinKein direktes UpgradeSide-by-Side-Migration nötig

02
Kritische Risiken

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.

Kritisch Verbindungsverschlüsselung

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.

Kritisch Linked Server (OLE DB 19)

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.

Kritisch Replikation (Remote Distributor)

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.

Kritisch Full-Text Search (FTS)

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.

Hoch Log Shipping Monitor

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).

Hoch Erweiterte gespeicherte Prozeduren

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.

Hoch Service-Neustart während Setup

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.

Mittel Entfernte Features

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

T-SQL – Unverschlüsselte Verbindungen und Linked Server inventarisieren
-- 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;

03
Quellversionen im Vergleich

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.

Kritische 2016-spezifische Probleme: In SQL Server 2016 war es noch möglich, TEXT, NTEXT und IMAGE-Spaltentypen zu nutzen. Diese Typen sind in SQL 2025 weiterhin vorhanden, aber vollständig deprecated. Abfragen, die diese Typen verwenden, müssen auf VARCHAR(MAX), NVARCHAR(MAX) bzw. VARBINARY(MAX) migriert werden. In SQL 2016-Umgebungen finden sich auch häufig veraltete JOIN-Syntax (=*, *=), nicht-standardkonforme Aggregatfunktionen und Nutzung von Trace Flags, die in SQL 2025 ignoriert werden oder andere Bedeutung haben.
RisikopunktSQL 2016 → 2025SQL 2019 → 2025SQL 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.

2019-spezifisch: In SQL Server 2019 eingeführte Features wie Accelerated Database Recovery (ADR) und die erste IQP-Generation können in SQL 2025 anders konfiguriert sein. Wer ADR in 2019 explizit deaktiviert hatte (aus Performance-Gründen), sollte die Konfiguration nach dem Upgrade prüfen – SQL 2025 erweitert ADR auf TempDB.

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".

T-SQL – Deprecated Features vor Migration identifizieren
-- 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];

04
Migrationssicherheitsnetz

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.

Level 130
SQL Server 2016
Level 140
SQL Server 2017
Level 150
SQL Server 2019
Level 160
SQL Server 2022
Level 170
SQL Server 2025

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.

T-SQL – Kompatibilitätslevel prüfen, beibehalten und schrittweise anheben
-- 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
Wichtig: Nicht alle Verbesserungen in SQL Server 2025 sind an Kompatibilitätslevel 170 gebunden. Sicherheitsfeatures (TLS 1.3, PBKDF2), ZSTD-Backup-Kompression und die AlwaysOn-Verbesserungen wirken instanzweit – unabhängig vom Datenbankkompatibilitätslevel. Der Level steuert primär den Query-Optimizer und IQP-Verhalten.

05
Strategieauswahl

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.

AspektBeurteilung
DowntimeServiceunterbrechung während des Upgrades (typisch 15–60 Min.)
RollbackNur durch Restore eines Backups möglich – kein automatischer Rückweg
AufwandGering – ein Schritt
RisikoMittel – Breaking Changes müssen vorher adressiert sein
Geeignet fürEinfache Umgebungen ohne Linked Server, Replikation oder komplexe AG-Topologien
Service-Neustart während des Setups: SQL Server 2025 startet den SQL-Dienst bereits während der Health-Check-Phase des Setup-Wizards neu – bevor das eigentliche Upgrade beginnt. Das ist ein bekanntes Problem aus der Praxis (berichtet nach realen Upgrades von 2022). Wer das Setup bis kurz vor den letzten Schritt vorbereitet und wartet, wird von diesem Neustart überrascht. Das Upgrade-Fenster muss diesen Zeitpunkt berücksichtigen.

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.

AspektBeurteilung
DowntimeNur Cutover-Downtime (wenige Minuten bis Stunden je nach DB-Größe und Methode)
RollbackEinfach – alter Server bleibt bis zur finalen Abschaltung aktiv
AufwandHöher – zweiter Server, Login-Migration, Job-Migration
RisikoGering – vollständige Testmöglichkeit vor Cutover
Geeignet fürProduktivumgebungen mit hohen Verfügbarkeitsanforderungen, AS 2016-Migrationen
T-SQL – Logins und Jobs für Side-by-Side Migration skripten
-- 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.


06
Migrationsprozess

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.

1

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.

2

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.

3

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.

4

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.

5

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

T-SQL – Plan-Regressionen nach Kompatibilitätslevel-Anhebung erkennen
-- 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;

07
Werkzeuge

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.

ToolFunktionEmpfehlung
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 – Assessment starten (Schritt-für-Schritt)
-- 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];

08
Hochverfügbarkeit

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.

1

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.

2

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.

3

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.

4

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.

T-SQL – Rolling Upgrade: Status überwachen und Failover 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);
Kompatibilitätslevel in AG-Umgebungen: Nach dem Rolling Upgrade bleibt der Kompatibilitätslevel aller Datenbanken auf dem Quell-Level. Die Level-Anhebung auf 170 kann und sollte nach dem Upgrade, nach einer Stabilisierungsphase und nach ausreichend Query-Store-Baseline erfolgen – unabhängig vom AG-Upgrade selbst.

09
Notfallplanung

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-SzenarioMachbarkeitDatenstandVoraussetzung
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
Der kritischste Punkt: Ein vollständiges, verifiziertes Backup unmittelbar vor dem Upgrade ist keine Empfehlung, sondern eine Pflichtvoraussetzung. Ein Backup aus der letzten Nacht reicht nicht – alle Transaktionen zwischen dem Nacht-Backup und dem Upgrade-Beginn wären bei einem Rollback verloren. Der Restore-Test des Pre-Upgrade-Backups muss vor dem Upgrade-Tag stattfinden.
T-SQL – Pre-Upgrade-Backup und Verify
-- 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;

Zusammenfassung

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=False und 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=True umgestellt
  • 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)
Fazit: Eine Migration zu SQL Server 2025 ist kein Hexenwerk – aber sie ist mehr als ein routinemäßiges Patching. Die fünf Breaking-Change-Bereiche (Verschlüsselung, Linked Server, Replikation, Full-Text Search, entfernte Features) sind gut dokumentiert und vollständig adressierbar. Wer diese sorgfältig vor dem Upgrade behebt und das Kompatibilitätslevel als Sicherheitsnetz nutzt, hat eine hohe Wahrscheinlichkeit auf eine reibungslose Migration. Die Belohnung: bessere Sicherheit, stabilere Performance durch OPPO, und AlwaysOn-Features, auf die DBAs lange gewartet haben.
MS SQL Server 2025 (17.x) · Migration von 2016 / 2019 / 2022 · Stand: April 2026