Alte Server müssen irgendwann weg. Windows Server 2012 R2 ist schon lange aus dem Support, 2016 ist seit Januar 2027 am Ende der Extended Security, und Hardware, die vor acht oder zehn Jahren angeschafft wurde, ist heute nicht nur ineffizient, sondern auch sicherheitstechnisch bedenklich. Trotzdem zögern viele Unternehmen eine Migration so lange wie irgend möglich hinaus.

Der Grund ist fast immer der gleiche: Die Angst, dass etwas schiefgeht. Dass der Buchhaltungsserver nach dem Umzug nicht mehr läuft, dass plötzlich Mails verschwinden, dass niemand mehr auf die Laufwerke zugreifen kann. Diese Sorge ist berechtigt – aber sie ist keine Begründung, es zu lassen. Sie ist eine Begründung, es sorgfältig zu machen.

Die folgenden Phasen bilden den Rahmen, in dem bei mir fast alle Server-Migrationen ablaufen, egal ob es um fünf Server oder fünfzig geht.

Phase 1: Inventur – Was ist da? Was läuft noch?

Die erste Phase ist die unspektakulärste und gleichzeitig die wichtigste. Bevor irgendeine Hardware bestellt wird, muss klar sein, was überhaupt im Serverraum steht.

In der Inventur-Phase entsteht eine vollständige Liste:

  • Alle Server mit Hardware-Daten, Betriebssystem-Version, Patchstand, Rollen und Diensten
  • Alle virtuellen Maschinen mit zugewiesenen Ressourcen, IP-Adressen, Funktionen
  • Alle installierten Anwendungen mit Hersteller, Version, Support-Status, Lizenz-Informationen
  • Alle Dienste, die auf anderen Systemen laufen (Datenbanken, Drucker-Server, Lizenzserver)
  • Alle Dateifreigaben mit Pfaden, Größen, Berechtigungen
  • Alle Client-Verbindungen, die auf die Server zeigen

In einem größeren Migrationsprojekt, das ich vor einiger Zeit begleitet habe (ca. 180.000 € Gesamtvolumen, inklusive Hardware und Arbeit), kam bei der Inventur heraus: Von 17 virtuellen Maschinen auf dem alten Cluster wurden drei seit über zwei Jahren von niemandem mehr genutzt – aber niemand hatte sie ausgeschaltet. Eine vierte lief nur noch für eine Anwendung, die das Unternehmen vor drei Jahren abgelöst hatte. Allein diese Erkenntnis hat die neue Hardware deutlich kleiner dimensionieren lassen.

Phase 2: Ziel-Architektur entwerfen

Sobald klar ist, was es gibt, wird entworfen, was es sein soll. Dabei geht es nicht nur um Hardware, sondern auch um die Frage: Welche Dienste verdienen überhaupt eine eigene VM? Welche lassen sich zusammenlegen? Welche sollten eher in die Cloud wandern?

Typische Architektur-Entscheidungen bei mittelständischen Migrationen:

  • Exchange-Server → Microsoft 365 oder Hybrid
  • Datei-Server bleibt On-Premise, aber mit DFS-Namespaces für zukünftige Flexibilität
  • Backup auf Veeam mit Immutable Storage (Cloud oder Off-Site-NAS)
  • Zwei Domain Controller, jeweils auf einem anderen Hyper-V-Host
  • Dedizierte Management-VM für Updates, Monitoring, PowerShell-Automation
  • Neue Firewall und Core-Switch, sofern das bisherige Equipment 10 Gbit nicht beherrscht

Am Ende dieser Phase steht ein Dokument: Netzwerk-Topologie, VM-Plan, IP-Schema, Host-Konfiguration, Lizenz-Liste, Kostenübersicht. Dieses Dokument ist die Grundlage für die Beschaffung.

Phase 3: Neue Hardware aufsetzen und testen

