Wie komplex ist eigentlich eine Migration von Citrix oder RDS zu Horizon?

Technisch beherrschbar – organisatorisch oft unnötig verkompliziert. 

„Nicht die Plattform ist das Problem, sondern Perfektionismus, Feature-Diskussionen und zu viel Planung ohne Umsetzung. Genau hier setzt ein pragmatischer Ansatz an, den ich gern die „Migration Superhighway“ nenne.“

Anastasios Ntaflos
Business Area Lead Mod| Microsoft MVP | Omnissa Tech Insider | evoila

Eine Migration von Citrix oder klassischen RDS-Umgebungen zu Horizon wirkt auf den ersten Blick oft komplexer, als sie tatsächlich ist. In vielen Projekten zeigt sich schnell, dass nicht die Technologie der limitierende Faktor ist, sondern die Art und Weise, wie Migrationen angegangen werden. Zu viel Perfektionismus, endlose Feature-Diskussionen und eine überfrachtete Planungsphase sorgen häufig dafür, dass Projekte ins Stocken geraten, noch bevor der erste Benutzer migriert wurde. Dabei ist der eigentliche Schlüssel zum Erfolg erstaunlich simpel: Fokus, Pragmatismus und ein klarer Blick auf das gewünschte Ergebnis. 

Wenn Kunden über einen Plattformwechsel nachdenken, tauchen fast immer dieselben Fragen auf. Wie einfach oder schwierig ist der Umstieg wirklich? Muss die Migration schrittweise erfolgen oder ist ein klarer Schnitt möglich? Wie geht man mit technischem Ballast aus der Vergangenheit um? Und vor allem: Was bedeutet der Wechsel für Endanwender und Betrieb? Die Antworten darauf können je nach Organisation unterschiedlich ausfallen, doch der grundlegende Weg hin zu Horizon folgt in den meisten Fällen einem sehr ähnlichen Muster. 

Ein strukturierter Weg durch die Migration

Hilfreich ist es, Migration nicht als einmaliges Großprojekt zu betrachten, sondern als klar strukturierten Prozess. Ein bewährter Ansatz ist die sogenannte „Migration Superhighway“, die den Weg in fünf Phasen unterteilt. Zuerst steht das Planen im Vordergrund. Dabei geht es weniger darum, jedes technische Detail im Voraus zu perfektionieren, sondern vielmehr darum, die Ausgangslage zu verstehen, klare Ziele zu definieren und Verantwortlichkeiten festzulegen. Wer nicht weiß, warum er migriert und welches Ergebnis erreicht werden soll, wird sich zwangsläufig in Details verlieren. Ebenso wichtig ist es, die Kommunikation früh mitzudenken und die Nutzer nicht erst kurz vor dem Go-live abzuholen. 

Darauf folgt die Testphase, in der Annahmen durch Realität ersetzt werden. Pilotanwender und überschaubare Use Cases liefern wertvolle Erkenntnisse, die kein Architekturdiagramm ersetzen kann. In dieser Phase entstehen auch Runbooks und Dokumentationen, die später helfen, die Migration zu skalieren und menschliche Fehler zu reduzieren. Tests sind kein Selbstzweck, sondern die Grundlage dafür, dass der eigentliche Rollout kontrolliert und planbar ablaufen kann. 

In der Move-Phase wird aus Planung und Test schließlich Umsetzung. Benutzer werden migriert, Images angepasst, Agenten getauscht oder neue Desktops bereitgestellt. Überraschungen lassen sich dabei nie vollständig vermeiden, entscheidend ist jedoch der Umgang damit. Migration bedeutet nicht, dass alles reibungslos funktioniert, sondern dass Probleme schnell erkannt, priorisiert und gelöst werden. Geschwindigkeit entsteht nicht durch Perfektion, sondern durch Handlungsfähigkeit. 

Ein häufig unterschätzter Aspekt ist der laufende Betrieb. Die Frage, wie die Horizon-Plattform während und nach der Migration betrieben wird, sollte nicht erst am Ende gestellt werden. Betriebs- und Supportprozesse, Image-Lifecycle-Management, Applikationsbereitstellung und Patch-Strategien müssen parallel zur Migration etabliert und weiterentwickelt werden. Wer diesen Punkt ignoriert, riskiert, dass die neue Plattform zwar technisch funktioniert, aber operativ nicht tragfähig ist. 

