Mirantis Offers Managed VMware-to-Kubernetes Migrations to MOSK

The migration service addresses more than tooling

For organizations weighing a move away from VMware, choosing another platform is only part of the technical challenge. Teams also have to work out how existing workloads will move, how they’ll behave after the move, and who has the time and skills to manage the transition. Mirantis is adding hands-on migration services for workloads moving from VMware to Mirantis OpenStack for Kubernetes (MOSK), its Kubernetes platform built on OpenStack. The offer targets a practical obstacle: a migration tool can help transfer workloads, but it doesn’t by itself supply the people or experience to plan and carry out the work.

The service pairs a free assessment with access to Mirantis IT staff who can manage the migration. Product manager Cristian Klein said Mirantis had already offered migration tools; the new service adds the expertise to carry out the work. That distinction matters. For an IT team with limited experience in the target environment, the difficult questions often concern workload dependencies, sequencing, and how to handle problems that surface during a move. The company says it aims to move workloads without requiring customers to buy additional infrastructure, which may ease one source of friction for organizations evaluating a change. Klein said migrations take about five weeks on average, depending on the amount of data. That estimate gives customers a starting point, not a schedule they can safely apply to every estate.

Skills and compatibility remain part of the problem

The offer addresses a gap for IT teams whose VMware skills don’t automatically translate to operating Kubernetes at scale. Familiarity with virtual machines and hypervisors can help, but Kubernetes introduces its own operating model and demands. The move may therefore involve more than transferring an application from one place to another: teams need to understand how it will run, how it will be maintained, and which existing practices still apply.

Mirantis has also hardened open source software that can perform a role similar to VMware’s Virtual Disk Development Kit (VDDK), which Broadcom no longer makes available. Competing migration vendors had relied on VDDK to move workloads off VMware. That makes the availability of an alternative relevant to the mechanics of migration, though it doesn’t answer the broader question of how much work a customer’s particular applications will require. Similar migration projects typically turn on the details of the source workloads and the destination environment, so a tool’s capabilities are only one part of the assessment.

Here's the thing: offering both migration software and hands-on staff makes Mirantis’ pitch more concrete for customers who don’t want to assemble the process themselves. It also gives the company a role in the work that follows from its platform sale. The value will depend on whether the assessment produces a realistic plan and whether teams can operate the migrated workloads once the service engagement ends.

VMware customers face different choices

Mirantis’ announcement arrives as customers assess the cost and scope of VMware deployments under Broadcom. Broadcom is positioning VMware Cloud Foundation 9 as an integrated platform combining hypervisors with virtual storage and networking, while charging higher licensing fees. Some organizations may adopt that platform; others are considering moving workloads elsewhere or placing new applications on a different infrastructure. Those choices reflect different needs and constraints. A customer may decide that keeping an existing environment is the least disruptive course, while another may see a change in platform as a chance to alter how future applications are deployed.

There’s no single migration path for an existing estate. Teams need to decide whether older, largely monolithic applications should remain on virtual machines or be rewritten for cloud-native operation. Rewriting can change how an application is built and maintained, so it isn’t automatically a simpler alternative to moving it intact. Klein noted that many organizations still rely on a hypervisor to isolate applications, even as they add Kubernetes environments. That combination points to a gradual transition for many teams: different kinds of workloads may call for different ways of running them.

The operational burden doesn’t disappear

Broadcom’s licensing changes may push more teams to deploy Kubernetes, but the operational skills gap remains. Klein said AI tools are lowering the engineering effort required to deploy Kubernetes clusters. That could make adoption easier, especially for teams that have found the initial setup demanding. But getting a cluster running is only one part of operating a platform. Teams still need to manage the workloads and systems they’ve chosen to run, and a larger mix of platforms can add work even when staffing stays the same.

This is more significant than it looks: reducing the effort to get started doesn’t necessarily reduce the effort of running the environment over time. If you're working in this space, the useful question is whether the people responsible for a migration will also be prepared to support what comes after it. (And this is the part most people overlook.) A service that helps move workloads can lower the barrier to the first step, but customers still need a plan for ongoing ownership, support, and skills.

What will determine MOSK’s appeal

The practical test for MOSK will be whether organizations can move priority workloads within their existing infrastructure and sustain them afterward. Mirantis’ average migration estimate and promise to avoid additional infrastructure purchases address two immediate concerns, but they don’t establish how every workload will fare. Customers will need to judge the service against their own application mix, available staff, and tolerance for change. The numbers here are underwhelming as a universal guide: an average duration can help frame a discussion, but it can’t substitute for a workload-specific assessment.

As Kubernetes expands across legacy applications and AI workloads, migration services may help teams get started. The harder question is what happens after the move. Organizations that can match each workload to an appropriate operating model may find a path through the transition; those that treat migration as a one-time transfer could discover that the work has shifted rather than ended. More options. More operational choices to own.