.png){kind=logo}
Exit VMware without buying new risk, new debt, and new lock-in
Enclaive macht aus der erzwungenen Migration eine weichenstellende Modernisierung: mit einer Landing Zone, die von Grund auf sicher konzipiert ist und auf der Plattform Ihrer Wahl läuft.
FÜR SUSE RANCHER, RED HAT OPENSHIFT, MANAGED KUBERNETES UND SOUVERÄNE EU-CLOUDS. Erfordert Keine Anpassungen von ANWENDUNGEN UND TOOLs.
IN IHREM BEVORZUGTEN TEMPO
Die meisten VMware-Exit-Projekte stehen durch den festen Renewal-Termin unter einem hohen Druck. Doch wer unter Zeitdruck migriert, läuft Gefahr, mit der Lösung eines alten Problems gleich drei neue ins Haus zu Holen.
Neue Security-Schulden
Eine unter Zeitdruck aufgesetzte Kubernetes-Plattform bringt oft mehr privilegierte Zugriffsmöglichkeiten mit als die Infrastruktur, die sie ersetzt: für Cluster-Administratoren, Cloud-Administratoren und den Support des Providers. Security wird auf „Phase zwei“ verschoben – und Phase zwei konkurriert schon bald mit der nächsten Deadline.
Modernisierungssteuer
Jeder Workload, der nicht migriert werden kann, verlängert die Lebensdauer der VMware-Umgebung. Regulierte und besonders sensible Systeme bleiben außen vor oder müssen aufwendig neu konzipiert werden. Der Parallelbetrieb zieht sich in die Länge, zwei Plattformen verursachen gleichzeitig Kosten – und die erhofften Einsparungen schrumpfen.
Lock-in - nur wonanders
Wer die neue Plattform an das KMS und die Managed Services eines einzelnen Cloud-Providers bindet, schafft dieselbe Abhängigkeit, die mit dem VMware-Exit eigentlich überwunden werden sollte, jetzt bei Services, Infrastruktur und sogar der Kontrolle über die Verschlüsselung. Spielraum haben Sie nur, wenn ein Wechsel tatsächlich möglich ist.
Das gilt unabhängig davon, ob Ihre gesamte Infrastruktur strengen regulatorischen Vorgaben unterliegt oder nur einzelne Workloads besonders schützenswert sind: Die Kundendatenbank eines Händlers oder die Pricing Engine eines Logistikunternehmens stößt bei der Migration auf dieselben Hürden wie das Kernsystem einer Bank.
Eine Landing Zone, bei der Security von Anfang an integriert ist – und nicht erst in Phase zwei
Enclaive verankert Confidential Computing direkt in der Migration. Workloads werden von Beginn an auch während der Verarbeitung verschlüsselt, Zugriffe an verifizierte Workload Identities statt an Personen und langlebige Secrets gebunden. Und die Nachweise, die Ihre Auditoren benötigen, entstehen automatisch im laufenden Betrieb der Plattform.
Pods laufen gekapselt als Confidential VMs. Cluster-Administratoren, Cloud-Administratoren und der Support des Providers können nicht im Klartext auf die Daten der Workloads zugreifen – ein Schutzniveau, das die meisten Virtualisierungsumgebungen bislang nicht bieten.
Kundendaten, Finanzsysteme und andere besonders schützenswerte Workloads können gemeinsam mit der übrigen Umgebung migriert werden. Verschlüsselung während der Verarbeitung und Keys unter Ihrer Kontrolle beseitigen zentrale Hürden, die einer Migration dieser Systeme sonst im Weg stehen. Keine fragmentierte Infrastruktur, keine zurückbleibende VMware-Insel.
Bringen Sie Ihre eigenen Keys mit und behalten Sie die Kontrolle darüber – geschützt in einem virtuellen HSM statt gebunden an das KMS eines einzelnen Cloud-Providers. Dieselbe Sicherheitsarchitektur lässt sich auf Rancher, OpenShift, Managed Kubernetes, souveränen EU-Clouds oder Ihrer eigenen Hardware betreiben. Die Möglichkeit eines weiteren Exits ist von Anfang an mitgedacht.
Attestierungsstatus, Key-Verwahrung und Zugriffskontrollen liefern die erforderlichen Audit-Nachweise direkt mit. Der erste migrierte Workload bringt damit bereits seine Compliance-Nachweise mit – statt nur zu versprechen, sie später nachzureichen.
Bestandsaufnahme und Baseline
Erfassen Sie Ihre bestehende Infrastruktur, identifizieren Sie regulierte und besonders schützenswerte Workloads und richten Sie auf Ihrer Zielplattform eine Landing Zone ein, in der Confidential Computing von Anfang an integriert ist.
Erster produktiver Workload
Migrieren Sie einen relevanten Workload vollständig – produktiv, attestiert und mit allen Policies und Audit-Nachweisen. Diese klare "Definition of Done" schafft die Blaupause für alle weiteren Schritte und reduziert die Risiken der anschließenden Migration.
Migration factory
Nutzen Sie diese Best Pratices, um Welle für Welle die gesamte Umgebung zu migriere. Blueprints und Policy Templates stellen sicher, dass jeder Cluster dieselbe Baseline erfüllt – damit Welle zehn genauso sauber umgesetzt wird wie Welle eins.
VMware abgelöst
Damit die Rechnung Ihres CFO aufgeht
Den Anstoß für den Exit gaben die Lizenzkosten. Wie Sie die Migration angehen, entscheidet darüber, ob die geplanten Einsparungen in der Praxis realisiert werden können – oder von der Migration selbst aufgezehrt werden.
Kürzerer Parallelbetrieb. Einer der größten versteckten Kostenfaktoren jedes Exits ist der gleichzeitige Betrieb zweier Plattformen. Wenn auch regulierte und besonders schützenswerte Workloads im Rahmen der regulären Migrationswellen umziehen, verkürzt sich diese kostspielige Übergangsphase.
Keine Extra-Kosten für den Schutz der neuen Plattform. Eine Landing Zone mit integrierter Security reduziert den Bedarf an teuren Einzellösungen, zusätzlichen Security-Systemen und nachträglichem Audit-Aufwand, die bei ungeschützten Kubernetes-Umgebung unvermeidlich sind.
Kosten, die verhandelbar bleiben. Da die Plattform Distributions- und Cloud-agnostisch ist und Ihre Keys unter Ihrer eigenen Kontrolle bleiben, können Sie auf der neuen Plattform jederzeit den Provider wechseln. Jeder Anbieter – auch Enclaive – kalkuliert damit im Wissen, dass Sie jederzeit gehen können.
Ergänzt Ihre Zielplattform, ohne sie zu ersetzen
nclaive ist weder eine weitere Kubernetes-Distribution noch eine weitere Cloud, die Sie evaluieren müssen. Stattdessen dient sie als einheitliche Security- und Sovereignty-Baseline, die Ihre Workloads auf jedem gewählten Exit-Pfad begleitet – und die sich nahtlos in Ihre Tools und Prozesse integriert.
Unterstützung Ihrer bevorzugten Linux- und Kubernetes-Distributionen, darunter SUSE Rancher, Red Hat OpenShift und Managed Kubernetes auf AWS, Azure und Google Cloud
Souveräne EU-Clouds wie IONOS und STACKIT sowie Ihre eigene On-Premises-Hardware
Bestehende HSM-Infrastrukturen und Secrets Manager können weiterbetrieben werden – für eine schrittweise Migration ohne Rip-and-Replace
Terraform, Ansible und CI/CD-Pipelines funktionieren unverändert weiter; die Provisionierung erfolgt API-basiert
Deployment in Ihren eigenen Cloud-Accounts unter Beibehaltung Ihrer bestehenden IAM-, Logging- und Budget-Prozesse
Das sind die Kennzahlen, auf die dieser Ansatz einzahlt – und nach denen Ihr Vorstand bei jedem wichtigen Meilenstein fragen wird.
Zeit bis zum ersten produktiven Workload auf der neuen Plattform
Dauer und Kosten des Parallelbetriebs
Anzahl privilegierter Zugriffswege vor und nach der Migration
Anteil regulierter Workloads, die migriert werden, statt auf VMware zurückzubleiben
Zeitaufwand für die Erstellung eines vollständigen Audit-Nachweises
Kosten und Aufwand eines erneuten Provider-Wechsels – uns eingeschlossen
Hierher führt Ihr Exit – eine identische Umgebung, aber jetzt mit einer starken Baseline, die zwischen Providern portabel ist.
VMs lassen sich ohne Neuentwicklung migrieren. Sie landen aber nicht eins zu eins auf der neuen Plattform, sondern von Anfang an geschützt.
Containerisierte Workloads landen auf Confidential Kubernetes-Systemen mit etablierten Standard-Distributionen.
Eine zentrale Konsole für alle Cloud-Umgebungen, auf die sich Ihre Infrastruktur nach der Migration verteilt.
Ihre Keys bleiben vor, während und nach der Migration unter Ihrer Kontrolle. Genau das hält auch die Kosten eines künftigen Provider-Wechsels niedrig.
Was Migrationsteams wissen möchten
Wie viel Zeit nimmt ein VMware-Exit dieser Art in Anspruch?
Das hängt von der Größe Ihrer Infrastruktur und davon ab, wie viel Zeit Ihnen bis zum nächsten Renewal-Termin bleibt. Deshalb nennen wir hier keine verbindliche Zahl. Was wir sagen können: Der Migrationsplan wird von Ihrem Stichtag aus rückwärts geplant. Wir migrieren frühzeitig einen ersten produktiven Workload, der dann als Proof Point für das weitere Vorgehen dient. Und dank Lift-and-Shift muss kein Workload auf ein vorheriges Refactoring warten. Bringen Sie Ihren Termin und die Eckdaten Ihrer Infrastruktur mit – dann können wir bereits im ersten Gespräch einen realistischen Ablauf skizzieren.
Was kostet das im Vergleich zu einem Renewal?
Die Kalkulation basiert auf drei Faktoren: Ihrem bestehenden Renewal-Angebot, den laufenden Kosten der Zielplattform und den Kosten der Übergangsphase. Die Entscheidung für Enclaive strahlt auf die beiden letzten Faktoren aus: durch einen kürzeren Parallelbetrieb, eine von Anfang an integrierte Security-Architektur und ein Preismodell, das verhandelbar bleibt, weil ein späterer Wechsel möglich und wirtschaftlich bleibt. Im ersten Gespräch können wir diese drei Kostenblöcke für Ihre konkrete Infrastruktur gegenüberstellen – auf Basis Ihrer tatsächlichen Broadcom-Renewal-Konditionen.
Wir haben einen festen Renewal-Termin. Wie verändert das die Planung?
Die Deadline bestimmt die Reihenfolge. Wir planen vom Stichtag aus rückwärts: Landing Zone und erster produktiver Workload kommen früh, sodass das Vorgehen validiert ist, solange noch zeitlicher Spielraum besteht. Anschließend werden die Migrationswellen auf die verbleibende Zeit abgestimmt. Da sich bestehende Workloads unverändert per Lift-and-Shift in Confidential VMs überführen lassen, zwingt Sie die Deadline nicht zu einem riskanten Refactoring.
Ersetzt Enclaive Rancher, OpenShift oder unsere geplante Managed-Kubernetes-Plattform?
Nein. Die Wahl einer Plattformen ist und bleibt Ihre Entscheidung. Enclaive ist keine weitere VMware-Alternative, die Sie zusätzlich evaluieren müssen. Enclaive ergänzt die Confidential Runtime, Workload Identity, Key-Verwahrung und Audit-Nachweise: also die Sicherheitsebenen, die diese Plattformen allein nicht bereitstellen.
Unsere Anwendungen sind nicht containerisiert. Müssen wir sie vor der Migration refaktorieren?
Nein. Ihre bestehenden Workloads können unverändert in Confidential VMs migriert und später nach Ihrem eigenen Zeitplan containerisiert werden. Die Security-Baseline bleibt in beiden Fällen dieselbe.
Wir erwägen eine souveräne EU-Cloud. Ändert das etwas?
Unsere Baseline lässt sich auch auf IONOS, STACKIT und anderen europäischen Cloud-Plattformen bereitstellen. Und weil Ihre Keys unter Ihrer Kontrolle bleiben, ist auch ein späterer Wechsel zwischen Hyperscaler und souveräner Cloud ohne Re-Design Ihrer Security möglich.
Addieren wir nicht einfach einen neuen Hersteller, um einem Hersteller zu entkommen?
Auf den ersten Blick lautet die ehrliche Antwort: ja. Sie lösen sich von einem Anbieter und führen eine neue Technologie ein. Entscheidend ist jedoch, was sich dadurch strukturell verändert: Sie migrieren auf eine flexible Plattform und heben gleichzeitig das Sicherheitsniveau innerhalb Ihres bestehenden Betriebsmodells auf eine neue Stufe. Da die Lösung distributions- und Cloud-agnostisch ist und Ihre Keys unter Ihrer Kontrolle bleiben, sind auch die Kosten eines späteren Wechsels von Enclaive von Anfang an niedrig gehalten.
Zeigen Sie uns Ihr Renewal-Angebot
Wir beziffern für Sie gerne auch den Exit-Aufwand und die Kosten des Security-Upgrades. Dann entscheiden Sie – mit allen drei Faktoren auf dem Tisch.
