Cloud infrastructure migration: what are your options and where do you start?

For years, VMware was the safe choice: reliable, familiar, and deeply embedded in how organizations built their private and hybrid cloud environments. Then Broadcom rewrote the partner model overnight, license costs climbed, and a question that had always been theoretical suddenly became urgent; if not VMware, then what?

It’s tempting to treat that as a purely technical question: pick a platform, plan the move and execute. But talk to enough people working through this right now, people like Eric Kessels (CIO at Fairbanks), Ruud Allaerts (Managing Director of the Dutch Cloud Community), and Tony Vidal (VMware migration specialist), and a pattern shows up fast. Most of the obvious answers don’t actually solve the problem that got you here. They just relocate it. That’s the thread worth pulling on, because it changes how every option should be judged.

Broadcom didn’t create a new risk, it exposed one that was already there: a single vendor relationship sitting underneath an organization’s entire infrastructure, with terms that vendor can change unilaterally. Migration touches every layer of the business, from the applications people use every day to the commitments made to customers, which is exactly why it can’t be left to the IT-team to sort out quietly. It needs attention at the level where the original dependency was created: the boardroom.

Organizations that waited for things to stabilize are now under serious time pressure. Some who started migrating two or three years ago are still mid-process. Which says something useful on its own: doing this properly takes time, and the window to do it without cutting corners keeps shrinking.

There’s an obvious move that looks like it solves everything: leave VMware for a major public cloud provider. It’s fast, mature, and gets the immediate problem off the table. It also recreates the exact dynamic that caused the problem in the first place, just with a different name on the contract.

That matters more than it used to, because the dependency question has widened. For European organizations, digital sovereignty has moved from a footnote to a boardroom topic: who controls your data, which government can reach your services, what happens if a vendor is pressured by its own government to restrict access. None of that is hypothetical anymore. The organizations thinking clearly about this aren’t asking where they can move fastest, they’re asking which destination actually changes their risk profile, and which one simply resets the clock on the same risk.

Run the realistic options through that question and they sort themselves out quickly.

Open source infrastructure is the one with the most momentum, and for good reason. Roughly half of service providers already run it, OpenStack has a decade of production track record, and the knowledge it builds transfers across scale: what you learn running two nodes still applies at five thousand. It’s also the only one of the three that genuinely changes the dependency, rather than just changing who you depend on.

Proprietary alternatives like Nutanix solve the moving part well: a familiar operating model, a gentle learning curve, a smooth transition. What they don’t solve is the underlying issue. The licensing dynamics that caused this disruption could resurface from a different vendor a few years from now.

Public cloud is the right call for organizations that run their own application landscape without operating as a service provider themselves, since there’s no datacenter to build before the migration can even start. For service providers or anyone with real sovereignty requirements, it’s largely off the table as a destination, not because of capability, but because of what it would mean for dependency.

None of that matters yet if you haven’t looked closely at what’s actually running. Every workload is different, and the right path for each depends entirely on what it is, not on which destination sounds best.

Some workloads can be rebuilt from scratch with no real risk. Others carry years of configuration and dependencies that demand careful handling. Some have grown complex enough that moving them blind will surface surprises you didn’t plan for. Sorting workloads into these categories before anything moves is what tells you where to spend attention and where you can move fast: recreate some directly, lift-and-shift others, re-platform a few, retire whatever no longer earns its place.

Three things derail migrations that otherwise look well planned. Organizational capacity is the most common: teams already running production can’t absorb a major migration on top of their day job without shortcuts that cause problems later, which is why this needs to be its own workstream, not something squeezed in around existing work.

Knowledge transfer is slower than expected. VMware expertise doesn’t translate automatically, and a partner who’s done this before saves the team from relearning lessons that already exist elsewhere.

And then there’s the risk that ties back to where this started: choosing a destination that quietly recreates the problem. If reducing dependency is actually the goal, the destination has to deliver that, not just feel like progress.

If not VMware, then what? The honest answer isn’t a platform name. It’s whether the move you’re about to make actually changes who controls your infrastructure, or just changes who you’re asking for permission. Organizations that get this right start with a clear picture of what they have, choose deliberately rather than quickly, and treat the whole thing as an organizational decision that happens to require technical execution.

If you want to work through what that looks like for your own environment, reach out, we’re happy to think it through with you.