Windows Server 2016 → 2025: Der direkte Upgrade-Pfad

 Lange war es nicht möglich: Ein direktes Upgrade von Windows Server 2016 auf Windows Server 2025 – ohne den Umweg über 2019 oder 2022 – galt als nicht offiziell unterstützter Pfad. Das hat sich geändert. Microsoft dokumentiert seit dem Release von Windows Server 2025 ausdrücklich, dass ein In-Place Upgrade direkt von Windows Server 2016 auf Windows Server 2025 ausschließlich auf media-based feature Updates für nicht geclusterte Systeme unterstützt wird. Für viele IT-Teams ist das eine erhebliche Vereinfachung gegenüber dem bisher üblichen Stufenmodell.

Was das In-Place Upgrade leisten kann: Es ersetzt die Betriebssystem-Dateien auf dem laufenden Server, während Einstellungen, Server-Rollen, installierte Anwendungen und Daten erhalten bleiben. Was es nicht leisten kann: Es ist kein Allheilmittel. Es gibt klare Voraussetzungen, bekannte Stolpersteine und Szenarien, in denen eine Side-by-Side-Migration die bessere Wahl ist.

Dieser Artikel liefert die vollständige technische Grundlage – von den Voraussetzungen über die Schritt-für-Schritt-Durchführung bis zur Rollback-Strategie.

Wichtiger Hinweis vorab: Microsoft empfiehlt bevorzugt für Domain Controller eine Neuinstallation mit Promotion neuer DCs und anschließender Demotion alter DCs. Ein In-Place Upgrade eines DC ist jedoch laut aktueller Microsoft-Dokumentation grundsätzlich auch möglich, sofern die AD-Voraussetzungen erfüllt sind.
 

Voraussetzungen: Was vor dem ersten Klick geklärt sein muss

Ein In-Place Upgrade, das auf einem unvorbereiteten System gestartet wird, ist ein Risiko. Die folgenden Voraussetzungen sind keine Empfehlungen – sie sind Pflicht.

Hardware: Was Windows Server 2025 mindestens braucht

Windows Server 2025 stellt folgende Mindestanforderungen an die Hardware:

Zur TPM-2.0-Frage: Für die Installation von Windows Server 2025 sind UEFI und Secure Boot als Grundvoraussetzungen definiert. TPM 2.0 ist keine generelle Installationsvoraussetzung, wird jedoch für spezifische Sicherheitsfunktionen benötigt: Secured-Core Server, Credential Guard und vergleichbare moderne Security-Features setzen TPM 2.0 voraus – ebenso wie in der Regel eine UEFI-Umgebung.

Auf Feature-Ebene bedeutet das: Server, die mit Windows Server 2016 eingeführt wurden, sind heute typischerweise sieben bis zehn Jahre alt. Viele dieser Systeme verfügen weder über TPM 2.0 noch über UEFI. Ein Upgrade auf Windows Server 2025 ist auf solcher Hardware technisch möglich – die genannten Sicherheitsfunktionen stehen dann jedoch nicht zur Verfügung.

Aus architektonischer Sicht empfiehlt sich in diesem Fall ein Hardware-Refresh. Wer langfristig von den modernen Security-Features profitieren möchte, sollte die Hardwareentscheidung nicht losgelöst von der Betriebssystemstrategie treffen.

Praxis-Check: Vor dem Upgrade prüfen, ob ausreichend freier Speicherplatz auf dem Systemlaufwerk vorhanden ist. Das Setup benötigt temporär deutlich mehr als die 32 GB Minimum – in der Praxis sollten mindestens 20 GB freier Speicher auf dem Systemlaufwerk verfügbar sein.

Software: Patchstand und Kompatibilität

• Aktueller Patchstand: Der Server sollte vor dem Upgrade vollständig mit den aktuellen kumulativen Updates versorgt sein. Ein veralteter Patchstand ist eine der häufigsten Ursachen für Upgrade-Fehler.
• Anwendungskompatibilität: Welche Anwendungen laufen auf dem Server? Unterstützen deren Hersteller Windows Server 2025? Besonders kritisch: ältere SQL-Server-Versionen (2012/2014 sind nicht kompatibel), .NET-Framework-Abhängigkeiten und proprietäre Treiber.
• Keine Cluster-Umgebung:  Das In-Place Upgrade über ISO und Setup ist ausschließlich für nicht-geclusterte Server vorgesehen. Für Failover-Cluster gilt ein anderer Migrationspfad: Das Cluster OS Rolling Upgrade ermöglicht ein knotenweises Upgrade des Betriebssystems bei laufendem Clusterbetrieb. Dabei ist zu beachten, dass jeweils nur ein Versionsschritt unterstützt wird – also etwa von Windows Server 2022 auf 2025. Ein direktes Upgrade von Windows Server 2016 auf 2025 ist im Cluster-Kontext nicht als einzelner Schritt vorgesehen; hier ist ein mehrstufiges Rolling Upgrade erforderlich.  
• Kein Active Directory Domain Services: Domain Controller werden separat migriert – nicht per In-Place Upgrade.  