Erst wenn die Migration Fahrt aufgenommen hat oder weitgehend abgeschlossen ist, beginnt die Phase der Verbesserung. Jetzt ist der richtige Zeitpunkt, um technische Schulden gezielt abzubauen, Altlasten zu bereinigen und die Plattform weiter zu modernisieren. Themen wie dynamische Applikationsbereitstellung, Profilmanagement oder ein Upgrade auf ein neues Betriebssystem entfalten hier ihren Mehrwert, ohne den Migrationsprozess unnötig zu bremsen. Wichtig ist dabei, dass Verbesserungen nicht zum neuen Blocker werden. Nicht alles, was möglich ist, muss sofort umgesetzt werden. 

Über allem steht ein klares Mindset. Der Fokus sollte immer auf der End User Experience liegen, nicht auf der technischen Eleganz der Lösung. Migrationstempo und Vorgehen werden durch geschäftliche und organisatorische Anforderungen bestimmt, nicht durch technische Ideale. Kompromisse sind unvermeidlich und kein Zeichen von Schwäche, solange sie bewusst getroffen und dokumentiert werden. Technische Schulden lassen sich nicht immer sofort vermeiden, aber sie lassen sich managen, wenn man sie sichtbar macht und in spätere Phasen einplant. 

Am Ende zeigt sich immer wieder: Eine Migration zu Horizon ist kein Hexenwerk. Wer den Weg klar strukturiert, den Mut hat, nicht alles gleichzeitig lösen zu wollen, und den Nutzer konsequent in den Mittelpunkt stellt, schafft die Grundlage für eine stabile, moderne und zukunftsfähige Digital-Workspace-Plattform. Migration ist dabei kein Endpunkt, sondern der Startpunkt für kontinuierliche Verbesserung. 

Die immer gleichen Fragen vor einer Migration 

Die Migration Superhighway: Struktur statt Komplexität 

Hilfreich ist es, Migration nicht als einmaliges Großprojekt zu betrachten, sondern als klar strukturierten Prozess. Ein bewährter Ansatz ist die sogenannte „Migration Superhighway“, die den Weg in fünf Phasen unterteilt. Diese Struktur hilft dabei, Komplexität zu reduzieren und den Fokus auf das Wesentliche zu behalten. 

In der ersten Phase, Plan it, geht es darum, die Ausgangslage zu verstehen und klare Ziele zu definieren. Warum wird migriert, welche Ergebnisse sollen erreicht werden und wer übernimmt welche Aufgaben? Es geht ausdrücklich nicht darum, jedes technische Detail im Voraus zu perfektionieren. Wer versucht, alles vorab zu klären, riskiert Stillstand. Ebenso wichtig ist es, Kommunikation früh mitzudenken und die Nutzer nicht erst kurz vor dem Go-live abzuholen. 

Darauf folgt Test it. In dieser Phase werden Annahmen durch Realität ersetzt. Pilotanwender und überschaubare Use Cases liefern wertvolle Erkenntnisse, die kein Architekturdiagramm ersetzen kann. Gleichzeitig entstehen Runbooks und Dokumentationen, die später helfen, die Migration zu skalieren und menschliche Fehler zu reduzieren. Tests sind kein Selbstzweck, sondern die Grundlage für einen kontrollierten Rollout. 

In der dritten Phase Move it beginnt der eigentliche Übergang. Jetzt wird migriert – schrittweise, kontrolliert und mit klaren Wellen. Entscheidend ist, dass Technik, Prozesse und Kommunikation zusammenspielen. Ein stabiler Migrationsrhythmus sorgt dafür, dass sowohl IT als auch Fachbereiche wissen, was als Nächstes passiert. Wichtig: Feedback aus den ersten Migrationen fließt direkt in die nächsten ein. So wird aus einem theoretischen Plan ein lernender Prozess. 

Phase vier, Run it, wird in vielen Projekten unterschätzt. Nach der Migration ist vor dem Betrieb. Jetzt zeigt sich, ob das neue Setup wirklich alltagstauglich ist. Monitoring, Supportprozesse und klare Zuständigkeiten stellen sicher, dass die Plattform stabil läuft und Nutzer Vertrauen aufbauen. Gleichzeitig entstehen hier die Grundlagen für Optimierung – auf Basis realer Nutzung statt Annahmen. 

Abschließend folgt Improve it. Migration ist kein Endpunkt, sondern der Start in einen kontinuierlichen Verbesserungsprozess. Technische Schulden aus der Altumgebung können gezielt abgebaut werden, neue Features werden bewusst eingeführt und Arbeitsweisen weiterentwickelt. Wer diese Phase ernst nimmt, verhindert, dass die neue Plattform über die Zeit genauso komplex wird wie die alte. 

Die Migration Superhighway zeigt: Erfolgreiche Migrationen scheitern selten an der Technologie. Sie gelingen dann, wenn Struktur, Pragmatismus und Fokus zusammenkommen – und wenn man den Mut hat, loszufahren, statt ewig auf der Auffahrt zu stehen.