Was ein belastbares Windows-11-Migrationsassessment prüfen muss

Warum eine Kompatibilitätsliste nicht genügt

Viele Migrationsvorhaben beginnen mit einer Exportdatei: Gerät, Modell, Arbeitsspeicher, freier Speicher und ein technisches Readiness-Merkmal. Das ist nützlich, aber noch kein Assessment. Die Liste sagt wenig darüber aus, ob ein Mitarbeiter nach der Migration seine Fachanwendung starten kann, ob das Gerät den richtigen Treiber erhält, ob eine Policy den vorgesehenen Zustand wieder verändert oder ob der Service Desk einen fehlgeschlagenen Ablauf diagnostizieren kann.

Ein Assessment muss deshalb eine betriebliche Frage beantworten: Unter welchen bekannten Bedingungen kann welche Gruppe migriert werden, und was geschieht, wenn eine dieser Bedingungen nicht erfüllt ist? Die Antwort verbindet technische Evidenz mit Entscheidungen. Ein grünes Gerät ohne freigegebene Anwendung ist kein freigegebener Client. Eine getestete Anwendung ohne reproduzierbaren Installationsweg ist kein belastbarer Rollout-Baustein.

1. Die Gerätebasis belastbar machen

Die Geräteübersicht ist der erste Prüfbereich, nicht das Endergebnis. Benötigt werden Modell, Generation, Firmware- und Treiberstand, Speicher, Verschlüsselungszustand, Anschlussgeräte und der tatsächliche Managementstatus. Dubletten, veraltete Datensätze und Geräte ohne aktuellen Kontakt müssen gekennzeichnet werden. Andernfalls wird die vermeintliche Zielmenge schon vor dem Pilot unzuverlässig.

Entscheidend ist die Bildung sinnvoller Gerätekategorien. Zwanzig Modellbezeichnungen können auf wenige technische Familien hinauslaufen – oder umgekehrt Varianten enthalten, die verschiedene Netzwerk-, Grafik- oder Speichertreiber benötigen. Für jede Kategorie braucht es ein repräsentatives Testgerät. Die anonymisierte Referenz Eine Task Sequence für zwanzig Hardwaretypen zeigt, wie ein gemeinsamer Blueprint und modellbezogene Bedingungen zusammenpassen.

Peripherie darf nicht als Randthema verschwinden. Dockingstationen, Spezialscanner, Kartenleser, Drucker oder Messgeräte können für kleine Nutzergruppen geschäftskritisch sein. Das Assessment ordnet solche Geräte einem fachlichen Owner, einem Testfall und einer Entscheidung zu. „Wird selten genutzt“ ist keine technische Bewertung.

2. Anwendungen nach Risiko statt Lautstärke ordnen

Eine reine Anwendungsliste führt schnell zu hunderten gleich aussehenden Zeilen. Für die Priorisierung sind mindestens Reichweite, fachliche Kritikalität, Installationskomplexität, Herstellerstatus, technische Abhängigkeiten und verantwortlicher Owner nötig. Besonders früh geprüft werden Anwendungen, die viele Geräte betreffen, den Geschäftsprozess direkt tragen oder mit Treibern, Browser-Komponenten, Datenbanken, Office-Integrationen und Session-Umgebungen verbunden sind.

Die Prüfung hat zwei Ebenen. Erstens: Läuft die Anwendung fachlich auf dem Zielsystem? Zweitens: Lässt sie sich im vorgesehenen Managementprozess installieren, erkennen, aktualisieren und deinstallieren? Ein manueller Test unter einem Administratorkonto beweist die zweite Ebene nicht. Bei Fachanwendungen hilft ein reproduzierbarer Paketstandard, wie ihn die Paketierungs-Factory liefert.

Unklare Owner sind selbst ein Befund. Wenn niemand eine fachliche Freigabe erteilen kann, darf das Projekt diese Lücke nicht mit einem technischen „funktioniert bei uns“ überdecken. Die Anwendung erhält einen Entscheidungsstatus, einen Eskalationsweg und gegebenenfalls eine begrenzte Ausnahme für den Pilot.

3. Identität, Policies und Sicherheitszustand verstehen

Ein neuer Clientzustand entsteht nicht nur durch das Betriebssystem. Anmeldung, Geräteidentität, Zertifikate, Gruppenrichtlinien, Intune-Policies, Sicherheitskonfiguration und Netzwerkkontrollen wirken gleichzeitig. Das Assessment prüft, welche Plattform welche Einstellung verantwortet und ob sich Regeln überschneiden. Besonders in Co-Management-Szenarien ist eine klare Workload- und Gruppenzuordnung nötig.

