Mirantis Offers a Five-Week Path from VMware Workloads to Kubernetes
For organizations weighing a move away from VMware, the hard part may be less about choosing a destination than finding the people who can carry out the migration. Mirantis is addressing that gap with a service that pairs a free assessment with hands-on moves from VMware environments to Mirantis OpenStack for Kubernetes (MOSK). The offer reflects a practical problem in infrastructure planning: selecting a platform is only the start, while transferring workloads and keeping them usable takes time, coordination and expertise. A free assessment can help a customer understand the scope before making a commitment, though its value will depend on how clearly it identifies the work, risks and staffing needs.
The target is Kubernetes clusters running on OpenStack. Mirantis product manager Cristian Klein says the company previously offered migration tools; the new service makes its own IT teams available to plan and manage the work. Mirantis estimates a typical migration takes about five weeks, depending on how much data is involved, and aims to complete it without requiring customers to buy additional infrastructure. That estimate gives prospective customers a starting point, not a guaranteed schedule: data volume is only one factor, and application dependencies or internal approval processes can also affect the sequence of work. The infrastructure claim is similarly specific to the proposed service; organizations will still need to assess their own capacity and requirements.
Migration tooling and execution
One technical hurdle is access to VMware’s Virtual Disk Development Kit (VDDK), which Broadcom no longer makes available. Other vendors had relied on it to support migrations away from VMware. Mirantis says it has hardened open source software that can provide a similar capability, alongside the staff support included in its service. The change matters because migration tools often depend on access to the source environment, and losing a familiar component can force providers to adapt their methods. Mirantis’ description presents its software as an alternative for this task, but the article doesn’t specify which workloads it supports or how the method compares across different customer environments.
That combination matters because tools alone don’t solve the skills problem. Many teams with deep VMware experience haven’t yet built the expertise to migrate workloads to open source platforms or operate Kubernetes at scale. A migration involves more than copying virtual machines: teams need to understand how applications are configured, what they depend on, and how they’ll be managed after the move. Those demands can make an apparently straightforward platform change a substantial operational project. Klein says the assessment is intended to help organizations understand the work involved before committing to a migration. Here's the thing: a clear plan can reduce surprises, but it can’t substitute for deciding who will own the new environment once the migration team leaves.
The service therefore addresses two related constraints: technical execution and staff capacity. Bringing in an experienced team may help customers make progress while their own engineers continue running existing systems. It may also give those engineers a chance to learn the new environment during the project, although the article doesn’t describe a formal training component. For buyers, that distinction matters. A completed migration is a milestone; the ability to operate, troubleshoot and update the destination platform is an ongoing responsibility.
Choices for existing applications
Broadcom is positioning VMware Cloud Foundation (VCF) 9 as a more integrated platform, combining hypervisors with virtual storage and networking services. Its higher licensing costs are leading some organizations to consider moving workloads elsewhere, while others may keep existing systems in place and steer new applications to a different platform. Those are different responses to the same pressure. A full migration seeks to change the underlying environment, while a split approach can limit immediate disruption but leave teams responsible for supporting more than one platform.
The economics aren’t determined by licensing alone. Moving workloads takes engineering time, and the destination has to meet the needs of the applications and the people who operate them. An organization weighing a move will need to compare the ongoing cost of its current arrangement with the effort of migration and the work of supporting the replacement. The article doesn’t provide a cost comparison, so the service’s appeal rests partly on whether an assessment helps customers make that calculation with their own requirements in view. The numbers here are underwhelming as a basis for a broad cost conclusion: a five-week estimate and no additional infrastructure purchase don’t establish what the whole transition will cost.
Those decisions depend in part on the applications themselves. Legacy software may remain monolithic and continue running in virtual machines, or teams may choose to rewrite it for cloud-native operation. Klein observes that many organizations still rely on hypervisors to isolate applications, so a move to Kubernetes doesn’t automatically mean abandoning virtualization. That nuance is easy to miss: Kubernetes can become part of the operating model while virtual machines remain useful for applications that aren’t ready, or aren’t suited, to be reworked.
Rewriting an application can change how it’s deployed and maintained, but it also adds work beyond the platform migration. Keeping it in a virtual machine may preserve a familiar boundary, though it won’t by itself resolve every dependency or operational constraint. Organizations may therefore need to make choices workload by workload rather than treating the move as a single switch. A staged approach can spread the effort over time, but it also asks teams to manage the old and new environments together for a period. And yet, that complexity may be preferable to forcing applications into a design their owners can’t support.
More platforms, limited staff
The broader shift is toward more Kubernetes use, including for established applications and newer AI workloads. AI tools may lower the engineering effort needed to deploy Kubernetes, but they don’t erase the operational demands of running clusters across an expanding mix of platforms. Automation can help with repeatable tasks, but organizations still need people who can decide how systems should be configured, recognize when something has gone wrong and take responsibility for recovery. A faster setup doesn’t automatically make a service easier to operate over time.
That matters especially when a team is adding a platform while supporting applications that can’t move at the same pace. More options can give IT leaders flexibility, but every environment brings its own processes and skills requirements. If you're working in this space, the useful question isn’t only whether a workload can run on Kubernetes; it’s whether your team can keep it reliable after the migration work is done. The operational burden may be less visible in a platform comparison than licensing or infrastructure, yet it shapes whether the change will hold up in practice.
That leaves IT leaders balancing licensing choices, application constraints and the capacity of their teams. Mirantis’ service offers one route for moving VMware workloads to MOSK, with an expected migration timeline and an assessment up front. Its appeal will depend on the fit between that service and each organization’s workloads, timeline and internal skills; the supplied details don’t establish that every VMware environment is a match. The longer-term challenge is building the operating skills to manage a more varied infrastructure without assuming that staffing will grow at the same pace. The migration itself is only one phase. Keeping the new platform useful after the handover is the test that matters.
