Die Instanz läuft weiter, sie wird nur nicht mehr repariert
Zwischen Migration, verwalteter Umgebung und gekaufter Zeit entscheidet nicht die Technik allein, sondern die Freigabe deiner Anwendungen und der Umfang deiner Tests.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Das Datum steht seit Jahren fest, die Entscheidung fällt trotzdem zu spät
Microsoft veröffentlicht die Lebenszyklusdaten mit dem Erscheinen einer Version, üblicherweise fünf Jahre allgemeiner Support und danach fünf Jahre erweiterter Support. Der erweiterte Support für SQL Server 2016 ist am 15. Juli 2026 ausgelaufen, für SQL Server 2017 endet er am 13. Oktober 2027. Niemand wird davon überrascht, und trotzdem beginnt die Planung in vielen Häusern erst, wenn eine externe Prüfung den Punkt aufschreibt.
Der Grund dafür ist selten Nachlässigkeit, sondern die Verteilung der Zuständigkeit. Die Datenbank gehört dem IT-Betrieb, die Anwendung darauf gehört einem Fachbereich, und die Freigabe für eine neue Datenbankversion erteilt der Hersteller dieser Anwendung. Solange niemand diese drei Beteiligten an einen Tisch holt, verschiebt jeder die Entscheidung auf den jeweils anderen. Der Betrieb wartet auf die Freigabe, der Fachbereich auf ein Budget, der Hersteller auf eine Anfrage, die nie gestellt wurde.
Teuer wird das an der Stelle, an der die Zeit nicht mehr reicht. Eine Migration mit ordentlichem Test braucht Monate, nicht Wochen: Bestandsaufnahme, Freigaben einholen, Testsystem aufbauen, fachlich abnehmen, Laufzeiten vergleichen, umschalten. Wer erst drei Wochen vor dem Stichtag beginnt, hat praktisch nur noch die Wahl zwischen einem ungetesteten Umschalten und dem Kauf erweiterter Sicherheitsupdates zu einem Zeitpunkt, an dem der Preis kein Verhandlungsgegenstand mehr ist.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer entscheidet was, wenn eine Version ausläuft
Fast alle Verzögerungen in solchen Vorhaben entstehen nicht an einer technischen Hürde, sondern daran, dass eine Entscheidung bei niemandem lag. Diese Aufstellung ordnet die typischen Punkte den Beteiligten zu.
| Thema | Wer entscheidet | Wer setzt um | Stolperfalle |
|---|---|---|---|
| Stichtag und Bestandsaufnahme | Die IT-Leitung gemeinsam mit der Informationssicherheit, weil ab dem Stichtag ein bekanntes und nicht behebbares Risiko im Haus steht. | Der Datenbankbetrieb erstellt eine Liste aller Instanzen mit Version, Edition, Kompatibilitätsgrad und zugehöriger Anwendung. | Die Liste ist regelmäßig unvollständig. Fachanwendungen bringen häufig eine eigene Express-Instanz mit, die in keinem Inventar auftaucht und trotzdem im Netz erreichbar ist. |
| Zielbild und Budget | Die IT-Leitung, denn zwischen Migration, verwalteter Umgebung und gekaufter Zeit liegen unterschiedliche Kostenarten, einmalig gegen laufend. | Architektur und Betrieb bewerten die Wege je Instanz und schlagen eine Zuordnung vor, statt einen Weg pauschal für alle zu wählen. | Erweiterte Sicherheitsupdates werden als Dauerlösung eingeplant. Diese Updates sind zeitlich begrenzt, werden jährlich bezahlt und ersetzen keine Planung, sondern kaufen die Zeit dafür. |
| Freigabe der Anwendungen | Der Fachbereich als Vertragspartner des Anwendungsherstellers, gemeinsam mit dem Einkauf, wenn eine Vertragsanpassung nötig wird. | Die Anwendungsbetreuung fragt die unterstützte Datenbankversion ab und dokumentiert die Antwort schriftlich. | Die Freigabe wird erst nach der Migration eingeholt. Fehlt sie, verweigert der Hersteller im Störungsfall die Unterstützung, und das trifft ausgerechnet die Wochen direkt nach dem Umschalten. |
| Kompatibilitätsgrad und Abfrageverhalten | Der Datenbankbetrieb zusammen mit der Anwendungsentwicklung, weil die Änderung Ausführungspläne betrifft und damit Laufzeiten verschiebt. | Der Datenbankbetrieb hebt den Grad in einem eigenen Wartungsfenster an, nachdem der Query Store einen Vergleichswert gesammelt hat. | Migration und Anhebung am selben Abend. Wenn danach etwas langsamer läuft, lässt sich nicht mehr unterscheiden, ob die neue Version oder das neue Schätzverfahren dahintersteckt. |
| Test und Abnahme | Der Fachbereich gibt frei, denn nur dort ist bekannt, welche Abläufe geschäftskritisch sind und welche Laufzeiten toleriert werden. | Anwendungsbetreuung und Datenbankbetrieb fahren die Abläufe auf dem Testsystem und vergleichen Laufzeiten gegen die gemessene Ausgangslage. | Getestet wird die Funktion, nicht die Dauer. Ein nächtlicher Abschluss, der von zwei auf sieben Stunden wächst, besteht jeden fachlichen Test und fällt erst am Monatsende auf. |
Stichtag und Bestandsaufnahme
- Wer entscheidet
- Die IT-Leitung gemeinsam mit der Informationssicherheit, weil ab dem Stichtag ein bekanntes und nicht behebbares Risiko im Haus steht.
- Wer setzt um
- Der Datenbankbetrieb erstellt eine Liste aller Instanzen mit Version, Edition, Kompatibilitätsgrad und zugehöriger Anwendung.
- Stolperfalle
- Die Liste ist regelmäßig unvollständig. Fachanwendungen bringen häufig eine eigene Express-Instanz mit, die in keinem Inventar auftaucht und trotzdem im Netz erreichbar ist.
Zielbild und Budget
- Wer entscheidet
- Die IT-Leitung, denn zwischen Migration, verwalteter Umgebung und gekaufter Zeit liegen unterschiedliche Kostenarten, einmalig gegen laufend.
- Wer setzt um
- Architektur und Betrieb bewerten die Wege je Instanz und schlagen eine Zuordnung vor, statt einen Weg pauschal für alle zu wählen.
- Stolperfalle
- Erweiterte Sicherheitsupdates werden als Dauerlösung eingeplant. Diese Updates sind zeitlich begrenzt, werden jährlich bezahlt und ersetzen keine Planung, sondern kaufen die Zeit dafür.
Freigabe der Anwendungen
- Wer entscheidet
- Der Fachbereich als Vertragspartner des Anwendungsherstellers, gemeinsam mit dem Einkauf, wenn eine Vertragsanpassung nötig wird.
- Wer setzt um
- Die Anwendungsbetreuung fragt die unterstützte Datenbankversion ab und dokumentiert die Antwort schriftlich.
- Stolperfalle
- Die Freigabe wird erst nach der Migration eingeholt. Fehlt sie, verweigert der Hersteller im Störungsfall die Unterstützung, und das trifft ausgerechnet die Wochen direkt nach dem Umschalten.
Kompatibilitätsgrad und Abfrageverhalten
- Wer entscheidet
- Der Datenbankbetrieb zusammen mit der Anwendungsentwicklung, weil die Änderung Ausführungspläne betrifft und damit Laufzeiten verschiebt.
- Wer setzt um
- Der Datenbankbetrieb hebt den Grad in einem eigenen Wartungsfenster an, nachdem der Query Store einen Vergleichswert gesammelt hat.
- Stolperfalle
- Migration und Anhebung am selben Abend. Wenn danach etwas langsamer läuft, lässt sich nicht mehr unterscheiden, ob die neue Version oder das neue Schätzverfahren dahintersteckt.
Test und Abnahme
- Wer entscheidet
- Der Fachbereich gibt frei, denn nur dort ist bekannt, welche Abläufe geschäftskritisch sind und welche Laufzeiten toleriert werden.
- Wer setzt um
- Anwendungsbetreuung und Datenbankbetrieb fahren die Abläufe auf dem Testsystem und vergleichen Laufzeiten gegen die gemessene Ausgangslage.
- Stolperfalle
- Getestet wird die Funktion, nicht die Dauer. Ein nächtlicher Abschluss, der von zwei auf sieben Stunden wächst, besteht jeden fachlichen Test und fällt erst am Monatsende auf.
Sechs Schritte bis zum Umschalttermin
- 01 Alle Instanzen erfassen, mit Version, Edition und zugehöriger Anwendung.
- 02 Für jede Anwendung die vom Hersteller freigegebene Zielversion abfragen.
- 03 Den Weg festlegen: neue Version, verwaltete Umgebung oder Zeit kaufen.
- 04 Mit dem Migrationsassistenten Blockierendes und Veraltetes aufspüren.
- 05 Auf einem Testsystem migrieren und Laufzeiten mit dem Vorher vergleichen.
- 06 Erst nach dem stabilen Betrieb den Kompatibilitätsgrad anheben.
Was du danach begründet entscheidest statt zu verschieben
Die Frage ist nie, ob migriert wird, sondern wann und auf welchem Weg. Sobald der Bestand bekannt ist und die Freigaben vorliegen, ist der Rest ein planbares Vorhaben mit einem Termin, an dem du dich festhalten kannst.
Den Bestand vollständig erfassen
Du weißt, welche Instanzen es gibt, in welcher Version und Edition sie laufen und welche Anwendung an jeder hängt. Die Überraschungen stecken erfahrungsgemäß in den Instanzen, die eine Fachanwendung stillschweigend mitinstalliert hat.
Die Herstellerfreigabe früh einholen
Du klärst vor jeder Planung, welche Datenbankversion der Anwendungshersteller unterstützt. Eine Migration ohne diese Freigabe kostet im Störungsfall den Anspruch auf Unterstützung, und das fällt genau dann auf, wenn du sie brauchst.
Zwischen den drei Wegen begründet wählen
Du kennst den Unterschied zwischen Aktualisierung an Ort und Stelle, Aufbau daneben mit Sicherung und Wiederherstellung sowie dem Umzug in eine verwaltete Umgebung, und du weißt, wann erweiterte Sicherheitsupdates die vernünftige Zwischenlösung sind.
Entfernte Funktionen vorher finden
Du prüfst mit dem Migrationsassistenten und über den Leistungsindikator für veraltete Funktionen, was in deinen Datenbanken steckt, statt es beim ersten Fehler nach dem Umschalten zu erfahren.
Den Kompatibilitätsgrad getrennt schalten
Du migrierst zuerst und hebst den Kompatibilitätsgrad erst danach in einem eigenen Schritt an. So bleibt zuordenbar, ob eine Verschlechterung von der neuen Version oder vom neuen Schätzverfahren kommt.
Den Testumfang an Laufzeiten festmachen
Du misst vor dem Umschalten die Laufzeiten der wichtigsten Abfragen und vergleichst sie danach. Ein rein fachlicher Test bestätigt nur, dass die Anwendung startet, nicht dass der Monatsabschluss noch in der Nacht durchläuft.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was das Support-Ende konkret ändert
Am Tag nach dem Stichtag funktioniert alles wie am Tag davor. Es gibt keinen Schalter, der eine Instanz abschaltet, keine Meldung und keine Einschränkung im Betrieb. Weg sind ausschließlich drei Dinge: Sicherheitsupdates, kumulative Updates mit Fehlerkorrekturen und der Anspruch auf technische Unterstützung durch Microsoft. Eine Schwachstelle, die im Frühjahr danach bekannt wird, bleibt in dieser Version offen, und zwar dauerhaft.
Wirksam wird das über andere Wege als die Technik. Prüfungen zur Informationssicherheit führen nicht unterstützte Software als Befund. Wer Karten- oder Gesundheitsdaten verarbeitet, stößt in den einschlägigen Anforderungskatalogen auf die Pflicht, Systeme mit Sicherheitsupdates zu versorgen, was mit einer nicht mehr gepflegten Version nicht erfüllbar ist. Auch Versicherungen für Cyberschäden fragen inzwischen nach dem Patchstand. Der Befund kostet dann nicht Rechenleistung, sondern Zeit für Stellungnahmen und Ausnahmegenehmigungen.
Dazu kommt der Zug aus dem Umfeld. Neue Betriebssystemversionen werden für eine alte SQL-Server-Version irgendwann nicht mehr unterstützt, Treiber und Client-Bibliotheken werden abgekündigt, und Hersteller von Fachanwendungen setzen mit ihren neuen Ständen aktuelle Datenbankversionen voraus. Eine ausgelaufene Version wird dadurch schrittweise zur Bremse für Vorhaben, die mit der Datenbank selbst nichts zu tun haben.
Die drei Wege und wann welcher passt
Die Aktualisierung an Ort und Stelle installiert die neue Version über die vorhandene. Das geht schnell und braucht keine zusätzliche Hardware, hat aber einen unangenehmen Zug: Der Rückweg führt nur über die Wiederherstellung des ganzen Servers. Dieser Weg eignet sich für kleine, unkritische Instanzen und für Umgebungen, in denen ein längeres Fenster mit gesicherter Rücksetzmöglichkeit zur Verfügung steht.
Der Aufbau daneben ist in fast allen anderen Fällen der bessere Weg. Du richtest eine neue Instanz auf einem neuen Server ein, überträgst die Datenbanken mit Sicherung und Wiederherstellung, testest dort in Ruhe und schaltest zum Termin nur noch die Anwendungen um. Der Rückweg besteht darin, den alten Server wieder anzusprechen, was in Minuten geschieht. Nicht vergessen wird dabei alles, was außerhalb der Benutzerdatenbanken lebt: Anmeldungen samt Kennworthashes und Sicherheitskennungen, Aufträge im Agent, Verbindungsserver, Datenbank-E-Mail, Zertifikate und die Instanzeinstellungen selbst. Werden Anmeldungen neu angelegt statt übertragen, passen die Kennungen nicht mehr zu den Benutzern in der Datenbank, und die betroffenen Konten kommen nicht mehr an ihre Daten.
Der Umzug in eine verwaltete Umgebung verschiebt die Versionspflege zum Betreiber, damit fällt diese Frage in Zukunft weg. Der Preis besteht aus laufenden Kosten und aus Einschränkungen, die vorher geprüft werden wollen, etwa beim Zugriff auf das Dateisystem, bei Verbindungsservern und beim Agent. Erweiterte Sicherheitsupdates schließlich sind kein vierter Weg, sondern eine Verlängerung: Geliefert werden nach dem Stichtag weiterhin Korrekturen für kritische Schwachstellen, werden jährlich bezahlt und stehen nur für einen begrenzten Zeitraum zur Verfügung. Sinnvoll sind sie, wenn eine Fachanwendung erst in zwölf Monaten in einer freigegebenen Fassung vorliegt, nicht als Ersatz für eine Entscheidung.
Den Aufwand vorher abschätzen
Das Werkzeug dafür ist der Data Migration Assistant. Er prüft eine Datenbank gegen eine Zielversion und liefert zwei Listen: blockierende Punkte, die vor der Migration behoben werden müssen, und Verhaltensänderungen, die danach auffallen könnten. Er meldet außerdem entfernte Funktionen, und genau das ist die Liste, die man vorher sehen will. In SQL Server 2022 fiel etwa Distributed Replay weg, der bisherige SQL Server Native Client wird nicht mehr weiterentwickelt und ist durch den aktuellen OLE-DB- beziehungsweise ODBC-Treiber zu ersetzen.
Eine zweite, oft übersehene Quelle steckt in der laufenden Instanz selbst. Der Leistungsindikator für veraltete Funktionen zählt, wie oft eine als veraltet markierte Funktion seit dem Neustart tatsächlich verwendet wurde. Du fragst ihn über sys.dm_os_performance_counters ab und siehst damit nicht nur, was theoretisch im Code steht, sondern was im Betrieb wirklich aufgerufen wird. Lass die Instanz vorher ein paar Wochen laufen, damit auch Monats- und Quartalsläufe darin auftauchen.
Zum Aufwand gehören schließlich die Dinge neben der Engine. Wenn Berichte über die Reporting Services laufen, ist deren Migration ein eigenes Teilprojekt mit eigener Datenbank und eigenen Berechtigungen. Wenn Ladestrecken mit den Integration Services arbeiten, müssen die Projekte auf die neue Fassung angehoben und im Katalog der Zielinstanz bereitgestellt werden. Und wenn Analysis Services im Spiel sind, entscheidet das Modell darüber, ob eine Übernahme überhaupt ohne Neuaufbau möglich ist. Diese drei Punkte machen aus einer Datenbankmigration erfahrungsgemäß ein Vorhaben, das die dreifache Zeit braucht.
Der Kompatibilitätsgrad ist der eigentliche Schalter
Eine Datenbank behält bei der Migration ihren bisherigen Kompatibilitätsgrad, sofern er von der neuen Version noch getragen wird. SQL Server 2022 unterstützt Grade bis hinunter zu 100, was dem Stand von SQL Server 2008 entspricht. Das ist bewusst so gebaut: Du bekommst zuerst die neue Engine mit ihren Korrekturen und ihrer Unterstützung, während das Abfrageverhalten unverändert bleibt. Erst das Anheben des Grads schaltet die neuen Verfahren scharf.
Der wichtigste Einschnitt liegt bei Grad 120. Dort wird das mit SQL Server 2014 eingeführte Schätzverfahren für Zeilenzahlen aktiv, und das kann Ausführungspläne verändern. In der überwiegenden Zahl der Fälle zum Besseren, aber eben nicht in allen. Eine einzelne Abfrage, die bisher in zwei Sekunden lief und danach zwei Minuten braucht, reicht aus, um einen nächtlichen Lauf zu sprengen. Jeder weitere Grad bringt zusätzliche Änderungen am Schätzverfahren mit, die jeweils nur im neuen Standardgrad wirksam werden. Deshalb gehört die Anhebung in einen eigenen Termin, getrennt von der Migration, und wer den Sprung entschärfen will, hebt den Grad an und setzt zunächst LEGACY_CARDINALITY_ESTIMATION auf ON.
Das Sicherheitsnetz dafür heißt Query Store. Schalte ihn nach der Migration ein und lass ihn bei unverändertem Kompatibilitätsgrad lange genug laufen, dass die typischen Lastspitzen enthalten sind. Hebst du den Grad danach an, zeigt der Bericht über zurückgegangene Abfragen die betroffenen Fälle, und du kannst einen bewährten Plan gezielt erzwingen, statt den ganzen Schritt zurückzunehmen. Der Query Tuning Assistant führt durch genau dieses Vorgehen. Wichtig ist die Reihenfolge: Der Vergleichswert muss vor der Umstellung entstanden sein, nachträglich lässt er sich nicht mehr erzeugen.
Dazu passende Kurse
Wer wissen will, was ihn auf der Zielversion erwartet, bevor die Migration geplant wird, ist bei den Kurse zur aktuellen SQL-Server-Generation richtig.
Solange der Bestand noch auf einer früheren Version läuft, halten die Trainings zum Betrieb älterer SQL-Server-Stände den laufenden Betrieb bis zum Umschalttermin sauber.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Super Schulung, in der der Trainer auch auf eigene Fragestellungen eingegangen ist.
Super Grundlagenschulung mit allen wichtigen Punkten und hilfreichen Tipps!
Schön, sich 5 Tage ungestört mit Postgres beschäftigen zu können.
Häufige Fragen
Kann ich von SQL Server 2012 direkt auf die aktuelle Version wechseln?
Was passiert mit meinen Anmeldungen und Agent-Aufträgen?
Lohnt sich der Umzug in eine verwaltete Datenbank statt einer neuen Version?
Wie lange kann ich mit erweiterten Sicherheitsupdates weiterfahren?
Passt thematisch dazu
Wenn du den Weg in eine verwaltete Umgebung ernsthaft prüfst, beantwortet der Vergleich der verwalteten Datenbankdienste in AWS und Azure die Frage, welche Variante Agent, Verbindungsserver und datenbankübergreifende Abfragen noch mitbringt.
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Datenbanken-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Vom bekannten Enddatum zum belastbaren Umschalttermin
Bei cmt gehst du die aktuelle Version einmal vollständig durch und siehst dabei, was sich gegenüber deinem Bestand geändert hat und worauf beim Umstieg zu achten ist.