BEKOM OPEN PROCitrix-XenServer-ExitXCP-ng, Proxmox, KVM evaluieren
Citrix Hypervisor und XenServer ablösen: XCP-ng, Proxmox, KVM und Hyper-V im Vergleich, Migrationspfade und Entscheidungsmatrix für eine strukturierte Ablösung.
Warum Citrix-XenServer-Exit aktuell ist
Die Citrix-Hypervisor- und XenServer-Landschaft verändert sich auf zwei Ebenen – strategisch und architektonisch. Strategisch: Seit der Übernahme durch die Cloud Software Group (2022) und dem Zusammenschluss mit TIBCO verlagert sich der Produktfokus vom Hypervisor hin zu Application Delivery (NetScaler/ADC) und Desktop-as-a-Service. Subscription-Modelle ersetzen Perpetual-Komponenten, Produkte werden gebündelt, die Roadmap-Sichtbarkeit der Virtualisierungs-Schicht nimmt ab. Architektonisch kommen viele XenServer-Bestandskunden aus einem VDI-Kontext: Der Hypervisor ist dort häufig Unterbau für Citrix Virtual Apps and Desktops (CVAD), flankiert von NetScaler und Provisioning Services. Der Exit hat damit eine Dimension, die rein Compute-orientierten Migrationen fehlt – was passiert mit dem darüberliegenden CVAD-Stack?
Der Citrix-XenServer-Exit betrifft geschäftskritische VDI-Infrastrukturen, über die Auftragsverarbeitung und standortübergreifende Arbeitsplätze bereitgestellt werden. Die Verfügbarkeit der Virtualisierungsschicht ist direkte Betriebsvoraussetzung für den operativen Betrieb, da Desktop-Services und Anwendungsbereitstellung davon abhängen. → BEKOM OPEN PRO Infrastructure
Die Cloud-Software-Group-Strategie und ihre Folgen für XenServer-Kunden
Die Neuausrichtung unter Cloud Software Group ist eine Verschiebung der Produkt-Prioritäten. Der Hypervisor verliert im Portfolio an Gewicht, während die Application-Delivery- und DaaS-Linie ausgebaut wird. Für XenServer-Bestandskunden wirkt das auf Laufzeit-Planung, Lizenzbudget und Werkzeug-Roadmap.
Was sich konkret verändert hat:
- Portfolio-Umbau mit Verschiebung auf NetScaler/ADC und Citrix DaaS; Hypervisor primär mit Bugfix-/Kompatibilitäts-Pflege statt sichtbarer Feature-Roadmap
- Ende der XenServer-Free-Edition, Konsolidierung verbleibender Editionen unter Premium-Subscription
- Produkt-Bündelung mit CVAD/DaaS, wodurch Hypervisor-Kosten schwerer einzeln steuerbar sind
- Umstrukturierung des Partner-/Reseller-Netzes mit Fokus auf Application-Delivery
- Preisanpassungen bei Vertragsverlängerung, besonders bei Paketen mit VDI-Anteil
Für Bestandskunden entsteht eine doppelte Planungsunsicherheit: technisch (wie lange bleibt XenServer ein priorisiertes Produkt?) und vertraglich (welche Pakete bleiben einzeln verfügbar?). Das begründet eine strukturierte Strategie-Bewertung – unabhängig davon, ob am Ende Wechsel, Teil-Exit oder bewusster Verbleib stehen.
Der XenServer-Exit als eigenständiges Migrations-Thema
Der Citrix-XenServer-Exit ist kein Standard-Hypervisor-Wechsel. Durch die enge Verzahnung mit CVAD und NetScaler sowie die Verfügbarkeit eines binärkompatiblen Forks (XCP-ng) stellen sich andere Fragen als bei einer typischen Hypervisor-Migration.
Citrix-spezifische Schwerpunkte:
- XCP-ng als Continuity-Option: Architektur-Fortführung statt Plattformwechsel, Migration über XAPI-Werkzeugkette
- Umgang mit dem CVAD-Stack: unverändert, mitmigriert oder ersetzt? Entscheidungs-Kriterien pro Szenario
- Proxmox, KVM/libvirt und Hyper-V als Alternativen bei bewusstem Architekturwechsel
- Migrationspfad entlang Xen-Orchestra, XVA und XenCenter inklusive PV-zu-VirtIO-Treibertausch
- Betriebsmodelle nach der Migration einschließlich VDI-relevanter Aspekte
BEKOM unterstützt auch Organisationen, die XenServer behalten und den Betrieb strukturiert outsourcen möchten – die Evaluierung ist technologie-neutral, ein Verbleib mit neuem Betriebsmodell ist ein zulässiges und häufiges Ergebnis.
Kostenstruktur mit XenServer-Besonderheiten
Ein Citrix-XenServer-Exit wirkt auf drei Kostenebenen mit Eigenheiten aus Citrix-Paket-Logik und VDI-Nähe. Auf der Hypervisor-Ebene wirken Socket- oder Core-basierte Subscription-Preise und die Frage, ob XenServer einzeln oder gebündelt mit CVAD/DaaS bezogen wird – die Paket-Entkopplung ist in vielen Verträgen nicht trivial. Auf der VDI-Ebene kommen Concurrent- oder Named-User-Lizenzen für CVAD hinzu, die nicht zwingend mit dem Hypervisor-Wechsel enden – CVAD kann auf XCP-ng, Proxmox oder Hyper-V weiterlaufen, sofern die Kombination offiziell unterstützt ist. Auf der Zielplattform-Ebene verschieben sich die Treiber: XCP-ng bringt keine Hypervisor-Lizenzgebühr (Open Source), Vates-Support ist optional. Hinzu kommen einmalige Migrationsaufwände für Pool-Inventar, Dry-Run, VM-Konvertierung (XVA für XCP-ng, virt-v2v für KVM-Ziele) und kontrollierten Rückbau. Ein strukturiertes Assessment trennt diese Ebenen und verhindert, dass CVAD-Lizenzfragen die Hypervisor-Entscheidung präjudizieren.
Alternativen im Vergleich
Die Zielplattformen zerfallen in zwei Grundtypen. Ein Architektur-Fortführungs-Szenario behält die Xen-Basis bei und wechselt auf XCP-ng – eine Binärfortführung, kein Plattformbruch. Ein Architekturwechsel-Szenario verlässt die Xen-Welt in Richtung KVM (Proxmox, libvirt/OpenStack) oder Hyper-V. Beide Pfade sind legitim, adressieren aber unterschiedliche Ausgangslagen.
XCP-ng – binärkompatible XenServer-Continuity (Leit-Option)
XCP-ng ist ein community-geführter Fork der XenServer-Basis, der XAPI-binärkompatibel zur Citrix-Plattform bleibt. Getrieben wird er von der französischen Firma Vates, die zusätzlich die Management-UI Xen Orchestra (XO) entwickelt. Für XenServer-Bestandskunden bedeutet das: Pool-Konzept, Storage-Repository-Logik, VM-Image-Format (VHD/XVA), HA-Mechanik und Befehlslogik (xe, XAPI-REST) bleiben erhalten. Die Migration ist ein kontrolliertes Umhängen der Hosts – kein Re-Plattforming.
Charakteristika:
Lizenzmodell: Open Source (GPL), optionale Support- und LTS-Subscription über Vates
Feature-Abdeckung: Pool-Cluster mit Master/Slave, Live-Migration, HA, Shared Storage (NFS/iSCSI/FC), Snapshot- und Delta-Backup via Xen Orchestra
Continuity-Eigenschaften: XVA-Images laufen ohne Konvertierung, PV-Treiber und XenTools bleiben nutzbar, XAPI-Skripte und Runbooks funktionieren unverändert
Typische Einsatzprofile: bestehende XenServer-Pools jeder Größe, VDI-Cases mit CVAD, Teams mit investierter Xen-Kompetenz
XCP-ng ist für Citrix-Hypervisor-Bestandskunden die Default-Option, wenn der Wechsel-Treiber Lizenzkosten und Roadmap-Sichtbarkeit sind – nicht eine bewusste Abkehr von der Xen-Architektur. Der Lock-in wechselt von einem Reseller-geführten Hersteller zu einem europäischen Open-Source-Anbieter; die technische Realität im Rechenzentrum bleibt vertraut.
Proxmox VE – Architekturwechsel nach KVM
Proxmox Virtual Environment verlässt die Xen-Welt und setzt auf KVM mit integriertem Cluster-Management, LXC-Containern und eigenem Backup-Server. Für XenServer-Kunden ist der Wechsel ein bewusster Architektur-Schnitt: VM-Images werden konvertiert (VHD → QCOW2/raw via virt-v2v), Storage-Repositories neu aufgesetzt, Xen Orchestra durch das Proxmox-Webinterface ersetzt, XAPI-Skripte neu geschrieben.
Charakteristika:
Lizenzmodell: Open Source (AGPL), optionale Enterprise-Subscription für den stabilen Paketkanal
Feature-Abdeckung: HA-Cluster, Live-Migration, Proxmox Backup Server, VM- plus LXC-Container-Betrieb
Werkzeug-Realität: neues Management-Webinterface, andere CLI (pvesh, qm), andere Cluster-Terminologie
Typische Einsatzprofile: bewusster Wechsel auf KVM, Konsolidierung mit Container-Workloads
Proxmox VE ist sinnvoll, wenn die Migration als strategischer Technologiewechsel geplant ist – etwa weil die KVM-Community, die Feature-Roadmap oder die Integration von VM- und Container-Workloads langfristig besser passen als der Verbleib in der Xen-Welt.
KVM und libvirt – Linux-Basis für eigene Orchestrierung
KVM im Linux-Kernel und libvirt als Management-API bilden das Fundament mehrerer Stacks (Proxmox intern, OpenStack, KubeVirt). Als direktes Ziel eines XenServer-Exits kommt die Kombination dort in Frage, wo Infrastructure-as-Code und eigene Automatisierung bereits etabliert sind.
Charakteristika:
Open Source (GPL), keine kommerzielle Pflichtbindung, Distributor-Support über Red Hat, SUSE, Canonical
Feature-Umfang vom gewählten Management-Stack abhängig (CLI, Cockpit, OpenStack, KubeVirt)
Hoher Eigenanteil bei Cluster-Design, Storage-Integration und HA-Mechanik
Für den typischen XenServer-Bestandskunden ist ein integriertes Produkt (XCP-ng für Continuity, Proxmox bei Architekturwechsel) der direktere Weg. Pures KVM/libvirt lohnt sich, wenn IaC bereits gelebt wird und die Plattform als austauschbare Compute-Schicht unter eigener Orchestrierung gedacht ist.
Hyper-V – Microsoft-Plattform bei VDI-Nähe
Hyper-V ist in Windows Server enthalten und in vielen Häusern bereits lizenziert. Für XenServer-Kunden mit starker Microsoft-Integration – etwa CVAD-Umgebungen mit Windows-Session-Hosts und Active-Directory-Policy-Management – ist Hyper-V eine ernstzunehmende Zielvariante, zumal CVAD/DaaS Hyper-V offiziell als Hypervisor-Unterbau unterstützt.
Charakteristika:
Proprietäre Bindung an Windows Server, Live-Migration, Failover-Clustering, System-Center-Integration
Microsoft-Support-Kanäle, etabliertes Partner-Ökosystem
Native Integration mit Active Directory, Group Policy, Microsoft-Werkzeugen
Hyper-V ist strategisch keine Open-Source-Ablösung, sondern ein Hersteller-Wechsel von der Cloud Software Group zu Microsoft. Für VDI-lastige Microsoft-Landschaften kann das die konsolidierungs-effizienteste Option sein; für Open-Source-Strategien bleibt der Lock-in ein bewusster Tradeoff.
Migrationspfad und Phasen
Die Ablösung einer Citrix-Hypervisor-Pool-Landschaft läuft über mehrere Quartale und folgt vier aufeinander abgestimmten Arbeitsblöcken. Jeder Block endet mit einem Kontrollpunkt – Geschäftsführung und IT-Leitung entscheiden vor Eintritt in die nächste Stufe.
Phase 1: Pool-Inventar und Zielarchitektur
Die bestehende XenServer-Landschaft wird strukturell erfasst: Pools, Storage Repositories (NFS, iSCSI, FC), Bonds und VLAN-Bindungen, PV/HVM-Charakteristik der Gast-VMs, eingesetzte XenTools-Versionen sowie Schnittstellen zu Citrix Virtual Apps and Desktops oder NetScaler.
Inhalt der Phase:
- Pool-Topologie (Master/Slave, Hochverfügbarkeits-Konfiguration, Shared-Storage-Pfade)
- Kategorisierung der Workloads: Xen-spezifisch (PV-Treiber, XenMotion-Abhängigkeiten) vs. plattform-agnostisch
- Bewertung der Kandidaten (XCP-ng, Proxmox VE, KVM, Hyper-V) nach Architekturnähe und Umstellungsaufwand
- Festlegung Zielarchitektur, Betriebsmodell und Abgrenzung zwischen Bestandsbetrieb und Zielplattform
Ergebnis ist eine Entscheidungsvorlage mit priorisiertem Migrationskorridor. Die Freigabe zur Pilotphase erfolgt formell. Weiterführend: Container-Orchestrierung.
Phase 2: Pilot-Pool und Migrations-Dry-Run
Ein Pilot-Pool auf der Zielplattform wird mit realitätsnahen VMs bespielt, um Werkzeugketten und Betriebsprozesse vor der produktiven Stufe abzusichern.
Inhalt der Phase:
- Aufbau eines eigenständigen Ziel-Pools mit produktivem Storage- und Netzwerk-Profil
- Überführung von Test-VMs per XVA-Export, Xen-Orchestra-Migrationsassistent oder virt-v2v (abhängig vom Zielsystem)
- Vergleich von I/O- und Netzwerk-Performance gegen die Citrix-Baseline unter Last
- Integration von Backup-Ketten, Monitoring-Agenten, Identity-Anbindung und Patch-Prozess
Typische Befunde: Treiber-Wechsel (PV → VirtIO), CPU-Feature-Masken, angepasste Boot-Parameter. Diese werden in Runbooks festgehalten, bevor Phase 3 startet.
Phase 3: Stufenmigration mit Parallelbetrieb
Die produktive Überführung erfolgt nicht am Stichtag, sondern in fachlich gruppierten Stufen. Bis zum Abnahmepunkt jeder Stufe bleibt die alte Umgebung rückfallfähig.
Inhalt der Phase:
- Stufen-Bildung entlang Anwendungsdomänen (Fileservices, Datenbanken, Applikations-Backends, Management-VMs)
- Cutover-Plan pro Stufe: Wartungsfenster, Reihenfolge, Kommunikation, definierter Fallback
- Migrationsdurchführung mit Abnahmekriterien je VM (Konsistenz, Performance, Funktion)
- Koexistenz: Citrix- und Ziel-Pool laufen parallel, bis die Stufe inkl. Nachbeobachtung abgeschlossen ist
Kritische Produktions-VMs migrieren erst, nachdem die Prozesse an weniger kritischen Workloads nachweislich funktionieren.
Phase 4: Pool-Abbau und Übergabe
Mit Abschluss der letzten Stufe wird der Citrix-Bestand kontrolliert abgebaut und die Zielplattform zur verbindlichen Basis erklärt.
Inhalt der Phase:
- Abnahme-Review: Vollständigkeit der migrierten VMs, Funktionsfähigkeit aller Schnittstellen, Performance-Baselines
- Rückbau des Citrix-Pools (License-Server, Hosts, Master/Slave-Rollen), Hardware-Umwidmung oder Ausmusterung
- Anpassung von Betriebshandbüchern, Runbooks und Notfallplänen auf die neue Plattform
- Wissenstransfer an das interne Team oder saubere Übergabe in den Managed Service
Mit dieser Phase endet das Projekt; der Regelbetrieb übernimmt mit dokumentiertem Betriebshandbuch.
Betriebsmodelle nach der Migration
Die Betriebsfrage beim Citrix-Exit hat eine Zusatz-Dimension: Wer verantwortet den darüberliegenden VDI-Stack (CVAD-Session-Hosts, Provisioning-Services, NetScaler, Profil-Management), falls CVAD weiterläuft? Das Betriebsmodell muss zwischen neuer Hypervisor-Plattform und fortbestehendem Citrix-Anwendungsstack eine saubere Schnittstelle ziehen. Drei Modelle bilden die Bandbreite.
Internes Team mit XAPI- und Xen-Orchestra-Kompetenz
Bei XCP-ng als Zielplattform bleibt die Kompetenz-Hürde niedrig – die gewohnte XAPI-Werkzeugkette ist erhalten. Bei Architekturwechsel (Proxmox, KVM) ist bewusster Kompetenzaufbau erforderlich.
Stärken:
Entscheidungshoheit über Pool-Layout, Patching, Kapazitätsplanung und VDI-Integration
Bei XCP-ng: investiertes XAPI-/Xen-Orchestra-Wissen bleibt produktiv
Kurze Wege zu CVAD- und NetScaler-Verantwortlichen, keine Service-Schnittstelle für VDI-nahe Entscheidungen
Geeignet, wenn:
- Bestehende Xen-/XAPI-Kompetenz (Continuity) oder bewusster KVM-Aufbau (Architekturwechsel) belastbar gedeckt ist
- Eine produktive Rufbereitschaft intern tragfähig bleibt
Managed Service – Hypervisor extern, Schnittstelle zum VDI-Stack vertraglich
BEKOM übernimmt den Plattform-Betrieb mit geregeltem Leistungsprofil: Pool-Monitoring, Patch-Zyklen, Incident-Response, Kapazitätsmanagement, Backup-Prüfung, Notfall-Wiederanlauf. Die Schnittstelle zum fortbestehenden CVAD-/NetScaler-Stack wird vertraglich festgelegt – typischerweise liegt die Hypervisor-Verantwortung bei BEKOM, die CVAD-Administration beim Kundenteam, gemeinsame Change-Fenster werden dokumentiert.
Stärken:
SLA-basierter Betrieb der XCP-ng- oder Proxmox-Plattform
Direkter Einstieg ohne Aufbau von Xen-Orchestra-/Proxmox-Spezialwissen
Patch-Koordination mit CVAD-Wartungsfenstern, Nacht- und Wochenend-Bereitschaft
Klare Rollenabgrenzung zur CVAD/NetScaler-Administration
Geeignet, wenn:
- Das interne Team mit CVAD-Administration und Fachbereichs-Betreuung ausgelastet ist
- Verfügbarkeits-Anforderungen über interne Bereitschafts-Möglichkeiten hinausgehen
- Compliance-/Audit-Anforderungen eine nachweisbare Betriebs-Dokumentation erwarten
Hybrides Betriebsmodell – Hypervisor extern, VDI intern
Die Aufgabenteilung folgt einer natürlichen Grenze: BEKOM betreibt die Hypervisor-Schicht, das Kundenteam behält CVAD, Profil- und Applikations-Stack. Architektur- und Planungshoheit bleibt beim Kunden, BEKOM übernimmt definierte operative Bereiche und Plattform-Rufbereitschaft.
Stärken:
Hypervisor-Betrieb ohne internen Aufbau von Plattform-Spezialwissen
CVAD- und NetScaler-Hoheit bleibt beim Kundenteam – VDI-Kompetenz verlässt das Haus nicht
Nacht-/Wochenend-Bereitschaft für die Plattform extern abgedeckt
Aufgabenteilung lässt sich stufenweise verschieben
Geeignet, wenn:
- Ein IT-Team vorhanden ist, das CVAD-Kompetenz aber nicht breit verteilen kann
- Die Zeit nach Go-Live mit externer Rückendeckung stabilisiert werden soll
BEKOM ist Partner für den Citrix-Exit
Ein Citrix-Hypervisor-Exit ist kein Standard-Hypervisor-Projekt – die Continuity-Option (XCP-ng) konkurriert mit dem bewussten Architekturwechsel, und der CVAD-Stack verlangt eine zusätzliche Entscheidungsebene. Drei Merkmale definieren die Zusammenarbeit mit BEKOM: unabhängige Bewertung zwischen Continuity und Architekturwechsel, durchgängige technische Verantwortung von der Pool-Analyse bis zum Regelbetrieb, und ein konsequent am deutschen Mittelstand ausgerichteter Vertrags- und Sprachraum.
Unabhängige Bewertung zwischen Continuity und Architekturwechsel
BEKOM vertreibt weder XCP-ng-, Vates-, Proxmox- noch Citrix-Lizenzen und bezieht keine Margen aus der Produktwahl. Die zentrale Bewertungsfrage lautet: Ist der Treiber Lizenzkosten und Roadmap-Sicherheit (dann spricht vieles für XCP-ng als Continuity), oder soll die Exit-Chance für einen strategischen Architekturwechsel genutzt werden (dann werden Proxmox, KVM oder Hyper-V zum Ziel)?
In der Projektrealität bedeutet das:
Bewertungsraster und Gewichtungen zu Projektbeginn schriftlich vereinbart, inklusive CVAD-/NetScaler-Integrations-Tiefe
Continuity (XCP-ng) und Architekturwechsel (Proxmox/KVM/Hyper-V) nach derselben Methodik bewertet
Jede Empfehlung wird gegen mindestens eine ernstzunehmende Alternative argumentiert
„Bei XenServer bleiben und Betrieb neu ordnen" ist ein zulässiges, wiederholt vorkommendes Ergebnis
Methodik und Rechenwege offen dokumentiert, für Dritte nachprüfbar
So entsteht eine Grundlage, die gegenüber Geschäftsführung, Gesellschaftern und Prüforganen belastbar ist – und den Unterschied zwischen Continuity-Migration und Architekturwechsel sauber offenlegt.
Durchgängige technische Verantwortung über XAPI und Cutover
Von der XenServer-Pool-Analyse in Phase 1 bis zum Regelbetrieb nach Phase 4 arbeiten dieselben technischen Rollen. Annahmen, Risiken und offene Punkte zur Xen-Architektur, zu PV-Treibern und zur CVAD-Schnittstelle gehen nicht zwischen Dienstleistern verloren.
Das heißt konkret:
Assessment-Team dokumentiert XAPI-Annahmen, Pool-Eigenheiten und CVAD-Abhängigkeiten direkt für das Pilot-Team
Dry-Run-Erkenntnisse (PV-zu-VirtIO-Treiber, Xen-Tools-Wechsel, Storage-Repository-Mapping) fließen ohne Umweg in die Migrationsplanung
Cutover-Team übergibt mit gemeinsam erstelltem Xen-Orchestra-Runbook in den Betrieb
Benannte technische Leitung durchgängig von Pool-Analyse bis Produktivsetzung
Beratungs-, Migrations- und Betriebsverantwortung unter einheitlicher Vertragsstruktur
Das senkt Schnittstellen-Verluste, die bei Citrix-Migrationen typisch sind – insbesondere dort, wo VDI-Spezialisten, Hypervisor-Experten und Netzwerk-Verantwortliche aus verschiedenen Dienstleistern kommen.
Mittelständischer Rechts- und Kommunikationsrahmen
Vertragsgestaltung, Ansprechpartner und Betriebssprache sind auf deutschsprachige Organisationen ausgerichtet. Keine Weitergabe an internationale Support-Tiers, keine Übersetzungsschleifen bei Eskalationen zum XenServer-Pool oder zur CVAD-Integration.
Im Alltag heißt das:
Vertrag, Leistungsbeschreibung und SLAs auf Deutsch, Rechtsraum Deutschland
Ansprechpartner mit Erfahrung in mittelständischen Führungsstrukturen und Citrix-Ökosystem-Hintergrund
Eskalationen erreichen verantwortliche Personen ohne Zeitzonenverzug – auch bei Produktiv-Vorfällen im Cutover
Termine mit Geschäftsführung, Betriebsrat, Fachbereichen und CVAD-Administratoren in gemeinsamer Arbeitssprache
Support- und Datenverarbeitung in Deutschland, ohne Weiterreichung an Offshore-Teams
Gegenüber Hyperscaler-Strukturen und internationalen Systemhaus-Ketten ist dieser Rahmen ein dokumentierbares Abgrenzungsmerkmal – besonders für Organisationen, in denen auch VDI-Profil-Daten und CVAD-Session-Inhalte verarbeitet werden.
Kostentreiber beim Citrix-XenServer-Exit reduzieren
Die größten Kostentreiber beim Citrix-XenServer-Exit entstehen durch parallele Lizenzzyklen während der Migrationsphase, ungeplante Kompatibilitätsprüfungen der CVAD-Infrastruktur und die Neubewertung von NetScaler-Abhängigkeiten im VDI-Stack.
Eigenbetrieb bedeutet hier Doppelaufwand: Während bestehende Citrix-Subscriptions weiterlaufen, müssen alternative Hypervisor-Plattformen evaluiert und produktiv getestet werden. Variable Aufwände entstehen durch unterschiedliche Migrationskomplexität je nach VDI-Integration und Storage-Backend. BEKOM strukturiert den Exit-Prozess über eine planbare Monatspauschale, die Assessment, Pilotbetrieb und schrittweise Migration umfasst. Die Kostenstruktur wird dadurch von unkalkulierbaren Projektphasen zu planbaren Betriebskosten verschoben, während der Hypervisor-Wechsel parallel zum laufenden Betrieb erfolgt.
Häufige Fragen zum Citrix-XenServer-Exit
Ist ein Citrix-Hypervisor-Exit für jede Organisation sinnvoll?
Nein. In Landschaften mit enger Bindung an Citrix Virtual Apps and Desktops, NetScaler-Integrationen oder spezifische Citrix-Orchestrierung kann ein Verbleib wirtschaftlicher sein als ein Wechsel. Die Entscheidung ergibt sich aus dem Gegenüberstellen von Migrationsaufwand, neuer Lizenzsituation und Abhängigkeitsgrad. Das Assessment liefert die belastbare Grundlage dafür – die Empfehlung kann Exit, Teil-Exit oder bewusst bleibender Betrieb lauten.
Wie unterscheiden sich XCP-ng, Proxmox VE, KVM und Hyper-V als Zielplattform?
XCP-ng bietet die kürzeste Strecke, weil Xen-Architektur, Pool-Konzept und Xen Orchestra erhalten bleiben. Proxmox setzt auf KVM/LXC und ist für Organisationen mit Linux-Schwerpunkt attraktiv, bringt aber ein neues Betriebskonzept. KVM/libvirt passt bei hoher Automatisierungs-Eigenleistung. Hyper-V ist dort sinnvoll, wo Landschaft und Skills bereits stark Microsoft-geprägt sind – tauscht aber einen Hersteller gegen den nächsten.
Welche Werkzeuge kommen bei der VM-Überführung zum Einsatz?
Auf Xen-nahen Zielen (XCP-ng) läuft die Migration über XVA-Export/Import oder den Xen-Orchestra-Migrationsassistenten. Bei Wechsel auf KVM-basierte Plattformen (Proxmox, libvirt) übernimmt virt-v2v die Formatumwandlung, flankiert von Treiber-Tausch (PV → VirtIO) und CPU-Feature-Anpassung. Für Hyper-V-Ziele kommen Microsoft-Werkzeuge oder Drittanbieter-Konverter zum Einsatz. Die Werkzeugwahl wird pro Zielplattform im Runbook definiert.
Was geschieht mit Citrix Virtual Apps and Desktops oder NetScaler-Integrationen?
Hypervisor-Ablösung und Citrix-Produktstack sind zwei Fragen. Citrix Virtual Apps and Desktops können prinzipiell auf einem neuen Hypervisor weiterlaufen – geprüft wird die offiziell unterstützte Kombination. NetScaler bleibt meist unverändert, da die Appliance-Rolle vom Hypervisor-Wechsel unabhängig ist. Bei Bedarf werden Alternativen zu Einzel-Komponenten im Assessment parallel bewertet und nicht im Migrationspaket erzwungen.
Kann der Citrix-Pool und die Zielplattform parallel laufen?
Ja, der Parallelbetrieb ist die Regel, nicht die Ausnahme. Während der Stufenmigration existieren Citrix-Pool und Ziel-Pool nebeneinander, inklusive geteiltem Storage- oder Netzwerk-Rückgrat nach Bedarf. Jeder Workload wechselt innerhalb eines definierten Cutover-Fensters, bleibt bis zur Abnahme rückfallfähig. Die Koexistenz wird bis zur Stilllegung des letzten Citrix-Hosts geplant, sodass kein Stichtagsrisiko entsteht.
Wie läuft ein bestehender Citrix-Hypervisor-Vertrag während der Migration weiter?
Laufende Subscription- oder Support-Verträge bleiben bis zum regulären Ablauf in Kraft und werden weiter genutzt. Der Migrationsfahrplan wird üblicherweise so gelegt, dass die Stilllegung vor der nächsten Vertragsverlängerung abgeschlossen ist. Kündigung oder Nicht-Verlängerung erfolgt erst nach belegter Außerbetriebnahme des Citrix-Pools. Vertragsrechtliche Fragen (Kündigungsfristen, Minderlaufzeiten) werden vor dem ersten Cutover geklärt.
Welche Rolle spielt das interne IT-Team im Migrationsprojekt?
Das interne Team bleibt durchgängig beteiligt. In Phase 1 liefert es Pool-Wissen, Workload-Prioritäten und bekannte Eigenheiten der bestehenden Umgebung. In Phase 2 erfolgt die Hands-on-Erprobung der Zielwerkzeuge gemeinsam. In Phase 3 wird die Aufgabenverteilung pro Stufe vertraglich fixiert. Das Zielbetriebsmodell wird mit dem Kompetenzprofil abgestimmt, sodass nach Produktivsetzung weder Überforderung noch Leerlauf entsteht.
Gibt es technische Risiken rund um PV-Treiber oder HA-Mechanismen?
Typische Themen: Paravirtualisierungs-Treiber aus Xen lassen sich nicht 1:1 auf KVM übernehmen, Gast-Betriebssysteme brauchen neue VirtIO-Treiber vor dem Cutover. Citrix-spezifische HA-Konzepte im Pool sind anders strukturiert als Proxmox-HA oder oVirt – Verfügbarkeits-Mechanismen werden neu konzipiert, nicht gespiegelt. Beides wird im Pilot-Pool validiert und in Runbooks dokumentiert, bevor kritische Workloads in die Stufenmigration gehen.
Was kostet das Citrix-Exit-Assessment bei BEKOM?
Das Assessment ist ein eigenständig beauftragtes Beratungsprojekt. Der Aufwand richtet sich nach Pool-Größe, VM-Anzahl, Integrationstiefe mit Citrix-Produkten und Detailgrad. Dem Auftrag geht ein unverbindliches Strategiegespräch voraus; danach entsteht ein schriftliches Angebot mit Phasenlogik, Abnahmekriterien und pro Phase ausgewiesenen Leistungen.
Kann BEKOM die bestehende Citrix-Umgebung weiterbetreiben?
Ja. Wenn das Assessment einen Verbleib empfiehlt, bietet BEKOM den Betrieb des bestehenden Pools als Managed Service an – mit Monitoring, Patch-Zyklen, Kapazitätsmanagement und SLA-Rahmen. Die Bewertung ist technologie-neutral; es gibt keine vertriebliche Motivation für einen Wechsel, wenn die Daten ihn nicht begründen.
Nächster Schritt: Citrix-Exit-Evaluierung
Die Citrix-Exit-Evaluierung beantwortet zuerst die Leitfrage Continuity oder Architekturwechsel und arbeitet danach den konkreten Umsetzungspfad aus. Der Einstieg ist ein unverbindliches Strategiegespräch zur aktuellen XenServer-Pool-Landschaft, zur CVAD-/NetScaler-Verzahnung und zu den realistischen Zielplattformen – ohne Folgeverpflichtung.
Das Citrix-XenServer-Exit-Assessment liefert eine systematische Bestandsaufnahme Ihrer aktuellen Hypervisor-Landschaft einschließlich CVAD-Abhängigkeiten und NetScaler-Integration. Sie erhalten Klarheit über Migrationskomplexität, alternative Plattformen wie XCP-ng oder Proxmox und deren Eignung für Ihren VDI-Stack. Die Empfehlung umfasst konkrete Architektur-Varianten, Überführungsstrategien und ein Service-Design für den schrittweisen Hypervisor-Wechsel ohne Unterbrechung der Desktop-Bereitstellung.
Strategiegespräch zur XenServer-Ausgangslage vereinbaren
Im Strategiegespräch klären BEKOM-Spezialisten mit dem Kundenteam Pool-Struktur, Edition, Vertragsstand, CVAD-Verzahnung und die Frage, ob Continuity (XCP-ng) oder Architekturwechsel (Proxmox, KVM, Hyper-V) strategisch priorisiert wird. Das Ergebnis ist eine erste fachliche Einordnung – ergebnisoffen.
Strukturiertes Citrix-Exit-Assessment durchführen
Im Assessment entstehen XenServer-Pool-Inventar, Abhängigkeitslandkarte inklusive CVAD-/NetScaler-Schnittstellen, Alternativen-Bewertung und dokumentiertes Zielbild. Die Entscheidungsvorlage enthält begründete Empfehlung, Risikoliste mit Schwerpunkt auf PV-Treiber und HA-Mechanik, und einen Phasenplan mit Cutover-Grenzen.
Pilot-Pool und XAPI-Cutover-Stufen begleiten
Nach Freigabe begleitet BEKOM die Umsetzung: Aufbau des Ziel-Pools, Dry-Runs mit Xen Orchestra, XVA-Export oder virt-v2v je nach Ziel, Stufenmigration mit Rückfall-Optionen. Die Beteiligungsform reicht von Beratung bis zur vollständig übernommenen Migrationsdurchführung – wahlweise mit anschließendem Managed Service für den Hypervisor; die Schnittstelle zum CVAD-Stack bleibt optional beim Kunden.