Backup: Ohne vollständiges Backup kein Upgrade-Start

Das ist keine Floskel. Ein In-Place Upgrade ist ein tiefer Eingriff in das laufende System. Wenn etwas schiefgeht – und das kann passieren – ist ein vollständiges, getestetes Backup die einzige zuverlässige Rückfalloption.

Das Backup muss umfassen:

• System State Backup (Betriebssystem, Konfiguration, Rollen)
• Image-basiertes Vollbackup des Systemlaufwerks
• Daten-Backup aller relevanten Volumes
• Konfigurationsdokumentation (IP-Adressen, Dienste, installierte Rollen)

Und: Den Restore testen, bevor das Upgrade startet. Ein Backup, dessen Wiederherstellbarkeit nicht verifiziert wurde, ist im Ernstfall wertlos.

Schritt-für-Schritt-Anleitung: In-Place Upgrade von Windows Server 2016 auf 2025

Schritt 1: Pre-Upgrade-Diagnose – Systemzustand dokumentieren

Bevor das Setup gestartet wird, sollte der aktuelle Systemzustand vollständig dokumentiert werden. Diese Informationen sind unverzichtbar, wenn das Upgrade fehlschlägt und eine Fehleranalyse notwendig wird.

Diagnose-Daten sammeln – in einer erhöhten PowerShell-Sitzung:

Die exportierten Dateien auf einem externen Speicherort sichern (USB-Stick, Netzwerkfreigabe) – nicht nur lokal auf dem Server.

Zusätzlich prüfen:

• Installierte Rollen und Features: Get-WindowsFeature | Where-Object {$_.InstallState -eq "Installed"}
• Laufende Dienste: Get-Service | Where-Object {$_.Status -eq "Running"}
• Freier Speicherplatz: Get-PSDrive C
• Event-Log auf bestehende Fehler: Ereignisanzeige → Windows-Protokolle → System/Anwendung (letzte 7 Tage)

Bestehende Fehler im Event-Log sollten vor dem Upgrade behoben werden. Ein System, das bereits Probleme hat, wird diese nach dem Upgrade mit hoher Wahrscheinlichkeit weiterhin haben – oder neue dazubekommen.

Schritt 2: Backup erstellen und verifizieren

Vollständiges Image-Backup des Servers erstellen – vor dem nächsten Schritt. Empfohlene Tools: Veeam Backup & Replication, Windows Server Backup (integriert), oder das Backup-Tool Ihrer Wahl.

Kritisch: Laufende VMs auf dem Server herunterfahren oder migrieren. Das Setup empfiehlt, während des Upgrades keine VMs auf dem Host laufen zu lassen.

Backup-Verifikation: Einen Test-Restore in einer isolierten Umgebung durchführen oder zumindest die Integrität der Backup-Dateien prüfen.

Schritt 3: Windows Server 2025 ISO mounten und Setup starten

ISO beschaffen: Das Windows Server 2025 ISO über das Microsoft 365 Admin Center, ein Visual Studio-Abonnement oder den OEM-/Volumenlizenz-Kanal beziehen.

ISO mounten: In Windows Server 2016 direkt per Doppelklick auf die ISO-Datei oder über den Hyper-V Manager. Das ISO wird als Laufwerk eingebunden.

Setup starten: Im Stammverzeichnis des gemounteten Laufwerks setup.exe ausführen.

Im Setup-Dialog:

• Updates für die Installation: Standardmäßig lädt Setup automatisch Updates herunter – empfohlen, sofern Internetverbindung vorhanden.
• Product Key eingeben (falls erforderlich).
• Edition auswählen: Standard oder Datacenter – muss der bestehenden Lizenz entsprechen.
• Lizenzbedingungen akzeptieren.
• „Dateien, Einstellungen und Apps beibehalten" auswählen – das ist der In-Place Upgrade-Modus. Nicht „Nichts" wählen, das wäre eine Neuinstallation.
• „Installieren" starten.

Schritt 4: Upgrade durchführen

Der Upgrade-Prozess läuft weitgehend automatisch. Der Server startet während des Prozesses mehrfach neu – das ist normal und erwartet. Typische Gesamtdauer: 1 bis 3 Stunden, abhängig von Hardware-Geschwindigkeit, Anzahl der installierten Rollen und Datenmenge.

