Viele AVD-Migrationen werden unnötig komplex. Der Grund liegt selten an der Technik selbst, sondern an dem, was vor dem ersten Session Host passiert: fehlendes Assessment, unterschätzte Anwendungen, vergessene Profile, ignorierte Peripherie und ein Netzwerk, das erst im Pilot auffällt.
Dieser Artikel richtet sich an VDI-Verantwortliche, die den Umstieg konkret planen. Sie bekommen einen praxisorientierten Projektleitfaden: sechs Phasen, konkrete Checklisten in Frageform, messbare Quality Gates und Zielwerte für den späteren Betrieb.
Falls Sie grundsätzlich prüfen wollen, ob AVD die richtige Lösung ist, empfehlen wir vorab unseren Beitrag „Was ist Azure Virtual Desktop? Einsatz und Vorteile“.
Kostenfreies Whitepaper:
„VDI verstehen & umsetzen: Der Weg zum digitalen Arbeitsplatz“
Wenn Sie sich noch genauer über Virtual Desktop Infrastructure informieren möchten, dann laden Sie sich unseren kostenlosen Leitfaden „VDI verstehen & umsetzen“ herunter.
Von welchem Desktop-Konzept kommen Sie?
Eine AVD-Migration ist kein Lift-and-Shift. Microsoft stellt keinen direkten Migrationspfad von Citrix, Omnissa oder RDS bereit, weil AVD als PaaS anders aufgebaut ist. Host Pools, Images, Profile und Apps werden in der Regel neu geplant und aufgebaut.
Ihre Ausgangssituation bestimmt den Projektaufwand. Je nachdem, ob Sie von Fat Clients, einer RDS-Farm oder einer Citrix- bzw. Omnissa-Umgebung migrieren, unterscheiden sich die Anforderungen deutlich. Gleichzeitig ist ein Greenfield-Ansatz unabhängig von der bestehenden Umgebung jederzeit eine Option, wenn ein vollständiger Neustart strategisch sinnvoll ist.
| Ausgangssituation | Empfohlener Ansatz | Besonderheit |
| Citrix oder Omnissa Horizon | Host Pools, Anwendungen und Profile neu konzipieren | Keine Lift-and-Shift-Migration möglich |
| RDS-Farm | Geeignetes Bereitstellungsmodell (RemoteApps oder Full Desktop) festlegen | Anwendungen und Nutzergruppen analysieren |
| Fat Clients / physische PCs | Anwender, Anwendungen und Geräte für AVD bewerten | Daten, Peripherie und Benutzerprofile frühzeitig einplanen |
| Greenfield | AVD von Grund auf neu aufbauen | Aufbau nach aktuellen Best Practices ohne Altlasten |
Unabhängig vom gewählten Migrationsansatz hat sich der nachfolgend beschriebene sechsstufige Projektablauf in der Praxis bewährt.
AVD-Migration in sechs Projektphasen
Eine strukturierte AVD-Migration läuft in sechs Phasen. Jede Phase hat ein definiertes Ziel und ein Quality Gate, das den Übergang zur nächsten Phase absichert.
| Phase | Typische Dauer | Zentrales Quality Gate |
| 1. Assessment | 2–6 Wochen | Vollständige User-, App-, Daten- und Peripherieliste |
| 2. Design | 2–4 Wochen | Architektur, Landing Zone und Betriebsmodell freigegeben |
| 3. Build | 2–8 Wochen | Landing Zone, Images, FSLogix und Security stehen |
| 4. Pilot | 4–8 Wochen | Pilotgruppe arbeitet produktiv, Zielwerte werden erreicht |
| 5. Rollout | 1–6 Monate | Wellenplan mit Rückfalloption umgesetzt |
| 6. Betrieb | laufend | Kosten, Performance und Support stabil |
Die Zeitangaben sind Orientierungswerte. Die tatsächliche Dauer schwankt stark je nach Größe der Nutzerbasis, Heterogenität der Anwendungen und Reifegrad der bestehenden IT. Ein Greenfield-Projekt mit 200 Standardnutzern ist in Monaten realistisch, eine Citrix-Ablösung mit 5.000 Nutzern über zehn Standorte dauert deutlich länger.
Phase 1: Assessment
Jede nicht gestellte Frage wird später zum Projektrisiko. Im Assessment erfassen Sie systematisch, was heute genutzt wird und was in AVD abgebildet werden muss. Alles, was hier fehlt, taucht später im Pilot oder Rollout wieder auf und kostet dann deutlich mehr.
Arbeiten Sie die folgenden Bereiche mit Fachbereich, IT-Betrieb und Netzwerkverantwortlichen gemeinsam durch:
| Bereich | Zu klären im Assessment |
| Identity & Access | Welche Benutzergruppen und wie viele gleichzeitige Nutzer? Identitätsquelle: Active Directory, Entra ID oder hybrid? Mehrere Forests, Domains oder externe Nutzer? Wie werden privilegierte Konten heute behandelt? |
| Netzwerk & Standorte | Von welchen Standorten wird zugegriffen? Wie sind Bandbreite, Latenz und WAN-Auslastung heute? VPN, ExpressRoute oder direkte Internet-Breakouts? Latenzsensible Anwendungen? |
| Benutzerprofile | Typische Profilgröße heute? Roaming Profiles oder Folder Redirection im Einsatz? Bekannte Profilprobleme? Lokale Daten im Profil? |
| Daten & Speicher | Wo liegen Nutzerdaten: File Server, DFS, OneDrive, SharePoint? Welche Datenmengen ändern sich täglich? Offline-Dateien oder lokale Datenbestände? |
| Anwendungen | Welche Apps sind geschäftskritisch? Legacy-Apps, USB-Dongles, GPU-Anforderungen? Wer testet die App-Kompatibilität fachlich? |
| Endgeräte & Peripherie | Welche Gerätetypen und Betriebssysteme? Thin Clients, BYOD, veraltete Hardware? Spezialdrucker, Scanner, Signaturpads, Smartcards je Standort? |
| Security & Compliance | Regulatorische Anforderungen? Datenklassifizierung? Bestehende Security-Lösungen? |
| Betrieb & Support | Wer betreibt heute? Welche SLAs, welches Monitoring, welches Ticketmodell? |
Das Ergebnis dieser Phase ist eine dokumentierte Ist-Aufnahme. Sie ist die Grundlage für alle folgenden Entscheidungen.
Phase 2: Zielarchitektur & Design
In dieser Phase legen Sie fest, wie Ihre AVD-Umgebung technisch aussieht. Die zentralen Entscheidungen betreffen Identität, Netzwerk, Profilspeicher und App-Bereitstellung. Alles baut auf dem Assessment auf.
Klären Sie die folgenden Kernfragen:
| Bereich | Zu entscheiden im Design |
| Identity | Entra ID Join oder Hybrid Join? Welche RBAC-Rollen? Conditional Access und MFA verpflichtend? |
| Region & Netzwerk | Welche Azure-Region liegt nutzernah? Wird RDP Shortpath genutzt? DNS-Architektur und Firewall-Anpassungen? |
| Profilspeicher | FSLogix auf Azure Files oder Azure NetApp Files? Welche Speichergrößen, Backup und Restore? |
| App-Bereitstellung | Golden Image, App Attach oder Kombination? Getrennte Host Pools für „schwere“ und „leichte“ Apps? Lizenzmodelle AVD-kompatibel? |
| Endgeräte | Offiziell unterstützt? Windows App oder Remote Desktop Client? Peripherie umgeleitet oder lokal? |
| Security-Baseline | Defender for Cloud, Logging, Patch-Management, Baselines? |
| Betrieb | Welche KPIs werden überwacht? Wie erfolgen Alarmierung und Autoscaling? Wie sehen die neuen Helpdesk- und Supportprozesse aus? Wer trägt die Kostenverantwortung? |
| Daten | Was migriert in die Cloud, was bleibt on-prem? Berechtigungen, Performance, Datenresidenz? |
Prüfen Sie außerdem die offiziellen AVD-Voraussetzungen von Microsoft und dokumentieren Sie das Betriebsmodell inklusive Alarmierung, Autoscaling und Kostenverantwortung.
Das Ergebnis dieser Phase ist ein abgestimmtes Zielbild. Erst wenn dieses Zielbild von IT, Security und Fachbereich freigegeben ist, beginnt der Build.
Phase 3: Build & technische Vorbereitung
Jetzt entsteht die eigentliche Plattform. Die Landing Zone, die Images, die Profilspeicher und die Security-Baseline werden aufgebaut. Als Referenz eignet sich das Cloud Adoption Framework für AVD von Microsoft.
Die Phase ist abgeschlossen, wenn diese Punkte erfüllt sind:
| Bereich | Fertig, wenn … |
| Landing Zone | Subscription-Struktur, Netzwerk, Policies und Governance stehen |
| Identity & Access | Nutzer und Gruppen synchronisiert, RBAC-Rollen vergeben, Conditional Access aktiv |
| Netzwerk | Firewall, DNS und Routing auf AVD-Endpunkte vorbereitet, Freigaben getestet |
| Profilspeicher | FSLogix-Speicher bereitgestellt, Berechtigungen und Backup getestet, Restore verifiziert |
| Images & Apps | Golden Image gebaut, Kern-Apps paketiert, Redirect-Richtlinien verteilt |
| Security | Baselines, Defender, Logging und Patch-Prozess aktiv |
| Monitoring | Azure Monitor, Log Analytics und Dashboards liefern Daten |
Bauen Sie parallel Ihre Runbooks. Anmelden, neue Nutzer bereitstellen, Skalierung anpassen, Notfall-Rollback: Diese Standardvorgänge müssen dokumentiert und getestet sein, bevor der Pilot startet.
Phase 4: Pilot mit messbaren Quality Gates
Der Pilot muss als Realitätstest verstanden werden: Er zeigt, ob AVD im echten Arbeitsalltag funktioniert. Ein aussagekräftiger Pilot umfasst mindestens 20 bis 50 Nutzer aus IT und Fachbereich, deckt alle Standorte ab und läuft über mehrere Wochen.
Die Pilotfreigabe erfolgt anhand messbarer Kriterien. Die folgenden Werte sind typische Erfahrungswerte aus VDI-Projekten und dienen als Orientierung:
| Quality Gate | Zielwert (Erfahrungswert) |
| Anmeldezeit | unter 60 Sekunden |
| Profilbereitstellung | stabil, keine temporären Profile |
| App-Start Kernanwendungen | unter 15 Sekunden |
| Teams Audio und Video | störungsfrei über mindestens zwei Wochen |
| Peripherie je Standort | Druck, Scan, Signaturpad, Smartcard erfolgreich getestet |
| Datenzugriff | File Shares, SharePoint und OneDrive vollständig erreichbar |
| Security | MFA, Conditional Access, Logging und Defender aktiv |
| User Acceptance | schriftliche Freigabe der Pilotgruppe |
Erst wenn alle Gates erreicht sind, ist der Pilot bestanden. Wenn ein Kriterium nicht erfüllt ist, wird die Ursache im Pilot behoben, nicht erst später im Rollout.
Phase 5: Rollout in Wellen
Ein Big-Bang-Rollout ist bei AVD selten sinnvoll. Wellenweise Migration reduziert Risiken, erlaubt Lernkurven im Support und schafft für jede Nutzergruppe einen belastbaren Fallback-Pfad.
Bewährt hat sich das folgende Vier-Wellen-Modell:
| Welle | Benutzergruppe | Ziel | Fallback-Option |
| Pilot | 20–50 Nutzer aus IT und Fachbereich | Systemreife nachweisen | Bestehender Arbeitsplatz bleibt aktiv |
| Early Adopters | ca. 10 % der Belegschaft, technikaffin | Prozessreife im Alltag | Parallelbetrieb für vier Wochen |
| Standard User | Office-Nutzer, gestaffelt nach Abteilung | Massenrollout | Rollback pro Welle |
| Kritische User | Fachnutzer mit Spezial-Peripherie zuletzt | Vollständige Ablösung der Altplattform | Rollback pro einzelnem Nutzer |
Kommunikation und Schulung entscheiden mit über den Erfolg. Jede Welle sollte mit einer klaren Ankündigung starten, einen dedizierten Support-Kanal haben und im Nachgang ausgewertet werden. Nur wer die Erkenntnisse aus Welle 1 in Welle 2 einbaut, spart im Rollout Zeit und Nerven.
Erst nach der letzten Welle werden Altsysteme stillgelegt. Diesen Schritt sollten Sie fest im Plan verankern, sonst verbleiben Alt-VDI und AVD dauerhaft parallel und verursachen doppelte Kosten.
Phase 6: Betrieb & Optimierung
Nach Go-live beginnt der eigentliche Betrieb. Jetzt entscheidet sich, ob AVD wirtschaftlich läuft und ob die Nutzererfahrung stabil bleibt. Ohne definierte KPIs steuert niemand aktiv, es wird nur reagiert.
Die folgenden Zielwerte haben sich in der Praxis bewährt:
| Betriebs-KPI | Zielwert (Erfahrungswert) |
| Anmeldezeit | unter 60 Sekunden |
| CPU-Auslastung Session Host | im Durchschnitt unter 80 % |
| RAM-Auslastung | im Durchschnitt unter 85 % |
| Profilgröße FSLogix | Zielwert unter 30 GB, Alarm ab 25 GB |
| Storage-Wachstum | unter 10 % pro Monat |
| Kosten pro Nutzer | definierter Zielkorridor mit monatlichem Reporting |
Kostenkontrolle ist im Betrieb Chefsache. Nutzen Sie Autoscale, Start-VM-on-Connect und Reserved Instances aktiv. Prüfen Sie mindestens einmal pro Quartal, ob die Host-Pool-Dimensionierung noch zur tatsächlichen Nutzung passt.
Ein professionelles Betriebsmodell umfasst außerdem Patch-Management für Session Hosts und Images, Monitoring mit Alarmierung, ein Ticket- und Eskalationsmodell sowie regelmäßige Restore-Tests des FSLogix-Speichers.
Wenn Sie diese Themen intern nicht dauerhaft abbilden können, ist ein Managed-Services-Modell eine Option.
Die zehn häufigsten Stolpersteine
Diese Fehler tauchen in AVD-Projekten immer wieder auf:
- Kein vollständiges Assessment. Starten Sie erst, wenn Nutzer, Apps, Peripherie, Daten und Netzwerk exakt dokumentiert sind. Skizzen reichen nicht, es braucht Listen.
- Anwendungen nur technisch getestet. Der Fachbereich muss echte Workflows durchspielen, nicht nur „App startet“. Planen Sie dafür feste Testtage mit definierten Szenarien.
- FSLogix unterschätzt. Größe, Berechtigungen, Backup und Performance gehören in die Design-Phase, nicht in den Pilot. Testen Sie Restore einmal produktiv, bevor der Rollout beginnt.
- Datenmigration vergessen. File Shares, DFS, Offline-Dateien und lokal gespeicherte Daten brauchen einen expliziten Migrationsplan mit Deltasync und Cutover-Datum.
- Spezialdrucker und Peripherie übersehen. Erstellen Sie eine Peripherie-Matrix je Standort und testen Sie jede Kombination im Pilot, nicht erst im Rollout.
- Netzwerk falsch dimensioniert. Führen Sie vor dem Pilot Latenz-, Bandbreiten- und RDP-Shortpath-Tests aus allen Nutzerstandorten durch, nicht nur aus der Zentrale.
- Pilot zu klein. Mindestens 20 bis 50 Nutzer aus IT und Fachbereich, echte Arbeitsszenarien, mehrere Wochen Laufzeit. Alles darunter ist eine Demo, kein Pilot.
- Kein Betriebsmodell. Monitoring, Patching, Support und Kosten müssen vor dem Go-live definiert sein. So sparen Sie sich Hektik und Improvisation im Betrieb.
- Keine Kostenkontrolle. Legen Sie Zielkosten pro Nutzer fest, aktivieren Sie Autoscale und prüfen Sie die Auslastung monatlich. AVD ohne FinOps-Prozess wird teuer.
- Kein Rollback-Szenario. Jede Welle braucht einen definierten Rückfallweg. Ohne Rollback-Plan wird jede Störung zum Drama.
AVD oder eine andere VDI-Lösung?
Nicht in jedem Fall ist AVD die passende Antwort. Windows 365, Citrix, Omnissa oder hybride Modelle können je nach Anforderung besser passen. Unser Blogartikel „Virtual Desktop Anbieter Vergleich: Microsoft, Citrix & Omnissa (ehem. VMware)“ bietet eine gute Übersicht über die anderen VDI-Modelle.
Von der Checkliste zur Umsetzung mit Proact
Eine AVD-Migration ist mehr als das Bereitstellen neuer Session Hosts. Über den Projekterfolg entscheiden Profile, Anwendungen, Daten, Netzwerk, Peripherie, Security und Betrieb. Wer diese Themen in sechs klaren Phasen mit dokumentierten Checklisten und messbaren Quality Gates bearbeitet, reduziert Projektrisiken erheblich.
Proact begleitet Unternehmen seit vielen Jahren bei VDI-, Workplace- und Cloud-Projekten. Konkret unterstützen wir Sie bei Landing Zone, FSLogix-Design, Pilot-Steuerung, Rollout-Planung, Security-Baselines und Managed Operations. So bleibt Ihr Team frei für die eigenen Kernthemen, während wir den Migrationsprozess absichern.
Sie stehen am Anfang einer AVD-Migration oder überlegen, ob Ihre bestehende VDI-Umgebung migrationsreif ist? Lassen Sie uns das in einem kostenlosen Erstgespräch gemeinsam bewerten.
Kostenfreies Whitepaper:
„VDI verstehen & umsetzen: Der Weg zum digitalen Arbeitsplatz“
Wenn Sie sich noch genauer über Virtual Desktop Infrastructure informieren möchten, dann laden Sie sich unseren kostenlosen Leitfaden „VDI verstehen & umsetzen“ herunter.