Am 14. Juli 2026 hat Microsoft den Extended Support für SQL Server 2016 eingestellt. Viele mittelständische Unternehmen unterschätzen, was das konkret bedeutet – besonders dann, wenn SSIS das Herz ihres Data Warehouse bildet.
Der 14. Juli 2026 war kein Datum, das für große Schlagzeilen gesorgt hat. Für zahlreiche Unternehmen im DACH-Raum markiert er dennoch einen wichtigen Wendepunkt: An diesem Tag hat Microsoft den Extended Support für SQL Server 2016 eingestellt.
Was bedeutet das konkret? Für die Plattform gibt es keine regulären Sicherheitspatches, Bug-Fixes oder technischen Updates mehr. Wer SQL Server 2016 weiterbetreibt – und damit in vielen Fällen auch SQL Server Integration Services, kurz SSIS, als zentrales ETL-Werkzeug –, arbeitet seitdem unter deutlich veränderten Bedingungen.
Das klingt zunächst rein nach einem klassischen IT-Thema. Ist es aber nicht, jedenfalls nicht nur. Denn wenn SQL Server und SSIS die Grundlage für Reporting, Planung und Datenversorgung bilden, betrifft das Supportende nicht allein die Technik. Es betrifft die Sicherheit, die Compliance und im Zweifel die Verlässlichkeit des gesamten Data Warehouse.
Der naheliegende Einwand lautet häufig: Der Server läuft doch noch. Das stimmt. SQL Server 2016 stellt seinen Betrieb nicht automatisch ein, nur weil der Supportzeitraum abgelaufen ist. Datenbanken bleiben erreichbar, SSIS-Pakete werden weiterhin ausgeführt und bestehende Berichte funktionieren zunächst wie gewohnt.
Genau darin liegt allerdings auch das Problem. Während im Tagesgeschäft scheinbar alles unverändert weiterläuft, wächst das Risiko im Hintergrund. Drei Punkte sind dabei besonders relevant.
Neue Sicherheitslücken bleiben offen. Wird künftig eine Schwachstelle in SQL Server 2016 entdeckt, gibt es dafür im regulären Support keinen Fix mehr. Neue CVEs können also hinzukommen, ohne dass Microsoft die Ursache behebt. Für Systeme, die personenbezogene Daten verarbeiten oder an geschäftskritische Prozesse angebunden sind, ist das keine Kleinigkeit. Je länger eine ungepatchte Plattform betrieben wird, desto größer wird die Zahl potenzieller Angriffspunkte. Dass ein System intern betrieben wird und nicht direkt aus dem Internet erreichbar ist, beseitigt dieses Risiko nicht vollständig.
Der Erklärungsbedarf bei Audits steigt. Auch aus Compliance-Sicht wird der weitere Betrieb anspruchsvoller. ISO 27001, die DSGVO und branchenspezifische Anforderungen, etwa im Finanz- oder Gesundheitswesen, setzen in vielen Fällen voraus, dass eingesetzte Software aktiv gepflegt und mit Sicherheitsupdates versorgt wird. Ein geschäftskritisches System auf einer nicht mehr unterstützten Plattform zu betreiben, kann deshalb bei Audits zum Problem werden. Unternehmen müssen dann nachvollziehbar darlegen, wie sie die daraus entstehenden Risiken bewerten und mit welchen Maßnahmen sie diese begrenzen.
Extended Security Updates kaufen Zeit. Microsoft bietet mit den Extended Security Updates, kurz ESU, eine kostenpflichtige Verlängerung der Sicherheitsversorgung an. Diese Option ist allerdings zeitlich begrenzt und reicht maximal bis Juli 2029. Das kann sinnvoll sein, wenn eine kurzfristige Migration nicht realistisch ist. Eine dauerhafte Lösung ist es aber nicht. Die bestehende Architektur wird dadurch weder moderner noch leichter wartbar. ESU verschafft Luft. Mehr nicht.
In vielen mittelständischen Data-Warehouse-Architekturen steckt SSIS tief drin. Pakete laden Daten aus ERP-Systemen, transformieren sie in Staging-Bereiche, befüllen Data Marts und versorgen anschließend SSAS-Cubes oder Power-BI-Reports.
Diese Umgebungen sind selten in einem einzigen Projekt entstanden. Sie wurden über Jahre erweitert, an neue Anforderungen angepasst und um zusätzliche Datenquellen ergänzt. Manche laufen seit mehr als einem Jahrzehnt. Die Pakete basieren auf SQL Server 2016, entwickelt wurde mit SQL Server Data Tools derselben Generation, und die Dokumentation ist – realistisch betrachtet – häufig dünn.
Mit dem SQL Server 2016 End of Support steht deshalb nicht nur eine einzelne Datenbankversion auf dem Prüfstand. Betroffen ist oft ein kompletter Stack aus Datenbank, SSIS-Paketen, Entwicklungswerkzeugen, Treibern und Konnektoren.
Für Data-Warehouse-Teams ergeben sich daraus drei typische Herausforderungen.
Bestimmte SSIS-Bestandteile wurden von Microsoft bereits früher deprecated, darunter etwa der Attunity Oracle Connector, Hadoop-Tasks oder einzelne CDC-Komponenten.
In neueren Umgebungen funktionieren solche Bestandteile möglicherweise nicht mehr zuverlässig oder müssen ersetzt werden. Besonders bei historisch gewachsenen SSIS-Projekten ist oft nicht auf Anhieb klar, welche Pakete von diesen Abhängigkeiten betroffen sind. Was im laufenden Betrieb unauffällig bleibt, kann bei einer Migration plötzlich zum Hindernis werden.
SSIS-Pakete aus 2016er-Projekten lassen sich nicht in jedem Fall unverändert in eine neuere SQL-Server-Umgebung übernehmen. Änderungen an Package-Formaten, Konnektoren oder eingesetzten Komponenten können Anpassungen erforderlich machen.
Wie hoch der Aufwand ausfällt, hängt stark von der jeweiligen Umgebung ab. Standardisierte Pakete lassen sich in der Regel leichter übertragen als individuell erweiterte Lösungen mit älteren Treibern, Skriptkomponenten oder speziellen Konnektoren. Eine Migration sollte deshalb nicht als reiner Versionswechsel verstanden werden, sondern als technisches Vorhaben, das sorgfältige Tests und eine realistische Einschätzung der Abhängigkeiten benötigt.
Neben den technischen Risiken spielt die personelle Seite eine wichtige Rolle. Die Mitarbeitenden, die den Legacy-SSIS-Stack aufgebaut haben, arbeiten möglicherweise längst nicht mehr im Unternehmen. Neue Kolleginnen und Kollegen kennen dagegen eher Azure Data Factory oder Microsoft Fabric als SSIS-Projekte auf Basis von Visual Studio 2015.
Damit wächst die Abhängigkeit von wenigen Personen, die noch wissen, wie die bestehende Architektur aufgebaut ist und warum bestimmte Lösungen auf genau diese Weise umgesetzt wurden. Je länger eine Modernisierung aufgeschoben wird, desto schwieriger kann es werden, dieses Wissen zu sichern oder neu aufzubauen.
SQL Server 2016 findet sich besonders häufig dort, wo eine BI-Infrastruktur über viele Jahre gewachsen ist und im Tagesgeschäft zuverlässig funktioniert. Typische Beispiele sind Industrieunternehmen mit 50 bis 500 Mitarbeitenden, die SAP- oder ERP-Daten über SSIS in ein eigenes Data Warehouse laden. Auch Handelsunternehmen nutzen solche Umgebungen für Absatzplanung, Lagersteuerung und Logistikanalysen, während bei Dienstleistungsunternehmen häufig SSRS-basierte Berichte auf SQL Server 2016 aufsetzen.
Was diese Unternehmen verbindet, ist weniger die Branche als die Rolle der Plattform: Die BI-Infrastruktur ist betriebskritisch, wird aber nicht immer als eigenes strategisches Entwicklungsprojekt behandelt. Sie läuft im Hintergrund, häufig über viele Jahre und ohne größere Aufmerksamkeit.
Das funktioniert so lange, wie Ladevorgänge stabil bleiben, Schnittstellen erreichbar sind und Berichte zuverlässig bereitstehen. Kritisch wird es erst, wenn eine Komponente ausfällt, ein Sicherheitsproblem auftritt oder eine Migration kurzfristig notwendig wird. Dann zeigt sich, wie viele operative Prozesse inzwischen von einer Plattform abhängen, die über lange Zeit lediglich „mitgelaufen“ ist.
Handlungsbedarf besteht, keine Frage. Das heißt aber nicht, dass jedes Unternehmen morgen die gesamte Datenplattform in die Cloud verschieben muss. Sinnvoller ist ein strukturiertes Vorgehen in drei Schritten.
Bestandsaufnahme. Welche SQL-Server-2016-Instanzen gibt es überhaupt? Welche Datenbanken und SSIS-Pakete laufen darauf, welche Datenquellen sind angebunden und welche Berichte oder Geschäftsprozesse hängen davon ab? Dabei sollten auch Test-, Entwicklungs- und Nebeninstanzen berücksichtigt werden. Gerade solche Systeme werden im Alltag leicht übersehen, obwohl sie weiterhin Daten verarbeiten oder Abhängigkeiten zu anderen Anwendungen besitzen. Die Bestandsaufnahme ist häufig schneller erledigt als zunächst befürchtet. Die eigentliche Herausforderung besteht meist darin, vergessene Instanzen überhaupt erst zu finden.
Risikobewertung. Auf dieser Grundlage lässt sich priorisieren. Welche Systeme sind aus anderen Netzen oder aus dem Internet erreichbar? Welche verarbeiten personenbezogene Daten? Welche sind regulatorisch relevant, und welche Folgen hätte ein mehrtägiger Ausfall? Nicht jede Instanz ist gleich kritisch. Ein interner Testserver ist anders zu bewerten als eine Plattform, die täglich Daten für Absatzplanung, Lagersteuerung oder Managementberichte bereitstellt.
Strategieentscheidung. Erst danach sollte entschieden werden, wie es weitergeht. Möglich ist ein Lift & Shift über die Azure-SSIS Integration Runtime, bei dem bestehende SSIS-Pakete zunächst weitgehend erhalten bleiben. Ebenso denkbar ist eine schrittweise Modernisierung in Richtung Azure Data Factory oder Microsoft Fabric. Auch ein hybrider Ansatz kann sinnvoll sein: stabile Komponenten bleiben vorerst bestehen, während besonders kritische oder wartungsintensive Datenflüsse nach und nach modernisiert werden.
Welche Variante passt, hängt von der vorhandenen Architektur, dem verfügbaren Budget und der Frage ab, wie viel technische und organisatorische Veränderung das Unternehmen aktuell bewältigen kann. Eine pauschale Lösung gibt es deshalb nicht. Entscheidend ist, den Weg bewusst zu wählen, statt erst unter Zeitdruck reagieren zu müssen.
Das Ende des Extended Supports für SQL Server 2016 ist kein Grund zur Panik. Aber es ist auch kein Thema, das sich noch lange aussitzen lässt. Jede neu entdeckte Schwachstelle, jeder veraltete Konnektor und jedes verlorene Stück Know-how erhöht das Risiko.
Unternehmen, die jetzt eine strukturierte Bestandsaufnahme durchführen, behalten die Kontrolle über Tempo und Weg. Sie können Prioritäten setzen, Budgets planen und selbst entscheiden, ob ein Upgrade, eine schrittweise Modernisierung oder ein hybrider Ansatz sinnvoll ist.
Wer dagegen wartet, bis eine Sicherheitslücke bekannt wird, eine Komponente ausfällt oder ein Audit konkrete Maßnahmen verlangt, muss unter deutlich ungünstigeren Bedingungen reagieren. Dann bestimmen nicht mehr Strategie und Prioritäten den Migrationspfad, sondern der akute Handlungsdruck.
→ Zum Download: Kostenloser Entscheidungsguide „SQL Server EOL – Migrate, Modernize oder Hybrid?“
Die roosi GmbH unterstützt mittelständische Unternehmen im DACH-Raum bei genau dieser Entscheidung. Nicht mit vorgefertigten Migrationsvorlagen, sondern mit einer ehrlichen Bestandsaufnahme und einem Pfad, der zur vorhandenen Architektur und Organisation passt.