Während des Upgrades:

• Nicht manuell eingreifen oder den Server neu starten
• Keine anderen Aktivitäten auf dem Server
• Fortschritt wird auf dem Bildschirm angezeigt (Prozentanzeige)

Falls das Upgrade abbricht und der Server in einen Wiederherstellungsmodus startet: Nicht in Panik geraten. Windows versucht in diesem Fall automatisch, den vorherigen Zustand wiederherzustellen. Die Setup-Logs unter C:\Windows\Panther\ liefern die Fehlerursache.

Schritt 5: Post-Upgrade-Check – Systemzustand verifizieren

Nach dem abschließenden Neustart: Systemzustand systematisch prüfen, bevor der Server wieder in den Produktivbetrieb geht.

Betriebssystem-Version verifizieren:

Checkliste Post-Upgrade:

Setup-Logs analysieren (bei Auffälligkeiten): C:\Windows\Panther\ – hier liegen die detaillierten Upgrade-Protokolle. Das Tool SetupDiag von Microsoft kann diese automatisch auswerten.

Schritt 6: Monitoring – Die ersten 48 Stunden sind entscheidend

Die ersten 48 Stunden nach dem Upgrade sind die kritischste Phase. Probleme, die sich nicht sofort zeigen, treten oft beim ersten vollständigen Arbeitszyklus auf: nach dem ersten Wochenende, nach dem ersten Monatsabschluss, nach dem ersten Backup-Durchlauf.

Monitoring-Maßnahmen:

• Event-Log kontinuierlich beobachten (Warnungen und Fehler)
• Performance-Monitoring: CPU, RAM, Disk I/O, Netzwerk – Vergleich mit Baseline-Werten vor dem Upgrade
• Anwendungs-Monitoring: Sind alle Dienste stabil? Gibt es unerwartete Neustarts?
• Benutzer-Feedback aktiv einholen: Gibt es Probleme mit Anwendungen, Druckern, Netzlaufwerken?

Erst wenn die ersten 48 Stunden stabil verlaufen sind, kann der Server als erfolgreich migriert gelten.

Typische Probleme nach dem Upgrade – und wie man sie löst

Problem 1: Treiber fehlen oder funktionieren nicht

Symptom: Geräte-Manager zeigt unbekannte Geräte oder Warnzeichen. Netzwerkkarte, RAID-Controller oder Storage-Adapter werden nicht korrekt erkannt.

Ursache: Windows Server 2025 bringt aktualisierte Treiber-Signaturen mit. Ältere OEM-Treiber, die für Windows Server 2016 entwickelt wurden, sind nicht immer kompatibel.

Lösung:

• Hersteller-Website des Server-Herstellers aufrufen (HPE, Dell, Lenovo, Fujitsu etc.)
• Treiber-Downloads für Windows Server 2025 suchen – viele Hersteller haben dedizierte Treiberpakete für den neuen OS-Stand
• Treiber installieren, Server neu starten
• Bei RAID-Controllern besonders sorgfältig vorgehen: Treiber-Update vor dem Neustart vollständig abschließen

Vorbeugung: Treiber-Kompatibilität bereits in der Testumgebung prüfen, bevor das Produktivsystem angefasst wird.

Problem 2: Dienste starten nach dem Upgrade nicht

Symptom: Einzelne oder mehrere Dienste starten nach dem Upgrade nicht. Im Event-Log erscheinen Fehler wie Ereignis-ID 7000 (Dienst konnte nicht gestartet werden) oder 7001 (Abhängigkeit nicht erfüllt).

Ursache: Häufige Ursachen sind geänderte Dienstkonten-Berechtigungen, fehlende Abhängigkeiten nach dem OS-Wechsel oder Kompatibilitätsprobleme mit Anwendungen.

Lösung:

• Event-Log analysieren: Ereignisanzeige → Windows-Protokolle → System → nach Ereignis-IDs 7000, 7001, 7009 filtern

• Dienst-Abhängigkeiten prüfen: sc qc [Dienstname] zeigt Abhängigkeiten an

• Dienstkonto-Berechtigungen prüfen: Läuft der Dienst unter einem Domänenkonto? Ist das Konto noch aktiv und hat die notwendigen Berechtigungen?

• Verzögerter Start als Workaround: Bei Diensten, die Netzwerk-Abhängigkeiten haben und zu früh starten, kann ein verzögerter automatischer Start das Problem lösen: sc config [Dienstname] start= delayed-auto

Problem 3: Netzwerk funktioniert nach dem Upgrade nicht korrekt

