TL;DR for CIOs/CTOs: If the SAP systems in your organisation run on SUSE Linux Enterprise Server for SAP Applications - which, in Poland, applies to the majority of environments - then KVM (Kernel-based Virtual Machine) is already included in your subscription. It is natively certified by SAP for S/4HANA and HANA (SAP Note 1122387). Following Broadcom’s VMware licensing changes, the decision to “pay twice” has stopped being neutral - it has moved into the category of a question the board is entitled to have answered.
Starting point: what changed in 2024-2026
Broadcom’s acquisition of VMware (November 2023) changed the licensing model in a way that, for most SAP organisations in Poland, translates into a double-digit increase in the annual bill. In practice:
- The end of standalone products - vSphere Standard, vSphere Enterprise Plus, vSAN and NSX as separate SKUs have been discontinued. Clients now purchase a bundle (VMware Cloud Foundation or VMware vSphere Foundation) rather than individual components.
- Per-core subscription, not per-CPU - a minimum of 16 cores per CPU as the billing unit, regardless of the physical server configuration.
- The end of perpetual licences - clients who for years paid only for support now face a choice: subscribe to the new model, or forgo security updates.
- Price increases - depending on configuration, market signals point to a three- to tenfold increase in the annual cost of maintaining the same platform.
For an SAP environment where a single cluster may span dozens of production cores plus QA, dev and sandbox environments, this means a growth in a budget line that no one was planning six months ago.
The other side of the equation, worth seeing
In the same organisation where the VMware bill has just increased, there is most likely already an operating system for which you have been paying for years - SUSE Linux Enterprise Server for SAP Applications. This is today the dominant Linux distribution under SAP in Poland, partly due to the long history of the SAP-SUSE partnership, and partly because SAP recommends it in typical HANA scenarios.
A less well-known fact: the SLES for SAP subscription includes the right to run KVM as a production hypervisor, including virtualisation of critical systems. No additional fee. No separate licence. This is not “free Linux” - it is part of a package you have already purchased.
The key element missing from most discussions about “VMware alternatives”:
SAP Note 1122387 - Linux: SAP Support in virtualized environments explicitly lists KVM as a certified hypervisor for SAP workloads, including S/4HANA and SAP HANA, on SLES for SAP.
This is not an experiment, a hobby project, or a decision taken “at your own risk”. It is a certified pathway that SAP supports under standard SLA terms.
”But does KVM have what VMware had?”
That is the right question to ask. Let us answer it factually, feature by feature:
| Production feature | VMware vSphere | KVM on SLES for SAP |
|---|---|---|
| Live migration of virtual machines | vMotion | libvirt + virsh migrate / live block migration |
| High availability (HA) | vSphere HA | Pacemaker + Corosync (part of SLES HA Extension) |
| Snapshots and backups | VMware Snapshots | qcow2 snapshots, integration with backup tools (Veeam, Bareos, SEP) |
| Central management | vCenter | SUSE Manager / Cockpit / SUSE Virtualization (based on Harvester) |
| Storage replication | vSAN, SRM | DRBD, Ceph, array-level replication |
| Monitoring and performance | vRealize | Prometheus + Grafana, SAP Host Agent, SUSE Manager |
| Vendor support | Broadcom | SUSE (24/7, Polish first-line support available through partners) |
This list is not exhaustive. We also fairly acknowledge areas where VMware still holds a tooling advantage - for instance, the maturity of the vCenter interface for an administrator who has worked with it for fifteen years. That is genuine value, which should not be dismissed.
But at the functional layer in which SAP operates - spin up a machine, allocate resources, live-migrate it to another host, take a snapshot, recover after a failure - KVM has closed this gap over the past several years.
Why we are confident: a brief operational history
The first production SAP deployments on KVM in Poland date back to 2018. Red Hat and SUSE jointly maintained KVM certification for SAP from the moment SAP began treating Linux as the platform of first choice for HANA (2014-2015). Six years later, KVM runs substantial production workloads - from finance, through retail, to public administration across the EU.
Within the SAP Basis team at SNOK, we observe these deployments from the technical side. A single, well-designed KVM environment for S/4HANA can support a dozen or more application and database instances with SLA parameters comparable to an equivalent VMware environment - at zero hypervisor licensing cost.
“The question we hear from IT directors today is no longer ‘can KVM cope’. It is ‘what exactly will change in our day-to-day operations after migration’. That is a healthy shift - a conversation about operational risk, not about ideology.” - Jarosław Zdanowski, Partner responsible for SAP Basis and Cybersecurity at SNOK
Three layers of the decision worth separating
Most organisations we speak with approach this decision in a single dimension - “it’s expensive, let’s find something cheaper”. That is too narrow a view. A sound analysis covers three layers:
Layer 1. Financial
A concrete five-year TCO comparison: the VMware subscription under the new model (with projected growth) versus a one-off migration cost to KVM plus zero hypervisor cost in subsequent years. For a mid-sized SAP environment in Poland, the difference over five years typically falls in the range of one to several million PLN.
Layer 2. Strategic risk
The question boards are asking themselves today: to what extent is it acceptable, over the coming decade, for critical systems to depend on a single vendor that has just undertaken the most profound change to its business model in its history? This is not an ideological question. It is a question about diversifying technology risk - the same question a sensible CFO asks about financial providers.
Layer 3. Operational
The least visible, and the most important in practice. Migration means that a team that has operated VMware for ten years will now operate KVM. This requires: a training plan, changes to runbooks, verification of integration with backup systems, monitoring, and automation. This is real work and should not be minimised in a board presentation.
How we approach such migrations
For the sake of transparency - this is not a sales pitch, but a description of the method:
- Discovery (1-2 weeks) - mapping the current VMware environment, an inventory of machines running SAP, a workload profile, and an audit of SUSE licences with respect to KVM entitlements.
- Feasibility and TCO analysis (1-2 weeks) - a financial and operational comparison of two scenarios: remaining on VMware versus migrating to KVM. Without an automatic recommendation - the decision remains yours.
- PoC on a non-production environment (2-4 weeks) - one or two SAP instances moved to KVM, verification of backup, HA and monitoring processes, and integration with your existing Solution Manager / Cloud ALM.
- Production migration plan (implementation phase) - only if the decision is “yes”. A sequence of maintenance windows, a rollback plan, and knowledge transfer to your team.
In most cases, the entire effort fits within a single project budget line, rather than a recurring operating cost. This is precisely the model that changes the maths: a one-off investment instead of a subscription that grows year after year.
When KVM will not be the right recommendation
For this article to remain honest - there are scenarios in which staying with VMware is the correct decision:
- Your organisation makes intensive use of advanced vSAN, NSX and SRM features and has no plans to replace them with native solutions.
- The SAP environment is in the middle of an active transformation (S/4HANA conversion, cloud migration) - adding another platform change within the same timeframe raises risk beyond an acceptable threshold.
- The internal IT team lacks Linux expertise and the organisation does not wish to build it or permanently outsource it.
In each of these cases, the right decision is to renegotiate terms with Broadcom (possible, though difficult) or to plan the migration for a later window - rather than forcing change for its own sake.
What is worth doing this quarter
One step that costs nothing yet gives you a full basis for a board discussion:
Check the scope of KVM entitlements as a production hypervisor within your SUSE Linux Enterprise Server for SAP Applications contract. In most cases, you will find that this right already belongs to you. It is a single phone call to your SUSE account manager or the partner managing your subscription.
A second step, if the first confirms the entitlement: commission an independent TCO and feasibility analysis. Independent - meaning not from a VMware vendor, nor from one of the larger integrators for whom maintaining the status quo is more profitable than changing it.
At SNOK, we conduct such analyses regularly. The format is consistent: two to three weeks of work, a board presentation with three scenarios (remain, partial migration, full migration), figures based on your actual environment rather than vendor benchmark slides.
The decision always remains yours. But it is worth making it on the basis of your own data, rather than someone else’s assumptions.
Related materials
- SAP Basis and SAP security - SNOK services
- SUSE - SNOK technology partner (Gold)
- SecurityBridge in SAP defence architecture
Let’s talk
If this topic concerns your organisation, we are available within 48 hours. Two hours of a no-obligation conversation with our SAP Basis engineer. No sales presentation, no slides. Questions, answers, a decision map.