SQL Server Upgrade: So gelingt der sichere Versionswechsel

Kurz gesagt: Ein SQL Server Upgrade bringt Ihr Datenbanksystem auf eine neuere Version, für die Microsoft noch Sicherheitsupdates veröffentlicht. Für KMU heißt der sichere Weg: zuerst Inventar und Anwendungskompatibilität prüfen, nach Möglichkeit auf eine Neuinstallation statt auf ein In-Place-Upgrade setzen, die Wiederherstellung in einer Testumgebung proben und den Rollback-Plan schreiben, bevor sich etwas ändert.

In vielen Unternehmen laufen ERP, Buchhaltung, Lager und Reporting auf einem einzigen SQL Server, der vor Jahren installiert wurde. Weil er zuverlässig läuft, wird das Versionsthema vertagt, bis ein Software-Update eine neuere Version verlangt, ein Audit „nicht mehr unterstützte Software“ feststellt oder die Hardware ersetzt werden muss. Unter Zeitdruck wird aus dem Upgrade am Wochenende dann schnell ein ERP, das am Montagmorgen nicht startet.

Dieser Leitfaden behandelt den Supportzeitplan, die Wahl der Upgrade-Methode, einen Schritt-für-Schritt-Plan und die Prüfungen nach dem Upgrade.

Warum ist ein SQL Server ohne Support ein Risiko?

Endet der erweiterte Support einer SQL-Server-Version, veröffentlicht Microsoft dafür keine regulären Sicherheitsupdates mehr; Patches gibt es dann nur noch über das kostenpflichtige Programm Extended Security Updates (ESU). Die Datenbank läuft weiter, doch neu entdeckte Schwachstellen bleiben offen, Softwarehersteller können die alte Version in neuen Releases nicht mehr unterstützen, und bei einer Störung fehlt der offizielle Support. Für Unternehmen, die personenbezogene Daten nach DSGVO verarbeiten, ist ein ungepatchter Datenbankserver außerdem eine Schwachstelle bei den technischen Schutzmaßnahmen.

Laut den Lebenszyklus-Seiten von Microsoft endet der erweiterte Support zu diesen Terminen:

Version	Ende des erweiterten Supports	Status (Oktober 2026)
SQL Server 2014	9. Juli 2024	Beendet
SQL Server 2016	14. Juli 2026	Beendet
SQL Server 2017	12. Oktober 2027	Weniger als ein Jahr
SQL Server 2019	8. Januar 2030	Unterstützt (Mainstream-Support endete am 28. Februar 2025)
SQL Server 2022	11. Januar 2033	Unterstützt
SQL Server 2025	6. Januar 2036	Neueste Version

Welche Version Sie einsetzen, zeigt die Abfrage SELECT @@VERSION; im SQL Server Management Studio (SSMS).

In-Place-Upgrade oder Neuinstallation?

Microsoft beschreibt drei Ansätze: das In-Place-Upgrade, die Migration auf eine Neuinstallation und das parallele Upgrade (Rolling Upgrade) für Hochverfügbarkeitsumgebungen mit mehreren Servern. In den meisten KMU mit einem einzigen Server fällt die Wahl zwischen den ersten beiden:

• In-Place-Upgrade: Das Setup installiert die neue Version über die vorhandene Instanz. Das ist der einfachste Weg, erfordert aber eine Ausfallzeit, die alte Instanz existiert danach nicht mehr, und ein Zurück dauert länger. Auch ist es nicht von jeder Ausgangsversion möglich: Für ein In-Place-Upgrade auf SQL Server 2022 muss SQL Server 2016 mindestens auf SP3 stehen.
• Migration auf eine Neuinstallation (Side-by-Side): Die neue Version wird auf einem separaten Server installiert, oft mit neuer Hardware und aktuellem Betriebssystem; die Datenbanken werden per Sicherung und Wiederherstellung übertragen. Der alte Server bleibt unverändert, der Rückweg ist einfach, und die Erneuerung von Hardware und Betriebssystem erledigt sich im selben Projekt.

Auch der Microsoft-Leitfaden zur Wahl der Upgrade-Methode hält fest, dass die Neuinstallation Risiko und Ausfallzeit gegenüber dem In-Place-Upgrade verringert. Für Produktivsysteme, vor allem auf älterer Hardware, empfehlen wir deshalb diesen Weg.

SQL Server Upgrade Schritt für Schritt planen

1. Inventar erstellen

Erfassen Sie für jede Instanz Version, Edition (Standard, Express usw.) und Update-Stand sowie für jede Datenbank Größe und Kompatibilitätsgrad (SELECT name, compatibility_level FROM sys.databases;). Vergessen Sie die Objekte außerhalb der Benutzerdatenbanken nicht: Anmeldungen (Logins) liegen in der master-Datenbank, SQL-Server-Agent-Jobs in msdb, und beide müssen auf einem neuen Server neu angelegt werden. Auch Verbindungsserver, SSIS-Pakete, Reporting Services und alle Anwendungen, die auf den SQL Server zugreifen, gehören auf die Liste. Fehlt ein aktueller Überblick, schafft ein IT-Infrastruktur-Audit die nötige Grundlage.

2. Kompatibilität prüfen

