Rancher, Harvester and AKS: Running VMs and Containers After VMware

What runs VMs and containers after VMware?

SUSE Rancher with SUSE Virtualization (Harvester) runs both virtual machines and containers on your own hardware, and AKS runs containers on Azure or on Azure Local. Harvester gives you a hypervisor for the VMs that cannot change, while Rancher and AKS give you Kubernetes for the applications that can. Neither removes the need for a team, or a partner, that can run Kubernetes properly.

This post covers the Kubernetes branch of a VMware exit. Our guide to leaving VMware after Broadcom gives the full picture, and our post on choosing a route for each VMware workload decides which workloads belong here at all.

What are SUSE Rancher and SUSE Virtualization (Harvester)?

SUSE Rancher is a management platform for Kubernetes clusters. SUSE Virtualization, still widely known as Harvester, is open-source hyperconverged infrastructure (HCI) that runs VMs on bare metal. Harvester is built on Kubernetes, KubeVirt and Longhorn.

SUSE renamed both products in December 2024. Rancher became SUSE Rancher, and Harvester became SUSE Virtualization. The project's GitHub repository and documentation site still use the name Harvester, so this post uses both.

Rancher can import and manage several Harvester clusters alongside ordinary Kubernetes clusters, under Rancher authentication and role-based access control. That gives one console for VM hosts and container clusters, which matters to a small infrastructure team.

Which versions are current?

Harvester 1.7.x ships KubeVirt v1.6, Longhorn v1.10, Rancher v2.13 and RKE2 v1.34. The project has not published an equivalent component list for 1.9.0 in the upgrade documentation we checked.

Should you upgrade to Harvester v1.9.0 now?

No. The v1.9.0 release notes say that upgrading "is currently not recommended" because known issues can force VMs to shut down. The project plans fixes for v1.9.1. We recommend new deployments and upgrades target the maintained v1.8 or v1.7 lines until v1.9.1 is released and tested in a non-production cluster.

This caution matters more for a VMware exit than for a lab. The whole point of the move is to run production VMs, and an upgrade that can shut them down defeats it.

How does vm-import-controller move VMs off vSphere?

Harvester's vm-import-controller add-on imports VMs from VMware vSphere, OpenStack and OVA packages. It works in four steps for a vSphere source.

1. It shuts down the source VM.
2. It exports the VM's disks.
3. It converts the disks to raw images.
4. It creates Harvester VM images from the converted disks.

The process is offline. The source VM is down while its disks export and convert, so every import needs a maintenance window sized to the disk volume.

What are its limits?

The documentation lists several conditions that trip up first imports.

• The source VM name must be RFC1123-compliant. Check every VM name against that rule before you schedule imports.
• Scratch space should be twice the size of the largest VM you import.
• A VM without VMware Tools needs the forcePowerOff option or a manual shutdown before import. The documentation states this for v1.6.
• An imported VM needs an evictionStrategy set before live migration works. The documentation also states this for v1.6.

The controller moves the VM. It does not tell you whether the application inside still behaves the same, which is why we baseline each application before an import and re-test after it. Our post on proving every app still works after a VMware migration explains the method.

Can Azure manage Rancher clusters through Azure Arc?

Yes. Azure Arc-enabled Kubernetes works with any CNCF-certified Kubernetes cluster. Microsoft's validation programme lists SUSE Rancher RKE2 and K3s releases v1.31 to v1.33 as having passed its Arc conformance tests (page updated 8 April 2026).

Arc matters for a mid-market team because it connects on-premises clusters to Azure, so they sit alongside cloud resources. The team manages one estate, even when some workloads stay in your own building.

Check versions before you connect. Microsoft's validation list stops at v1.33, while Harvester 1.7.x itself ships RKE2 v1.34. Arc supports any CNCF-certified cluster, but the published conformance results do not yet name v1.34, so confirm support for any newer version before you rely on it.

AKS on Azure or AKS on Azure Local?

AKS on Azure is Microsoft's managed Kubernetes service in its own data centres. AKS on Azure Local brings the same experience to your hardware. You create clusters on Azure Local directly from Azure, through the portal, CLI or ARM templates. It uses Arc Resource Bridge, a custom location and an AKS operator extension, and Azure Local installs these automatically. You can create Windows or Linux node pools.

Microsoft groups AKS on Azure Local with AKS on bare metal (preview), AKS Edge Essentials and AKS on Windows Server under the name "AKS Hybrid and Edge".

