Auf einem Server liegen das ERP, das Lagerverwaltungssystem, das CRM, ein paar gewachsene Access-Datenbanken und das Datenlager fürs Reporting. Der Server muss umziehen, weil die SQL-Server-Version aus dem Support fällt. Und jetzt schickt jeder dieser Lieferanten eine eigene Rechnung, braucht mehrere Wochen und macht es nacheinander. Irgendwann stellt sich die berechtigte Frage: Wofür bezahle ich das alles eigentlich?
Der Großteil der Rechnung ist Transport, kein Können
Ein Serverumzug besteht aus zwei sehr verschiedenen Dingen, die auf den Lieferantenrechnungen vermischt sind. Das eine ist der reine Transport: Daten von Server A nach Server B bewegen, dazu Anmeldungen, automatische Hintergrundläufe und Verbindungen zu anderen Systemen. Das andere ist Verantwortung: die Bestätigung, dass die Anwendung auf der neuen Plattform freigegeben und gewährleistet ist.
Der Transport ist heute Standardarbeit. Es gibt kostenfreie Werkzeuge, die genau das automatisieren, und Erfahrung, die den Ablauf sicher macht. Trotzdem wird er pro Lieferant in Tagen abgerechnet. Der Grund ist selten technische Schwierigkeit. Er ist fehlende Vorbereitung, abgerechnet nach Stunden.
Dazu kommt Reibung, für die niemand offen bezahlt, die aber jeder bezahlt: Fünf Lieferanten, die voneinander nichts wissen, koordinieren sich nicht. Jeder wartet, bis der vorige fertig ist. Aus fünf parallelen Aufgaben werden fünf nacheinander, und der Kalender füllt sich mit Wartezeit.
Warum der Servername die ganze Rechnung treibt
Die eigentliche Ursache für den Aufwand ist unscheinbar: Der physische Name des Servers steckt fest in jeder Anwendung, in ihren Verbindungseinstellungen. Zieht der Server um, ändert sich dieser Name, und jeder Lieferant muss in seinem System nachziehen. Genau das ist die Handarbeit, die Wochen frisst und nach Stunden abgerechnet wird.
Die Vorbereitung, die das auflöst, ist eine einmalige Sache. Jede Anwendung bekommt vorab einen logischen Namen, hinter dem der physische Server austauschbar wird. Diese Umstellung macht man einmal, im laufenden Betrieb, und zwar mit den Lieferanten, nicht gegen sie. Danach kennt keine Anwendung mehr den echten Servernamen. Ein künftiger Umzug ist dann eine zentrale Umschaltung, kein Eingriff in fünf fremde Systeme.
Wer diese Schicht einmal eingezogen hat, zahlt den Vorbereitungsaufwand genau einmal und spart ihn bei jedem weiteren Umzug. Und es wird weitere geben: Microsoft beendet den Support pro Version nach zehn Jahren, SQL Server 2016 fällt am 14. Juli 2026 aus dem erweiterten Support. Der nächste Umzug ist also keine Frage des Ob.
Was die Vorbereitung konkret leistet
Drei Schritte verschieben den Aufwand von den teuren Lieferantenstunden zu einer einmaligen, internen Vorbereitung.
- Erstens die logische Namensschicht für jede Anwendung, wie beschrieben. Das ist der größte Hebel, weil er den Servernamen aus allen Anwendungen herauslöst.
- Zweitens ein vorbereiteter und mehrfach geprobter Zielserver. Mit einem frei verfügbaren Automatisierungswerkzeug lässt sich der komplette Umzug auf den neuen Server durchspielen, während die echten Anwendungen ungestört weiterlaufen. So oft, bis er sitzt. Aus dem riskanten ersten Versuch am Stichtag wird ein eingeübter Ablauf.
- Drittens schrumpft damit die Rolle des Lieferanten auf das, was wirklich nur er liefern kann: die Freigabe-Bestätigung für seine Anwendung auf der neuen Plattform und eine Liste der anwendungsspezifischen Stellen, die die logische Namensschicht nicht erreicht. Das ist eine Frage von Stunden und einer Unterschrift, nicht von Wochen.
Den technischen Unterbau dieser Vorbereitung habe ich auf sesoft.de ausführlich dokumentiert: die logische Namensschicht pro Anwendung und den vollständigen Migrationsablauf von der Probefahrt bis zur Freigabe.
Die ehrliche Grenze: Transport kannst du übernehmen, Verantwortung nicht einseitig
Hier ist der Punkt, an dem das Argument seriös bleiben muss. Du kannst den Transport vorbereiten und weitgehend selbst übernehmen. Die Verantwortung kannst du dir nicht einfach nehmen.
Viele Verträge für ERP-, Lager- und CRM-Systeme enthalten eine Klausel, die den Betrieb nur auf einer vom Hersteller freigegebenen Plattform erlaubt. Ziehst du die ERP-Datenbank eigenmächtig auf eine neue Version, und das System produziert später einen Fehler, kann der Lieferant die Gewährleistung verweigern. Das ist kein technisches, sondern ein vertragliches Risiko, und es trifft das Unternehmen, nicht den Dienstleister. Die Frage lautet deshalb nicht „kann ich es“, sondern „darf ich es, ohne dass jemand seine Haftung loswird“.
Daraus folgt eine faire Aufteilung. Gewachsene Access-Datenbanken und das Datenlager sind in der Regel deine eigene Domäne, hier brauchst du niemanden. Beim CRM lohnt der Blick in den Vertrag, oft ist es unkritisch. Bei ERP und Lagerverwaltung sitzt das Gewährleistungsrisiko, und ein vorsichtiger Geschäftsführer wird den Lieferanten den letzten Knopf drücken lassen wollen, schlicht um die Haftung dort zu halten. Das ist legitim. Auch dann sinkt die Rechnung, weil die Vorbereitung den Lieferantenaufwand von Wochen auf Stunden drückt.
Was das für dich als Entscheider bedeutet
Die Vorbereitung verschiebt deine Verhandlungsposition. Statt „macht mal und schickt die Rechnung“ sagst du dem Lieferanten: Der Server ist vorbereitet, die Namensschicht steht, das Ziel ist getestet, ich brauche von euch die Freigabe und die Liste der Stellen, die nur ihr kennt. Aus einer offenen Stundenabrechnung wird eine begrenzte, definierte Leistung.
Wirtschaftlich heißt das dreierlei. Die Koordinationswochen zwischen Lieferanten, die voneinander nichts wissen, fallen weg, weil die Vorbereitung zentral passiert. Der eigentliche Umzug schrumpft auf ein kurzes Fenster pro Anwendung statt eines langen Wochenendes. Und die Vorbereitung zahlt sich bei jedem künftigen Versionswechsel erneut aus, weil das Fundament dann schon liegt.
Der Satz, der bleibt: Den Umzug macht die Vorbereitung. Die Lieferanten brauchst du am Ende für die Unterschrift, nicht für den Transport.
Fazit
Eine SQL Server Migration ist nicht teuer, weil sie schwer ist, sondern weil sie selten vorbereitet wird. Wer die logische Namensschicht vorab einzieht und den Zielserver geprobt bereitstellt, trennt den Transport von der Verantwortung. Den Transport kannst du mit Erfahrung und Werkzeug günstig vorbereiten. Für die Verantwortung zahlst du dann gezielt, statt sie in Wochen ungeprüfter Stunden mitzukaufen.
Wenn du vor einer anstehenden Migration einmal unabhängig durchsprechen möchtest, was sich vorbereiten lässt und wofür du die Lieferanten wirklich noch brauchst, 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
Ü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 bereitet im norddeutschen Mittelstand Serverumzüge so vor, dass Software-Lieferanten nur noch das tun müssen, was wirklich nur sie können, und begleitet Unternehmen dabei, Bestandssysteme pragmatisch weiterzuführen statt teuer abzulösen; mehr über Sönke Schäfer SeSoft GmbH Web/Database/Solutions.
