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 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 ausdrücklich, Domain Controller nicht per In-Place Upgrade zu migrieren. Für Active Directory Domain Services gibt es einen separaten, kontrollierten Migrationspfad. Dieser Artikel gilt für Member-Server, File-Server, Anwendungsserver und vergleichbare Rollen.

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: TPM 2.0 ist für das Basis-Upgrade nicht zwingend erforderlich – aber für Secured-Core Server, Credential Guard und andere moderne Sicherheitsfeatures von Windows Server 2025 ist es Voraussetzung. Server, die mit Windows Server 2016 eingeführt wurden, sind typischerweise 7 bis 10 Jahre alt. Viele dieser Systeme haben kein TPM 2.0 oder nutzen noch Legacy BIOS statt UEFI. Das Upgrade ist technisch möglich – aber die modernen Security-Features bleiben dann ungenutzt. In diesem Fall ist ein Hardware-Refresh die strategisch sinnvollere Entscheidung.

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/Setup ist für nicht-geclusterte Server. Für Cluster-Umgebungen gibt es den Cluster-Aware Updating-Prozess.
• 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.

Praxis-Hinweis aus der Praxis: Bei einigen Windows Server 2016-Systemen muss setup.exe unter dem SYSTEM-Konto ausgeführt werden, damit das Upgrade korrekt initiiert wird. Falls der reguläre Start fehlschlägt, kann das Setup über PsExec als SYSTEM-Prozess gestartet werden:

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 enthält. Über die Windows-Einstellungen (Einstellungen → System → Wiederherstellung) kann innerhalb von 10 Tagen nach dem Upgrade auf die vorherige Version zurückgewechselt werden.

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 alter Hardware ohne TPM 2.0 (Hardware-Refresh sinnvoller)
• 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.