Sicherheitsanforderungen werden als überprüfbare Bedingungen formuliert: Welche Verschlüsselung muss vorliegen? Welche Zertifikate und Netzwerkpfade sind für Enrollment, Deployment und Anwendungen erforderlich? Was passiert mit einem Gerät, das nach dem Migrationsschritt noch nicht den erwarteten Compliance-Zustand meldet? Die fachliche Freigabe dieser Regeln bleibt bei den zuständigen Rollen; das Assessment macht ihre technische Wirkung sichtbar.

4. Den Deployment-Weg als Prozess testen

MECM, Intune oder ein kombinierter Weg können das Ziel bereitstellen. Entscheidend ist nicht der Produktname, sondern der vollständige Ablauf: Zielgruppenzuordnung, Download, Vorbedingungen, Installation, Neustarts, Anmeldung, Anwendungen, Reporting und Fehlerbehandlung. Eine Task Sequence oder Richtlinie wird deshalb nicht nur auf einem Laborgerät geprüft, sondern gegen repräsentative Kategorien und definierte Negativfälle.

Zum Assessment gehören Content-Verteilung, Netzwerkkapazität und Standorte. Ein technisch korrektes Image kann operativ scheitern, wenn große Inhalte gleichzeitig über ungeeignete Leitungen laufen. Ebenso muss klar sein, welche Daten ein Rollout-Dashboard zeigt, wie aktuell sie sind und wer auf einen Fehler reagiert. Der MECM- und Intune-Health-Check kann diese Plattform- und Betriebssicht vertiefen.

5. Benutzerzustand, Daten und Arbeitsfähigkeit einbeziehen

Migration ist für Nutzer nicht abgeschlossen, wenn das Gerät den Desktop zeigt. Profile, bekannte Ordner, lokale Daten, Browserzustand, Zertifikate, Drucker, Netzlaufwerke und anwendungsspezifische Einstellungen können die Arbeitsfähigkeit bestimmen. Das Assessment legt fest, welche Daten zentral verwaltet werden, welche lokal entstehen und welcher Rückfallweg bei unvollständiger Übernahme möglich ist.

Auch der Zeitbedarf gehört hierher. Ein Gerät mit langer Datenübernahme oder großen Downloads passt möglicherweise nicht in dasselbe Wartungsfenster wie ein standardisierter Büroclient. Pilotgruppen müssen diese Unterschiede absichtlich enthalten. Nur dann liefert die beobachtete Dauer eine brauchbare Grundlage für Rolloutplanung und Kommunikation.

6. Betrieb und Support vor dem ersten Ring vorbereiten

Der Service Desk braucht mehr als die Information, dass eine Migration stattfindet. Er benötigt erkennbare Fehlerklassen, Logpfade, Standardprüfungen, Eskalationskriterien und einen aktuellen Status des Rollouts. Betriebsteams müssen wissen, wie ein Gerät aus einem Ring genommen, erneut gestartet oder kontrolliert zurückgestellt wird. Diese Abläufe sind Teil des technischen Designs.

Ein gutes Assessment benennt außerdem die Beobachtungszeit. Manche Fehler treten erst nach Neustart, Policy-Aktualisierung, Netzwerkwechsel oder Nutzung einer seltenen Fachfunktion auf. Ein Pilot, der unmittelbar nach der Anmeldung als erfolgreich gilt, misst zu wenig. Erfolgskriterien verbinden technische Installation, Arbeitsfähigkeit, Monitoring und einen festgelegten Zeitraum.

Praktische Assessment-Checkliste

Die folgende Checkliste ist bewusst als Entscheidungsinstrument formuliert. Ein Haken bedeutet nicht nur „Daten vorhanden“, sondern „geprüft, verantwortet und mit nächstem Schritt versehen“.

• [ ] Die aktive Zielmenge ist von veralteten, doppelten und unbekannten Geräten getrennt.
• [ ] Jede relevante Hardwarefamilie hat ein repräsentatives Testgerät und einen Treiberstatus.
• [ ] Kritische Peripherie ist einem Owner und einem konkreten Testfall zugeordnet.
• [ ] Anwendungen sind nach Reichweite, Kritikalität, Paketierungsaufwand und Abhängigkeit priorisiert.
• [ ] Für jede kritische Anwendung sind technische und fachliche Abnahme getrennt benannt.
• [ ] Installations-, Detection-, Update- und Deinstallationsweg sind für den Zielprozess geprüft.
• [ ] Identität, Zertifikate, Netzwerkzugriffe und Geräteeinbindung sind im Zielzustand beschrieben.
• [ ] GPO-, Intune- und MECM-Zuständigkeiten widersprechen sich nicht unbemerkt.
• [ ] Daten- und Profilübernahme haben einen überprüfbaren Ablauf und eine bekannte Grenze.
• [ ] Deployment, Content-Verteilung und Standortkapazität wurden zusammen betrachtet.
• [ ] Pilotgruppen bilden Hardware, Anwendungen, Standorte und Nutzungssituationen realistisch ab.
• [ ] Erfolg, Abbruch, Wiederanlauf und Rückfall sind als Kriterien definiert.
• [ ] Reporting zeigt Zielmenge, Status, Fehlerklasse, Alter des Befunds und nächste Aktion.
• [ ] Service Desk und Betrieb verfügen vor dem Pilot über Runbook und Eskalationsweg.
• [ ] Ausnahmen besitzen Owner, Begründung, Frist oder eine bewusst dokumentierte Dauerentscheidung.