Während die alte Umgebung weiterläuft, wird die neue parallel aufgebaut. Meistens dauert diese Phase vier bis acht Wochen:

  • Hardware wird ausgepackt, ins Rack montiert, verkabelt. Entweder vor Ort beim Kunden oder im Rechenzentrum, je nach Zielumgebung.
  • Hyper-V-Hosts installiert und gehärtet. Standard-Patching, Firewall-Regeln, Admin-Accounts eingerichtet.
  • Netzwerk-Segmentierung konfiguriert. VLANs, Trunk-Ports, Firewall-Regelwerk getestet.
  • Erste VMs ausgerollt. Neue Domain Controller, neuer Fileserver, neuer Applikations-Server – alles noch in einem isolierten Subnetz.
  • Monitoring aktiviert. Zabbix, PRTG oder Veeam ONE laufen, damit man die neue Umgebung von Anfang an im Blick hat.

Phase 4: Daten-Synchronisation

Die neue Umgebung ist da, aber noch leer. Jetzt werden die Daten schrittweise synchronisiert. Wichtig: Das ist kein einmaliger Vorgang, sondern läuft über Wochen.

Die gängigen Werkzeuge für diese Phase:

  • Active Directory: Die neuen DCs werden einfach als zusätzliche DCs in die bestehende Domain aufgenommen. Replikation läuft automatisch. Erst beim Go-Live werden die alten DCs abgelöst.
  • Dateiserver: robocopy /MIR mit Delta-Updates, meistens nachts laufend. Am Umstellungstag läuft nur noch ein letzter kurzer Sync.
  • DFS-Replikation zwischen altem und neuem Fileserver, damit Anwender noch während des Umbaus weiterarbeiten können.
  • Exchange: Hybrid-Deployment mit Move-Requests. Postfächer werden einzeln oder in Batches verschoben, User merken praktisch nichts davon.
  • SQL-Datenbanken: Log-Shipping oder Always-On-Availability-Groups, damit die finale Umstellung nur Minuten dauert.
  • Virtuelle Maschinen: Wenn die alte Umgebung VMware war und die neue Hyper-V ist, kommt Veeam oder Microsoft Virtual Machine Converter zum Einsatz. Bei Hyper-V zu Hyper-V ist es eine Live Migration oder Export/Import.

Phase 5: Testläufe mit echten Benutzern

Bevor die komplette Belegschaft umgestellt wird, wandern zwei bis fünf Test-User auf die neue Umgebung. Idealerweise aus verschiedenen Abteilungen, damit möglichst viele Anwendungs-Szenarien abgedeckt sind.

In dieser Phase zeigen sich die Kleinigkeiten, die in der Planung übersehen wurden: Drucker-Treiber, die auf dem neuen Server anders heißen. Branchen-Anwendungen, die ihre Lizenz an die MAC-Adresse binden. Netzlaufwerke, die im Login-Skript fest verdrahtet waren. Solche Dinge findet man nicht am Reißbrett, sondern nur im echten Betrieb.

Diese Test-Phase dauert mindestens eine, besser zwei Wochen. Erst wenn die Test-User stabil arbeiten, wird die große Umstellung geplant.

Phase 6: Der Cutover – das lange Wochenende

Die eigentliche Umstellung findet an einem verlängerten Wochenende statt, meistens mit einem zusätzlichen Brückentag. Typischer Ablauf bei einem mittelständischen Unternehmen:

  • Freitag, 16:00: Letzte Mitarbeiter gehen aus dem System. Alle offenen Dateien werden explizit geschlossen (mit einer freundlichen Rundmail zwei Stunden vorher).
  • Freitag, 17:00: Finale Daten-Synchronisation. robocopy läuft nochmal, dieses Mal ohne Delta. Exchange-Move-Requests für die letzten Postfächer werden angestoßen.
  • Samstag, vormittags: Alte Dateiserver werden heruntergefahren. Neuer Fileserver übernimmt die DNS-Aliase. DFS-Pfade sind jetzt die produktiven Pfade.
  • Samstag, nachmittags: Test mit zwei bis drei Mitarbeitern, die extra dafür ins Büro kommen. Typische Arbeitsabläufe werden durchgespielt, Probleme werden sofort behoben.
  • Sonntag: Pufferzeit für Stabilisierung, letzte Anpassungen, Dokumentation.
  • Montag, 06:30: Ich bin vor Ort beim Kunden, bevor die ersten Mitarbeiter kommen. Mein Kollege sitzt parallel am Telefon bereit.
  • Montag, 07:00 bis 17:00: Vor-Ort-Support. Jede Frage, jedes Problem wird sofort geklärt. Das ist für die Akzeptanz der neuen Umgebung entscheidend.

