Auf dem Tisch liegt bald eine SQL Server Migration. Vielleicht, weil SQL Server 2016 am 14. Juli 2026 aus dem Support fällt, vielleicht wegen neuer Hardware. Gleich werden externe Dienstleister Aufwände schätzen, und du sollst diese Schätzung beurteilen. Aber woran erkennst du, ob ein veranschlagtes langes Wochenende fair ist oder einfach nur abgerechnete Stunden? Dafür hilft es, den Ablauf einer sauberen Migration zu kennen, bevor jemand sie dir verkauft.
Warum dieselbe Migration sehr unterschiedlich teuer ist
Eine SQL Server Migration kostet nicht das, was die Datenmenge nahelegt, sondern das, was die Methode verlangt. Dieselbe Datenbank lässt sich an einem ruhigen Vormittag umziehen oder zu einem nervösen Wochenende mit drei Dienstleistern aufblähen. Der Unterschied liegt nicht in der Technik, sondern in der Vorbereitung.
Der teure Teil ist nie die Datenbank selbst. Teuer wird alles drumherum: Anmeldungen, nächtliche Hintergrund-Jobs, Verbindungen zu anderen Systemen, Konfiguration. Wird das von Hand und ohne Probelauf gemacht, entsteht ein Großereignis mit Risiko. Wird es vorbereitet und geprobt, wird es Routine. Wer nach Stunden abrechnet, hat kein Interesse daran, dir den zweiten Weg zu zeigen.
Die nächste Migration kommt übrigens garantiert, und sie ist nicht die letzte. Microsoft gibt zehn Jahre Support pro Version. Branchenschätzungen zufolge läuft noch etwa jede fünfte produktive Instanz auf SQL Server 2016. Es lohnt sich also, den Ablauf einmal grundsätzlich zu verstehen, nicht nur für dieses eine Mal.
Der vollständige Ablauf einer sauberen Migration
Eine professionell vorbereitete Migration läuft in klar getrennten Phasen ab. Du musst keine davon selbst ausführen. Aber du solltest erkennen, ob ein Angebot sie enthält oder überspringt.
- Vorbereitung. Die wichtigste Phase passiert lange vor dem Umzug. Jede Anwendung bekommt einen logischen Namen, einen DNS-Alias, statt den physischen Server fest in ihren Verbindungen zu tragen. Dieser eine Schritt entkoppelt den Umzug von allen Anwendungen und macht ihn überhaupt erst wiederholbar. Wer ihn auslässt, muss bei jedem Umzug in fremden Systemen den Servernamen suchen und ändern. Das ist der Hauptgrund, warum Migrationen teuer werden.
- Nur-Lesen-Tests. Bevor irgendetwas verschoben wird, wird der Bestand inventarisiert: Welche Datenbanken, Anmeldungen, Jobs und Fremdverbindungen leben auf dem Server? Diese Phase verändert nichts und ist gefahrlos. Sie liefert die Liste, gegen die später geprüft wird, ob wirklich alles mitgekommen ist.
- Probefahrt (Test-Migration). Eine Test-Migration ist ein vollständiger Umzug auf den neuen Server, während die echten Anwendungen unberührt weiterlaufen. Möglich ist das, weil der logische Name noch auf den alten Server zeigt. Der neue Server wird aufgebaut, geprüft, wieder abgeräumt und neu aufgebaut, so oft, bis es sitzt. Das ist der Unterschied zwischen „wir migrieren am Stichtag zum ersten Mal“ und „wir haben den Ablauf fünfmal geübt“. Eine Migration ohne Probefahrt ist ein blinder Start.
- Kontrollen. Nach jeder Probefahrt wird geprüft, und zwar nicht nur, ob die Objekte da sind, sondern ob sie funktionieren. Eine Anmeldung kann existieren und sich trotzdem nicht anmelden. Eine Verbindung zu einem Fremdsystem kann als Eintrag vorhanden sein und zur Laufzeit scheitern. Vorhanden ist nicht gleich funktioniert. Genau hier trennt sich gründliche Arbeit von Augenwischerei.
- Aufräumen. Vor jedem neuen Probelauf wird das Ziel wieder in einen definierten Nullzustand zurückgesetzt. So startet jeder Durchgang gleich, und der geprobte Ablauf ist verlässlich derselbe wie der echte. Ohne diese Disziplin probt man jedes Mal etwas anderes.
- Echt-Migration. Erst wenn die Probefahrten sauber durchlaufen, kommt der eigentliche Umzug. Die große Datensicherung ist da längst eingespielt. Am Stichtag wird nur noch die alte Quelle stillgelegt, der allerletzte Datenstand nachgezogen und der neue Server scharf geschaltet. Das eigentliche Zeitfenster schrumpft dadurch von Stunden auf Minuten pro Anwendung.
- DNS-Umschaltung. Jetzt, und erst jetzt, wird der logische Name auf den neuen Server umgebogen. Ab diesem Moment reden die Anwendungen mit dem neuen Server, ohne dass in einer einzigen Anwendung etwas geändert werden musste.
- Anwendungstest. Nach der Umschaltung wird die echte Anwendung gegen den neuen Server getestet, nicht nur die Datenbank. Tut die Warenwirtschaft, was sie soll? Kommen die Auswertungen? Laufen die nächtlichen Jobs?
- Freigabe als GO/NO-GO-Tor. Der entscheidende Punkt zum Schluss: Der Test ist ein Freigabe-Tor, kein Test im Echtbetrieb. Solange auf dem neuen Server noch nicht produktiv geschrieben wurde, ist der Rückweg gratis. Man biegt den logischen Namen einfach zurück, und der alte Server ist unverändert maßgeblich. Bei einem Fehler verschiebt man auf das nächste Wochenende, passt den Ablauf an und probt erneut. Erst mit der Freigabe, wenn echte Nutzer auf dem neuen Server arbeiten, schließt sich dieser einfache Rückweg. Eine Migration, die diesen Unterschied nicht kennt, riskiert verlorene Daten bei einer vermeintlich harmlosen Rückrolle.
Der rote Faden durch alle Phasen: Eine gute Migration ist mehrfach geprobt und jederzeit zurückrollbar, bis zu dem einen klar definierten Moment der Freigabe.
Typische Fehler, die den Aufwand künstlich aufblähen
Diese Liste ist gleichzeitig deine Checkliste fürs Angebotsgespräch. Jeder Punkt darin ist ein vermeidbarer Kostentreiber.
- Den Servernamen erst beim Umzug abstrahieren wollen. Wer die DNS-Alias-Schicht nicht vorab einführt, macht jeden Umzug zur Handarbeit in fremden Konfigurationen. Das ist der teuerste und häufigste Fehler.
- Nur die Datenbank umziehen. Anmeldungen, Jobs und Fremdverbindungen liegen woanders. Werden sie vergessen, entstehen sie als Tickets am Montagmorgen, einzeln und teuer nachgereicht.
- Vorhanden mit funktioniert verwechseln. Eine reine Existenzprüfung übersieht nicht anmeldbare Logins und Fremdverbindungen, die zur Laufzeit brechen.
- Ohne Probefahrt direkt am Stichtag migrieren. Der erste echte Versuch ist dann zugleich der einzige, und jeder Fehler trifft die Produktion.
- Die Rückrolle als Allzeit-Notausgang missverstehen. Sie ist gratis vor der Freigabe und gefährlich danach.
- Auf einer Wegwerf-Testkiste statt dem echten Zielserver proben. Umgebungsspezifische Fehler, etwa beim Treiberverhalten oder bei Berechtigungen, zeigen sich nur auf der echten Hardware.
- Kopierte Hintergrund-Jobs während der Tests aktiv lassen. Ein versehentlich laufender Job kann echte Mails verschicken oder in produktive Fremdsysteme schreiben.
- Backups nie auf Rücksicherbarkeit testen. Ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung, kein Sicherungskonzept.
- Die Treiber- und Zertifikatsfalle bei neueren Versionen übersehen. SQL Server 2025 erzwingt bei Verbindungen standardmäßig eine Zertifikatsprüfung. Alte Fremdverbindungen, die das bisher nicht kannten, brechen nach dem Upgrade.
- Alles gleichzeitig migrieren wollen. Anwendung für Anwendung gestaffelt umzuziehen macht aus einem Großrisiko-Wochenende viele kleine, wiederholbare Einzelumzüge.
Wo deine Vorbereitung endet
Eine ehrliche Abgrenzung: Diesen Ablauf zu kennen, macht dich nicht zum Ausführenden. Die Werkzeuge dahinter sind frei verfügbar und mächtig, aber ein falscher Befehl auf einem Produktivsystem bleibt ein falscher Befehl. Die Ausführung gehört in die Hände von jemandem mit echter SQL-Server-Erfahrung, intern oder extern.
Dein Gewinn ist ein anderer: Du gehst informiert ins Angebotsgespräch. Du erkennst, ob ein Dienstleister methodisch arbeitet oder Stunden verkauft. Du fragst nach Probefahrt, nach der Behandlung von Anmeldungen und Fremdverbindungen, nach dem Rückweg. Und du nimmst „das sind eben drei Tage Handarbeit“ nicht mehr als Naturgesetz hin.
Was das für dich als Entscheider bedeutet
Wer den Ablauf vorab versteht, verschiebt die Verhandlungsposition. Statt einer Pauschale für ein riskantes Wochenende kannst du eine vorbereitete, mehrfach geprobte Migration verlangen, deren eigentliches Ausfallfenster Minuten beträgt, nicht Stunden. Die Vorbereitung kostet einmal Zeit. Danach wird jeder künftige Serverwechsel günstiger, weil das Fundament schon liegt.
Konkret heißt das: weniger Überraschungs-Tickets nach dem Umzug, ein kürzeres Wartungsfenster, eine faire statt aufgeblähte Schätzung und die Sicherheit, jederzeit zurückzukönnen, bis du freigibst. Eine Migration wird vom einmaligen Hochrisiko-Ereignis zur eingeübten Routine.
Wer den technischen Unterbau dazu sehen will, findet die beiden Bausteine ausführlich auf sesoft.de: die DNS-Alias-Schicht pro Anwendung und das Automatisierungswerkzeug dbatools.
Fazit
Der Aufwand einer SQL Server Migration ist keine Naturkonstante, sondern eine Folge der Methode. Vorbereitung, Probefahrt und ein klares Freigabe-Tor verwandeln ein riskantes Wochenende in einen geprobten, wiederholbaren Vorgang. Wer das vor dem Angebot weiß, zahlt für Ergebnis statt für Stunden.
Wenn du vor einer anstehenden Migration einmal unabhängig durchsprechen möchtest, welcher Aufwand realistisch ist und worauf du im Angebot achten solltest, sichere dir ein kostenloses Erstgespräch über sesoft.de/kostenloses-erstgespraech-sichern.
Quellen
- Microsoft Lifecycle, Ende des erweiterten Supports für SQL Server 2016 am 14. Juli 2026: SQLServerCentral
- Größenordnung typischer Migrationsdauern (einfach 2 bis 3 Monate, komplex länger) und Anteil produktiver SQL Server 2016 Instanzen: Northdoor, Red9 (als Schätzung gekennzeichnet)
- Zertifikatsprüfung und Brüche bei Fremdverbindungen beim Upgrade auf SQL Server 2025: Red9
Ü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. Er begleitet im norddeutschen Mittelstand SQL Server Migrationen und hilft IT-Verantwortlichen, Aufwände realistisch einzuschätzen, bevor externe Dienstleister sie ansetzen. Mehr über Sönke Schäfer und den Datenschäfer.