Lassen Sie sich von den Herstellern Ihres ERP und Ihrer übrigen Anwendungen schriftlich bestätigen, dass sie die Zielversion unterstützen. Prüfen Sie anschließend mit der SQL-Server-Migrationskomponente in SSMS, welche Probleme das Upgrade blockieren oder Skriptänderungen erfordern könnten, sichten Sie die in der neuen Version entfernten Funktionen und klären Sie die Anforderungen an Hardware, Betriebssystem und Edition des Zielservers.

3. Vollsicherung erstellen und prüfen

Sichern Sie vor dem Start alle Benutzer- und Systemdatenbanken vollständig. Eine Sicherung allein genügt nicht; Sie müssen wissen, dass Sie daraus wirklich wiederherstellen können. Wie ein Wiederherstellungstest abläuft, zeigt unser Beitrag zum SQL-Datenbank-Backup.

4. Wiederherstellung in einer Testumgebung proben

Stellen Sie die Sicherung auf einem Testserver mit der neuen Version wieder her und lassen Sie Buchhaltung, Vertrieb und Lager dort ihre täglichen Abläufe durchspielen. Messen Sie die Dauer der Wiederherstellung, denn sie bestimmt das Ausfallfenster der echten Umstellung. Wichtig: Ein Upgrade ist eine Einbahnstraße. Eine auf der neuen Version geöffnete Datenbank lässt sich nicht auf die alte Version zurückspielen; Ihr Rollback-Plan muss sich deshalb auf den alten Server und die Sicherung vor dem Upgrade stützen.

5. Umstellung in einem geplanten Zeitfenster

Stimmen Sie das Ausfallfenster mit den Fachbereichen ab und meiden Sie Monatsabschluss und Inventur. Stoppen Sie am Umstellungstag die Anwendungen, spielen Sie die letzte Sicherung auf dem neuen Server ein, legen Sie Anmeldungen und Agent-Jobs neu an und richten Sie dann die Verbindungseinstellungen der Anwendungen oder den DNS-Eintrag auf den neuen Server aus. Schalten Sie den alten Server erst ab, wenn die Anwender die neue Umgebung abgenommen haben; tritt eines der vorab festgelegten Abbruchkriterien ein, kehren Sie zu ihm zurück. Das ist dieselbe Rollback-Logik wie in unserem Leitfaden zur Cloud-Migration.

6. Nach dem Upgrade überwachen und den Kompatibilitätsgrad schrittweise anheben

Der Kompatibilitätsgrad legt fest, nach dem Abfrageverhalten welcher SQL-Server-Version eine Datenbank arbeitet. Liegt er bei 100 oder höher, bleibt er bei Upgrade und Wiederherstellung unverändert; manche Verbesserungen der Abfrageverarbeitung greifen erst, wenn Sie ihn anheben. Microsoft empfiehlt diesen Ablauf: Query Store aktivieren, mit dem bisherigen Grad eine Leistungsbasis erfassen, dann den Grad anheben und Abfragen mit Leistungseinbußen ermitteln. Der Query Tuning Assistant in SSMS führt durch diese Schritte. Erstellen Sie nach dem Upgrade eine neue Vollsicherung jeder Datenbank und nutzen Sie für die Abfragezeiten die Prüfpunkte aus unserem Beitrag zur SQL-Datenbankleistung.

Häufige Fehler

• Bis zum Supportende warten: Tests, Lizenzierung und Planung der Ausfallzeit brauchen Zeit; ein Upgrade in letzter Minute überspringt sie.
• Nur die Datenbanken umziehen: Werden Anmeldungen, Agent-Jobs, Verbindungsserver und die Verschlüsselungsschlüssel der Reporting Services vergessen, startet die Anwendung, aber geplante Jobs und Berichte schlagen fehl.
• Produktivsystem ohne Test aktualisieren: Eine inkompatible Abfrage oder eine veraltete Komponente fällt dann erst im Live-Betrieb auf.
• Am ersten Tag den höchsten Kompatibilitätsgrad setzen: Ohne Leistungsbasis lässt sich kaum erkennen, warum eine Abfrage langsamer wurde.
• Lizenzen erst zum Schluss klären: Klären Sie den Lizenzbedarf für neue Version und Edition gleich zu Projektbeginn.

Checkliste für das SQL Server Upgrade

• Sind alle Instanzen, Versionen, Datenbanken, Anmeldungen und Agent-Jobs erfasst?
• Haben die Softwarehersteller die Zielversion schriftlich bestätigt?
• Ist die Methode gewählt (In-Place-Upgrade oder Neuinstallation)?
• Wurde eine Vollsicherung erstellt und auf der neuen Version testweise wiederhergestellt?
• Sind Ausfallfenster, Abbruchkriterien und Rollback-Schritte schriftlich festgehalten?
• Stehen Sicherung nach dem Upgrade, Query-Store-Überwachung und der Plan für den Kompatibilitätsgrad?

In der richtigen Reihenfolge umgesetzt, ist ein SQL Server Upgrade ein kontrolliertes Projekt mit bekanntem Ausfallfenster und klarem Rückweg. Bei ÇAP Teknoloji planen wir SQL-Server-Upgrades gemeinsam mit Ihnen: von der Inventur und Kompatibilitätsanalyse über die Testmigration und den Umstellungsplan bis zur Leistungskontrolle danach. Informieren Sie sich über unsere SQL-Beratung oder nehmen Sie Kontakt auf, um Ihren aktuellen Server gemeinsam zu bewerten.

Häufig gestellte Fragen