How to Become Broadcom-Compliant Without Migrating a Single Workload 

Changing Your VMware Licensing Route Doesn't Mean Moving Workloads

If I could clear up one misunderstanding for impacted VMware partners, it would be this:

Changing how you access VMware licensing doesn't automatically mean changing where your customer workloads run.

The licensing route may need to change. Your partner arrangement may need to change. There will be contracts to agree and onboarding to complete.

But the workloads themselves?

They can stay exactly where they are.

That matters because migration has somehow become the default answer to what is, first and foremost, a compliance question.

Personally, I think that risks creating far more work and disruption than is actually necessary.

Let's Be Clear About What's Changing

Impacted MSPs need a route for continuing to access VMware licensing and support under Broadcom's new partner model.

In practical terms, that means working through a VCSP Pinnacle Partner.

It's a change to the commercial and licensing model behind the service. It isn't automatically a change to the service itself.

Your virtual machines don't know which commercial agreement sits behind them. Customer applications don't suddenly need to be re-platformed. Operational teams don't have to abandon the processes they already use.

You need to understand your current licence position. You need to choose the right partner, agree the commercial arrangement and complete the necessary onboarding.

But none of that inherently requires a workload migration.

A Migration Should Solve a Problem

I'm not suggesting migration is always the wrong choice.

There may be good reasons to move workloads. Existing hardware may be approaching the end of its useful life. Customers may want capabilities that their current environments can't provide. Moving to VCF or a managed VMware platform may create a stronger long-term operating model.

But migration should solve a clear business or technical problem.

It shouldn't happen simply because the licensing route has changed.

Moving a stable customer environment creates work. Dependencies need to be understood. Change windows have to be agreed. Engineers need capacity. Customers need to know what's happening and why.

And even a well-managed migration introduces some level of cost and risk.

If the immediate objective is compliance, adding all that work before there's a clear reason to do it feels like solving the wrong problem.

The better question is:

What genuinely needs to change now and what can safely remain in place?

What Continuity Looks Like in Practice

Under Iomart's VCF Transition Managed Service:

• Existing workloads stay where they are
• Customer services continue as normal
• Established operational processes remain in place
• There's no forced migration
• There's no requirement to move immediately to VCF

The main change is the route through which VMware licensing and support are provided.

A well-managed transition shouldn't create visible disruption simply to prove that something is happening behind the scenes.

If customers continue receiving the same reliable service and operational teams can carry on supporting them, the compliance work has achieved what it needs to achieve.

Low Disruption Is a Business Decision

Avoiding an unnecessary migration isn't only about reducing technical risk. It also protects the wider business.

Engineering teams can stay focused on customer delivery rather than being pulled into a transition project. Account teams don't have to explain changes that offer customers no obvious benefit. The MSP avoids creating project costs before there's a clear commercial return.

Most importantly, recurring customer revenue remains protected.

That doesn't mean doing nothing. The partner and licensing arrangements still need to be changed and made operational before the deadline.

It means focusing effort where it's genuinely required.

I'd much rather see an MSP complete a straightforward, well-planned compliance transition than rush into a much larger transformation programme simply because it feels like the more decisive response.

Continuity Isn't the Same as Standing Still

This is the other important point.

Keeping workloads where they are today doesn't mean committing to keeping them there forever.

Continuity gives you a stable starting point for deciding what the longer-term platform should look like.

Once the immediate requirement is dealt with, you can look properly at your customer estate. Which workloads are suitable for VCF? Which environments are approaching a hardware or lifecycle decision? Where could a managed platform reduce pressure on internal teams? Which new services could create additional value for customers?

Some MSPs may decide to move towards a complete managed VCF service. Others may take a phased approach, moving different workloads when there's a clear reason to do so.

Either route is easier to assess when you're not trying to complete it against a licensing deadline.

That's why I see continuity as an active decision.

You're not avoiding transformation. You're choosing to approach it on your own terms.

Start With the Question That Matters Most

If your main concern is, "Do we actually need to move?", start with a VMware Partner Strategy Review.

We'll look at what needs to change to meet the immediate compliance requirement, what can remain in place and what your realistic longer-term options look like.

You may decide that transformation is the right next step.

But you shouldn't have to migrate a single workload simply to become compliant.

If you're unsure what the most practical route to compliance looks like for your business, speak to a VMware specialist and start planning your next steps today.