Der erweiterte Support für SQL Server 2016 endet am 14. Juli 2026. Wer noch darauf produziert, hat in wenigen Wochen eine Migration vor sich, ob er will oder nicht. Und jeder, der so einen Umzug schon mal gemacht hat, kennt den eigentlichen Schmerz: nicht das Verschieben der Datenbank, sondern der neue Servername, der plötzlich an hundert Stellen geändert werden muss.
Der Servername steht überall, nur nicht an einer Stelle
Die Datenbank umzuziehen ist der einfache Teil. Backup, Restore, fertig. Teuer wird es, weil der physische Servername fest verdrahtet ist. In Verbindungszeichenfolgen von Anwendungen, die ein Lieferant betreut, den du nicht erreichst. In Linked-Server-Definitionen. In vier-teiligen Notationen mitten im Code. In Excel-Mappen mit ODBC-Verbindungen, von denen niemand mehr weiß.
Bei KMU kommt erschwerend hinzu, dass die Anwendungen nacheinander umziehen, jede von ihrem eigenen Lieferanten, zu unterschiedlichen Terminen. In der Zwischenzeit hängt die halbe Landschaft am alten, die andere Hälfte am neuen Server. Damit das überhaupt funktioniert, baust du übergangsweise Linked Server zwischen beiden. Genau die musst du hinterher wieder abräumen. Ein Wochenende reicht dafür selten, und sauber ist es auch nicht.
Der Punkt, an dem die meisten Migrationen wehtun, ist hausgemacht:
Der Servername gehört nicht in die Anwendung.
Die Migration kommt. Immer.
Das ist keine Drohung, das ist Lebenszyklus. Microsoft gibt zehn Jahre Support pro Produkt, danach ist Schluss. SQL Server 2016 fällt am 14. Juli 2026 aus dem erweiterten Support, 2017 folgt 2027, 2019 reicht bis 2030. Extended Security Updates gibt es zwar, aber sie kosten im ersten Jahr rund 75 Prozent des ursprünglichen Lizenzpreises und steigen jährlich weiter. Das ist kein Plan, das ist eine Galgenfrist.
Branchenschätzungen zufolge läuft immer noch etwa jede fünfte produktive SQL-Server-Instanz auf 2016. Die nächste Migrationswelle ist also keine Frage des Ob, sondern des Wann. Und sie wird nicht die letzte sein.
Wer das akzeptiert, stellt nicht die Frage „wie überstehe ich diese eine Migration“, sondern „wie baue ich die Landschaft so, dass jede künftige Migration ein Nicht-Ereignis wird“. Die Antwort ist eine Abstraktionsschicht, die du einführst, solange noch alles ruhig läuft.
Definition: Was ein DNS-Alias hier leistet
Ein DNS-Alias ist ein logischer Name im Namensdienst, der auf einen physischen Hostnamen zeigt, technisch meist ein CNAME-Eintrag. Statt dass eine Anwendung den echten Server SQLPROD01 kennt, kennt sie nur den logischen Namen sql-warenwirtschaft.kunde.intern. Welcher Server dahintersteht, entscheidet ein einziger Eintrag im DNS, nicht die Anwendung.
Damit verschiebt sich die Stelle, an der ein Serverwechsel passiert: weg aus fremden Konfigurationsdateien, hin zu einem zentralen Eintrag, den du selbst kontrollierst.
Ein Alias pro Anwendung, nicht einer pro Server
Hier liegt der eigentliche Trick, und er wird oft falsch gemacht. Wer einen einzigen Alias für den ganzen Server vergibt, hat zwar die Connection-Strings entkoppelt, aber alle Anwendungen hängen weiter aneinander. Du kannst den Server nur als Ganzes umziehen.
Vergib stattdessen einen eigenen Alias pro Anwendung. sql-warenwirtschaft, sql-crm, sql-zeiterfassung, alle als CNAME auf denselben physischen Server, solange er noch der richtige ist. Der Effekt ist Entkopplung: Wenn der Lieferant der Warenwirtschaft seine Datenbank auf den neuen Server zieht, biegst du genau diesen einen Alias um. Die anderen Anwendungen merken davon nichts und bleiben auf dem alten Server.
Damit löst sich das lieferantengetriebene Staffel-Problem von selbst auf. Du brauchst kein Wochenende, an dem alle gleichzeitig migrieren, keine Koordination zwischen Lieferanten, die voneinander nichts wissen. Jeder Umzug ist eine isolierte Umschaltung eines DNS-Eintrags.
Die Vorarbeit ist überschaubar: Die Alias-Schicht jetzt einführen, im laufenden Betrieb, und die Lieferanten einmalig bitten, ihre Verbindungen auf den logischen Namen umzustellen. Das ist der einmalige Aufwand, den du danach nie wieder hast.
Der Kerberos-Stolperstein
Eine ehrliche Einschränkung gehört direkt hierher: CNAME und Windows-Authentifizierung vertragen sich nicht von allein. Ohne passenden Service Principal Name fällt die Anmeldung über den Alias auf NTLM zurück oder schlägt fehl. Den SPN musst du für den Alias registrieren, nicht nur für den echten Hostnamen. Der folgende Befehl registriert den Dienstprincipal für den logischen Namen auf dem aktuellen Server:
setspn -A MSSQLSvc/sql-warenwirtschaft.kunde.intern SQLPROD01
setspn -A MSSQLSvc/sql-warenwirtschaft.kunde.intern:1433 SQLPROD01
Entscheidend ist, dass der SPN auf das Dienstkonto des Ziel-Servers zeigt. Beim Umzug auf einen neuen Server registrierst du den SPN dort erneut und entfernst den alten. Bei reiner SQL-Server-Authentifizierung, wie sie viele Lieferantensysteme nutzen, entfällt das Thema komplett.
Linked Server: den Namen abstrahieren, die Datenquelle umbiegen
Dasselbe Prinzip rettet dich in der Übergangsphase mit den Linked Servern. Der Name eines Linked Servers ist eine Abstraktion. Der Code referenziert ihn über die vier-teilige Notation LINKEDSERVER.Datenbank.Schema.Tabelle. Wenn du den logischen Namen konstant hältst und nur die Datenquelle umbiegst, bleibt der Code unangetastet.
Lege den Linked Server also nicht mit dem physischen Servernamen an, sondern mit einem logischen Namen, dessen Datenquelle entweder der DNS-Alias oder der physische Server ist:
-- Logischer Name bleibt für immer gleich, nur @datasrc aendert sich beim Umzug
EXEC sp_addlinkedserver
@server = 'LS_NAV' -- logischer Name, im Code referenziert
,@srvproduct = ''
,@provider = 'MSOLEDBSQL'
,@datasrc = 'sql-nav.kunde.intern'; -- Alias statt SQLPROD01
Der Witz steckt in der vorletzten Zeile: Steht im @datasrc bereits der DNS-Alias, musst du beim Serverwechsel oft nicht einmal den Linked Server anfassen. Es genügt, den CNAME umzubiegen. Andernfalls droppst du den Linked Server und legst ihn unter demselben logischen Namen neu an, nur mit neuer Datenquelle. Jeder Code, der LS_NAV verwendet, läuft unverändert weiter.
Dass diese Abstraktion kein Luxus ist, zeigt eine aktuelle Falle: Beim Upgrade auf SQL Server 2025 erzwingt der neue OLE-DB-Treiber MSOLEDBSQL 19 standardmäßig die Prüfung von Verbindungsverschlüsselung und Zertifikaten. Linked Server, die noch auf dem alten SQLNCLI-Provider laufen, können nach dem Upgrade brechen, weil der neue Treiber Zertifikatsketten ablehnt, die der alte stillschweigend akzeptiert hat. Wer seine Linked Server ohnehin über eine saubere logische Schicht führt, hat hier eine zentrale Stelle zum Nachziehen statt verstreuter Baustellen.
Wo die Abstraktion an Grenzen stößt
Ein DNS-Alias ist mächtig, aber kein Allheilmittel. Anwendungen, die eine harte IP-Adresse statt eines Namens hinterlegt haben, ignorieren den Alias. Programme, die den Servernamen fest im Quellcode tragen statt in einer Konfiguration, ebenso. Manche Clients und Appliances cachen DNS-Antworten hartnäckig über die TTL hinaus, sodass nach dem Umbiegen ein Neustart nötig wird. Und die SPN-Registrierung für Windows-Authentifizierung ist eine Aufgabe, die man einmal sauber machen muss, sonst hat man statt einer Migration ein Anmeldeproblem.
Der ehrliche Satz lautet: Die Alias-Schicht macht die meisten Migrationen zum Nicht-Ereignis, aber sie zwingt dich, einmal sauber zu inventarisieren, wo überall der Servername klebt. Genau diese Inventur ist ohnehin überfällig.
Was das für jemanden bedeutet, der das nicht selbst baut
Für einen Geschäftsführer ist das hier zunächst Technik-Kauderwelsch. Übersetzt heißt es: Ein Serverwechsel, der heute ein riskantes Wochenende mit mehreren externen Dienstleistern ist, wird zu einer Routine-Umschaltung, die kaum auffällt. Keine stillgelegte Warenwirtschaft am Montagmorgen, keine Lieferanten-Rechnungen für Connection-String-Anpassungen, kein Koordinations-Pingpong zwischen Software-Häusern, die sich nicht kennen.
Wenn dich nicht der Code, sondern die wirtschaftliche Seite interessiert, also was ein vermurkster Serverumzug ein Unternehmen tatsächlich kostet und wie man Altsysteme pragmatisch weiterführt statt teuer abzulösen: dazu schreibe ich aus Entscheider-Sicht. Frag mich danach, dann verlinke ich den passenden Beitrag.
Fazit
Die nächste SQL Server Migration kommt garantiert, spätestens mit dem nächsten End-of-Support. Der Schmerz daran ist optional. Wer pro Anwendung einen DNS-Alias vergibt und seine Linked Server über logische Namen führt, verlegt den Migrationsaufwand von vielen fremden Konfigurationen auf einen einzigen Eintrag im eigenen DNS. Das ist die billigste Architektur-Entscheidung mit dem größten Hebel, die ein SQL-Server-Admin treffen kann.
Wer das einmal eingerichtet hat, für den ist der nächste Serverumzug genau das: ein DNS-Eintrag und ein Restore. Wer es einrichten lassen oder vorher die eigene Landschaft inventarisieren möchte, erreicht mich über sesoft.de/kontakt.
Quellen
- Microsoft Lifecycle, Ende des erweiterten Supports für SQL Server 2016 am 14. Juli 2026: SQLServerCentral, Brent Ozar
- Zertifikatsprüfung und Linked-Server-Brüche beim Upgrade auf SQL Server 2025 (MSOLEDBSQL 19 vs. SQLNCLI): Red9
- Branchenschätzung zum Anteil produktiver SQL Server 2016 Instanzen: Red9 (als Schätzung gekennzeichnet)
Über den Autor
Sönke Schäfer ist selbstständiger IT-Berater und Datenarchitekt aus Ostholstein und arbeitet seit über 25 Jahren mit Microsoft Access, VBA und SQL Server. Sein Schwerpunkt liegt auf SQL Server Backends für gewachsene Anwendungen im norddeutschen Mittelstand und auf Migrationen, die laufende Systeme nicht ausbremsen. Mehr über Sönke Schäfer und Datenschäfer.