Symptom: Netzwerkkarte wird erkannt, aber die IP-Konfiguration ist verloren gegangen oder der Server ist nicht erreichbar. Bei VMware-Umgebungen: Netzwerk steht nach dem Neustart nicht sofort bereit.

Ursache: Bei physischen Servern oft ein Treiber-Problem (siehe Problem 1). Bei virtuellen Maschinen unter VMware kann ein bekanntes Problem mit dem Netzwerkadapter-Treiber dazu führen, dass das Netzwerk beim Booten noch nicht bereit ist, wenn feste IP-Adressen verwendet werden.

Lösung:

• IP-Konfiguration manuell neu setzen: netsh interface ip set address oder über die Netzwerkeinstellungen
• DNS-Cache leeren: ipconfig /flushdns
• Netzwerkadapter zurücksetzen: netsh winsock reset + Neustart
• VMware-Umgebungen: „Wait For Link"-Einstellung im Netzwerkadapter-Treiber aktivieren, damit der Treiber nicht zu früh meldet, das Netzwerk sei bereit. VMware Tools auf die aktuelle Version aktualisieren.
• IP-Konfiguration dokumentieren: Vor dem Upgrade die vollständige Netzwerkkonfiguration mit ipconfig /all exportieren und sichern – dann ist die Wiederherstellung in wenigen Minuten möglich.

Rollback-Strategie: Was tun, wenn das Upgrade fehlschlägt?

Option 1: Windows.old-Ordner (10-Tage-Fenster)

Das Windows-Setup legt beim In-Place Upgrade automatisch einen Windows.old-Ordner an, der die vorherige Installation sichert. Ein Rollback über diesen Mechanismus ist technisch möglich, jedoch für produktive Serverumgebungen keine belastbare Rückfallstrategie. Die empfohlene Vorgehensweise ist ein geprüftes System- oder Image-Backup vor dem Upgrade – bei virtualisierten Umgebungen ergänzt durch einen konsistent vorbereiteten Snapshot- oder Restore-Prozess. Nur auf dieser Grundlage lässt sich im Fehlerfall ein kontrollierter und vollständiger Rollback sicherstellen.

Wichtig: Dieser Mechanismus funktioniert nur, wenn das Upgrade technisch abgeschlossen wurde und der Server bootet. Bei einem abgebrochenen Upgrade, das den Server unbootbar hinterlässt, hilft Windows.old nicht.

Nach 10 Tagen löscht Windows den Windows.old-Ordner automatisch, um Speicherplatz freizugeben. Wer den Rollback-Zeitraum verlängern möchte, kann die automatische Bereinigung deaktivieren.

Option 2: Backup zurückspielen

Die zuverlässigere und universell einsetzbare Rollback-Option: Das vollständige Image-Backup, das vor dem Upgrade erstellt wurde, zurückspielen.

Dieser Weg funktioniert unabhängig davon, in welchem Zustand sich das System nach dem Upgrade befindet – auch wenn der Server nicht mehr bootet. Voraussetzung: Das Backup ist vollständig, getestet und auf einem externen Speicherort verfügbar.

Empfehlung aus der Praxis: Den Rollback-Plan vor dem Upgrade einmal gedanklich durchspielen. Wie lange dauert der Restore? Wer führt ihn durch? Welche Systeme sind davon abhängig? Diese Fragen sollten vor dem Upgrade-Start beantwortet sein – nicht während eines Notfalls.

Fazit: In-Place Upgrade – wann ja, wann nein?

Das direkte In-Place Upgrade von Windows Server 2016 auf Windows Server 2025 ist ein legitimer und offiziell unterstützter Migrationspfad – für die richtigen Szenarien. Es spart Zeit, reduziert Komplexität und ist besonders für virtuelle Maschinen und einfachere Server-Rollen gut geeignet.

Es ist nicht die richtige Wahl für:

• Domain Controller (separater AD-Migrationspfad)
• Cluster-Umgebungen (Cluster-Aware Updating)
•  Server mit unklarer Hardware- und Treiberunterstützung oder fehlenden Sicherheitsvoraussetzungen wie UEFI und TPM 2.0 – in diesen Fällen empfiehlt sich eine kritische Prüfung von Supportstatus, Firmware-Stand und Treiberlage; ein Hardware-Refresh ist dann häufig die sinnvollere Entscheidung
  
• Komplexe Anwendungsserver mit ungeklärter Kompatibilität (Side-by-Side-Migration sicherer)

Wer unsicher ist, welcher Migrationspfad für die eigene Umgebung der richtige ist, sollte die Entscheidung nicht auf Basis eines Blog-Artikels treffen – sondern auf Basis einer strukturierten Bestandsaufnahme.