Phase 7: Nachbetreuung und Abbau der alten Umgebung

Die alte Hardware bleibt nach dem Umzug mindestens zwei Wochen im Standby. Sie wird nicht abgebaut, nicht gelöscht, sondern nur heruntergefahren. Falls wirklich irgendetwas auftaucht, was wir übersehen haben, kann man sie binnen einer Stunde wieder hochfahren.

Erst nach einem Monat stabilen Betriebs auf dem neuen System:

  • Alte Domain Controller werden sauber aus der Domain entfernt (dcpromo bzw. Uninstall-ADDSDomainController).
  • Alte Fileserver werden auf den Datenstand „eingefroren", archiviert, dann gelöscht.
  • Alte Hyper-V-Hosts werden abgebaut – oder, was ich lieber mache, als Test- und Lab-Umgebung weiter verwendet.
  • Alte Backups werden mindestens ein Jahr zusätzlich aufbewahrt, idealerweise so lange, wie gesetzliche Aufbewahrungsfristen reichen.

Typische Fallstricke

Auch bei bester Planung gibt es Dinge, die regelmäßig zu Problemen führen:

  • Branchen-Software, die sich weigert umzuziehen. Manche Fachanwendungen verknüpfen sich mit Hardware-Seriennummern, MAC-Adressen oder festen Pfaden. Lösung: Vor der Migration mit dem Hersteller Kontakt aufnehmen und Lizenz-Wechsel oder Server-Umzug rechtzeitig vorbereiten.
  • Veraltete Telefonanlagen, die per ISDN oder proprietärer Schnittstelle am alten Server hängen. Die kommen oft in der Inventur nicht vor und tauchen erst beim Abschalten auf. Lösung: Frühzeitig alle Server-Peripherie durchgehen.
  • Drucker, Scanner, Kassensysteme. Alles, was per IP oder SMB-Share am alten Server hängt, muss umgebogen werden. Vor der Migration alle Endgeräte im Netz durchleuchten.
  • User mit lokalen Berechtigungen. Manche Mitarbeiter haben im Laufe der Jahre lokale Admin-Rechte oder Sondergruppen bekommen. Die gehen bei der Migration standardmäßig nicht mit. Lösung: Checkliste pro Mitarbeiter.
  • DNS-Caching. Nach der Umstellung kann es sein, dass Clients oder interne Router die alten IP-Adressen noch im Cache haben. Lösung: ipconfig /flushdns per GPO oder Neustart der Clients.

Fazit

Eine gut vorbereitete Server-Migration ist für den Anwender am Montagmorgen nicht unterscheidbar von einem normalen Arbeitstag. Die Mitarbeiter setzen sich an ihre Rechner, loggen sich ein, öffnen ihre Dateien, und alles ist wie immer – nur schneller. Die Migration hat erfolgreich stattgefunden, und niemand hat es bemerkt.

Das ist das Ziel. Und es ist erreichbar, wenn man sich die Zeit nimmt, die Phasen sauber durchzuarbeiten und keine Abkürzungen versucht.

Wenn Sie eine Migration vor sich haben und nicht sicher sind, wo Sie anfangen sollen: Melden Sie sich. Ich schaue mir die aktuelle Umgebung an und sage Ihnen ehrlich, was realistisch machbar ist – und was Sie besser nicht selber angehen sollten.