Aus Befunden Entscheidungen machen

Ein Assessment sollte nicht mit einer langen Liste gleichgewichtiger Probleme enden. Sinnvoll sind vier Entscheidungsklassen. Freigegeben bedeutet: Voraussetzungen sind erfüllt und der Fall kann in einen definierten Ring. Freigegeben mit Auflage bedeutet: Eine begrenzte Maßnahme oder Beobachtung ist vor dem nächsten Ring nötig. Blockiert bedeutet: Ein konkreter technischer oder fachlicher Befund verhindert die Migration. Ausnahme bedeutet: Der Fall folgt bewusst einem anderen Pfad und besitzt Owner und Begründung.

Diese Klassen werden mit der Zielmenge verbunden. So lässt sich entscheiden, ob ein Pilot repräsentativ genug ist, ob ein Paketierungs-Backlog vorgezogen werden muss oder ob eine Hardwaregruppe einen separaten Pfad benötigt. Prozentwerte ohne diese Zuordnung sind wenig hilfreich: Ein kleiner blockierter Anteil kann eine hochkritische Fachfunktion enthalten.

Vom Assessment in Pilot und Rollout

Der Pilot ist die erste Überprüfung des Modells, nicht die Fortsetzung einer Datensammlung ohne Kriterien. Er enthält Vertreter der wichtigen Hardware- und Anwendungskategorien, ausreichend Supportnähe und Nutzer, die reale Arbeitsabläufe testen können. Vor dem Start stehen der erwartete Ablauf, die Beobachtungszeit und die Entscheidung nach dem Ring fest.

Nach jedem Ring werden Befunde in genau dieselbe Struktur zurückgeführt: Kategorie, Evidenz, Wirkung, Owner, nächste Aktion. Dadurch wachsen keine parallelen Excel-Listen, deren Status sich widerspricht. Der Rollout wird breiter, wenn die definierten Qualitätsgrenzen erreicht sind – nicht, weil ein Kalenderdatum näher rückt.

Typische Fehlannahmen

Die erste Fehlannahme lautet, neue Hardware löse das Migrationsproblem. Sie kann technische Voraussetzungen vereinheitlichen, aber nicht automatisch Anwendungen, Identität und Betrieb. Die zweite lautet, ein erfolgreiches Laborgerät beweise den Prozess. Es beweist nur diesen Fall unter diesen Bedingungen. Die dritte lautet, jede Ausnahme müsse vor dem Start beseitigt sein. Tatsächlich müssen Ausnahmen vor allem sichtbar, begründet und steuerbar sein.

Eine weitere Fehlannahme ist, der Managementwechsel müsse gleichzeitig mit dem Betriebssystemwechsel erfolgen. Manchmal ist die Kombination sinnvoll, manchmal vervielfacht sie die Ursachen möglicher Fehler. Das Assessment sollte beide Änderungen getrennt bewerten und nur dann koppeln, wenn Ownership, Beobachtung und Rückfall beherrschbar sind.

Lieferfähiges Ergebnis statt Bestandsaufnahme

Am Ende stehen ein priorisiertes Befundbild, eine Geräte- und Anwendungsmatrix, der technische Migrationspfad, Pilot- und Ringdesign, Qualitäts- und Abbruchkriterien, ein Ausnahmeprozess sowie die Anforderungen an Reporting und Support. Annahmen und Datenlücken bleiben als solche erkennbar. Genau diese Trennung schafft Vertrauen: Das Projekt weiß, was belegt ist, was entschieden wurde und was noch offen ist.

Wer diese Grundlage nicht intern erstellen kann oder eine unabhängige technische Verdichtung braucht, kann mit der Leistung Windows 11 Migration für komplexe Client-Landschaften beginnen. Wo Standard-IT endet, fangen wir an – mit einem Assessment, das einen kontrollierten nächsten Schritt ermöglicht.