Mirantis Offers Managed VMware-to-Kubernetes Migrations on MOSK
Migration help targets the skills gap
Moving VMware workloads to Kubernetes can require expertise many infrastructure teams don’t yet have. The challenge isn’t just choosing a destination: teams have to understand how existing applications depend on their virtual machines, storage, networks and operating processes, then determine how those dependencies will work after a move. Mirantis is addressing that gap with a migration service for organizations shifting workloads to Mirantis OpenStack for Kubernetes (MOSK), its Kubernetes platform built on OpenStack.
The service adds hands-on support to migration tools Mirantis already offered. Cristian Klein, a Mirantis product manager, said the company’s IT teams will manage migrations as part of a services engagement that starts with a free assessment. That initial review gives both sides a chance to examine the workload and the proposed move before committing to the work itself. The source doesn’t spell out what the assessment covers, so its value will depend on how clearly it identifies dependencies, risks and the effort required for each customer.
Mirantis says it aims to move workloads without requiring customers to acquire additional infrastructure. That promise could matter to organizations trying to control costs during a platform change, though it doesn’t mean a migration has no operational cost: staff still need to plan, validate and support the move. A migration takes about five weeks on average, Klein said, though the amount of data involved affects the schedule. An average can help set expectations, but it won’t tell a particular team how long its own migration will take.
VMware’s changing economics prompt reassessment
The service arrives as some organizations reconsider how much they run on VMware following changes to licensing under Broadcom. The company has promoted VMware Cloud Foundation 9, which brings hypervisors, storage and networking services together under a more integrated platform, at higher licensing fees. For customers, the practical question is whether the platform’s bundled capabilities justify the cost for the workloads they actually run. A change in licensing can prompt that review, but it doesn’t by itself settle which alternative is suitable.
Customers’ responses vary. Some are moving VMware workloads to other platforms; others may keep existing deployments while placing new applications elsewhere. The number of organizations making either choice isn’t clear, and the decision to migrate can be difficult even when teams have chosen a destination. Existing applications may have dependencies that aren’t obvious from an inventory, while the people who know how those systems behave may also be responsible for keeping them running. That makes a staged decision more likely to involve operational constraints alongside licensing costs.
Mirantis has also hardened open source software that offers a function similar to VMware’s Virtual Disk Development Kit (VDDK), which Broadcom no longer makes available. Other vendors had relied on VDDK to support migrations away from VMware. This detail points to a less visible part of platform choice: migration depends on tools that can read and transfer existing workloads, not only on the capabilities of the destination. If an established tool is no longer available, vendors and customers need another workable route. The article doesn’t specify how Mirantis’ software compares in capability or coverage, so organizations will need to assess whether it handles their own systems.
Workloads may move before they’re rewritten
A move to a new platform doesn’t automatically make a legacy application cloud-native. Organizations will need to decide whether to keep monolithic workloads on virtual machines or rewrite them for cloud-native environments. Those are different projects, with different demands on engineering time and operational planning. A platform migration can change where an application runs while leaving its architecture largely intact.
Klein said many still use a hypervisor to isolate applications, even as they adopt Kubernetes. That combination reflects the practical reality that organizations can adopt a new platform in stages: Kubernetes may host or manage parts of the environment while virtual machines continue to provide familiar isolation for applications that haven’t been redesigned. Here’s the thing: keeping an application intact can make a move more manageable in the short term, but it also means the new platform inherits some of the old application’s constraints.
That makes Kubernetes a potential destination for workloads that aren’t being redesigned. Licensing changes may lead more teams to deploy Kubernetes clusters, but VMware administrators don’t necessarily have the experience to operate those clusters at scale. Klein said AI is reducing the engineering expertise needed to deploy Kubernetes, though operating a wider mix of platforms still adds work. Deployment is only one part of the job; teams also have to understand how their environments behave and maintain them over time. The skills gap doesn’t disappear just because the first cluster is easier to create.
For teams weighing this path, the distinction matters. If you’re working in this space, ask whether the immediate goal is to move an application, change how it’s operated, or redesign it; those goals can overlap, but they don’t require the same plan. And this is the part most people overlook: a migration that preserves an application may reduce the disruption of changing platforms while leaving the longer-term modernization question open. That’s a trade-off, not a failure.
The test is operational, not just technical
Mirantis’ offer reflects a practical divide in infrastructure planning: teams may want to change platforms before they can change the applications running on them. This is more significant than it looks. Migration services can address a shortage of hands-on experience and help teams work through a move, but the service’s stated scope doesn’t answer every question about long-term operations, application fit or the effort required after workloads arrive.
The near-term test will be whether migration support can help organizations move workloads while keeping their existing infrastructure and already stretched operations teams in view. That means judging the work by more than whether data reaches a new platform. Teams will also need to understand what they’ll be responsible for once the migration is complete, and whether their current staff can manage the resulting mix of systems. A move can be technically successful and still leave an organization with more operational complexity.
That said, a migration doesn’t have to resolve every modernization decision at once. Organizations can treat it as one step in a longer process, provided they’re clear about what the move changes and what it leaves in place. The useful question isn’t simply whether VMware workloads can run elsewhere; it’s whether the destination, support model and skills available make that choice workable for the applications involved. For now, the article describes an offer and a market pressure, while the outcomes will depend on each customer’s workloads and capacity.
One step at a time. That may be the most realistic way for teams to approach a platform shift when applications, staff expertise and infrastructure can’t all change together.