The choice between Azure Local and Harvester for on-premises hosting comes down to your operating model. Azure Local is Microsoft's Hyper-V-based platform, managed through Azure Arc and priced per physical core plus any Azure services used. Microsoft lists it as eligible for Azure Hybrid Benefit. Harvester is open source and Kubernetes-native, and it sits under Rancher. A Microsoft-centric team with Windows Server skills will usually find Azure Local easier to run. A team already running Rancher will find Harvester more natural.

Do Windows containers on AKS work for legacy apps?

They work, within firm limits. Microsoft documents these for AKS Windows node pools:

The dates show the pace. Windows Server 2019 node pools have already lost AKS support, and Windows Server 2022 node pools have a fixed end date. Containerising a Windows application commits you to moving it onto each new Windows Server node version. That is fine for code you own and release often. It is a poor bargain for a vendor application nobody changes.

How does Harvester compare with other VMware alternatives?

The table uses only the facts we could confirm from each vendor's documentation or reputable trade press as of October 2026. A blank in our knowledge is marked "Not covered", which means we did not verify it, not that the feature is missing.

Harvester and OpenShift Virtualization share the same idea: KubeVirt runs VMs as Kubernetes objects next to containers. Azure Local and Nutanix keep a traditional hypervisor at the centre. Proxmox VE suits teams that want a Debian-based hypervisor with a built-in ESXi importer. The real shortlist for a Microsoft-aligned mid-market business is usually Azure Local or Harvester on-premises, with AKS in Azure for new services.

Real experience: moving containerised apps from VMware to Rancher

We have done this move for a client. An anonymised oil and gas company based in Scotland ran its own VMware infrastructure, including containerised applications. We moved those containerised applications from VMware to SUSE Rancher. The same project replaced the company's ERP with Dynamics 365 Finance & Operations and moved its other workloads, including the SQL Server estate, to Azure services.

Rancher suited the applications that were already containers. The rest of the estate took other routes, which is the pattern we expect in most exits. The oil and gas VMware exit case study covers the project.

When are containers the wrong answer?

Kubernetes is a strong platform, and it still fails as a default. We push back on containers in these cases.

• The application will not change again. Repackaging a stable vendor application into containers adds image builds and cluster upgrades with no business gain. An Azure VM or a Harvester VM is simpler.
• The application depends on the Windows host: GUI components, local services, privileged access or fixed source IPs. The AKS Windows limits above rule many of these out.
• The software vendor supports only a VM deployment. Running it in a container can void that support.
• The workload is a packaged ERP at end of life. Dynamics AX 2012 or NAV should be replaced with Dynamics 365, not containerised. Our post on AX 2012 and NAV on VMware explains why.
• Nobody in the team will own the cluster. A Kubernetes platform without an owner decays quickly.

Containers are the right answer for services you own and release often, Linux workloads that are already containerised, and new applications. They are not a better hypervisor.

Why does Kubernetes need a managed operating model?

A mid-market IT team often has a few infrastructure people who also look after networking and the service desk. Most of them know vSphere well. Kubernetes asks for a different and faster rhythm.

The version tables above show why. Rancher published three releases on a single day in September 2026. Harvester has three maintained lines, and its newest one carries an upgrade warning. AKS Windows node pool support depends on both the Windows Server base and the Kubernetes version. Arc validation lists specific RKE2 and K3s versions. Someone has to track all of this, test each upgrade and decide when to move.

We recommend a managed operating model before the first production workload lands. It should cover four things:

1. A named owner for each cluster, with an upgrade calendar tied to the vendor release and support dates.
2. A non-production cluster that receives every upgrade first.
3. Governance and monitoring through Azure Arc, so on-premises clusters sit in the same view as Azure resources.
4. A regression test baseline for each application, run after every platform upgrade, not only after the migration.

Some teams build this in-house. We think most mid-market teams are better served by a partner running the platform while their own people focus on the applications. Decide which model you want before the VMware renewal date forces the move. Broadcom's end of service for vSphere 8, vSAN 8 and NSX 4 on 11 October 2027 gives a hard outer limit for many estates.

How we help

Our VMware Exit service decides which workloads belong on Rancher, Harvester or AKS and which belong elsewhere. Agents assist with discovery and code analysis, and we build a cost model against your Broadcom renewal. We set a UI and regression test baseline before migration, re-test after cutover and provide an evidence pack. Our managed service can then run the platform.

The testing method comes from our agentic software delivery work. One anonymised client has every release AI-tested, including UI testing and Azure DevOps bug verification, and released more than 15 testing roles. That is release-testing experience rather than a migration, and the agentic release testing case study describes it.