Build Optionality: The Capabilities That Keep VMware From Dictating Your Roadmap 

Most VMware transition plans still start with the same question: where are we moving? 

It’s a reasonable place to start, but it isn’t what determines whether the plan holds up. What matters is whether the organization can change course without breaking operations. In a mixed estate, course changes are inevitable. Pricing shifts. Risk shifts. A platform decision that looked clean early gets messy once you hit DR, identity, and real dependency chains. 

That’s what we mean by optionality. The ability to execute more than one path without turning the program into operational sprawl. 

Our 2026 CloudBolt Industry Insights research reflects why this matters. Only 4% report a completed full migration away, while 54% are staying with VMware while actively reducing dependence. And 92% of organizations have changed their strategy at least once since the acquisition, not because they’re indecisive, but because the landscape keeps shifting. Optionality is what makes that iteration deliberate rather than reactive; it’s the difference between controlled execution and gradual drift. 

Optionality is execution capacity 

Most organizations already know they need to reduce dependence. Many have a rough sense of what can move, what should be replaced, and what will remain longer than anyone wants. 

Where the work slows down is when every move requires custom engineering, bespoke ops changes, and renewal-driven decisions. Optionality is the set of capabilities that closes that gap. 

A simple way to test whether optionality exists is to test it. Can the organization do the following without turning each step into a bespoke project? 

• keep net-new workloads from defaulting back to VMware 
• move a workload class without rewriting the operating model each time 
• sustain a mixed estate without multiplying incidents and exceptions 
• negotiate renewals from credible alternatives rather than deadline pressure 

Optionality does not require every workload to be portable. It requires that the parts of the estate you intend to change can be changed repeatedly. 

The three layers that make optionality real 

Optionality is built across three layers: technical, operational, and commercial. If one lags, the program turns into churn. 

1. Technical optionality 

Workloads can be reproduced in a second environment without turning each move into custom engineering. 

Perfect portability isn’t the goal. Standardization is. Deployment patterns, configuration baselines, identity models, network patterns, and enough dependency visibility to avoid surprises. 

Typical ingredients include: 

• a default landing rule for net-new workloads 
• consistent build and deploy patterns (IaC and CI/CD conventions) 
• dependency visibility sufficient to sequence changes safely 
• a small set of workload archetypes you can move consistently 

Technical optionality keeps diversification from turning into a second set of snowflake environments. 

One dependency that doesn’t show up in most migration plans: the orchestration and automation layer.

Many VMware-heavy enterprises have 10+ years of workflows, provisioning logic, and integrations built into Aria Automation, and Aria doesn’t work with AWS Native, Azure Native, or Google Cloud. It automates VMware only. So even after you move 30% of workloads elsewhere, you still need Aria for what remains, and Broadcom knows that’s the stickiest component of the bundle.

Technical optionality means the automation layer can’t be locked to a single hypervisor. The organizations building real optionality are starting with a platform-agnostic management layer that works across destinations, so the orchestration doesn’t become the last trap standing. 

2. Operational optionality 

The organization can sustain a mixed estate without multiplying fragility. 

This is where many transition programs quietly fail. Migration work has an end date. Operating two platforms with two operating models does not unless the organization standardizes the operational layers that create safety and predictability. 

Operational optionality is built by standardizing the layers that create safety and predictability across environments: 

• observability patterns and alerting expectations 
• patching and baseline configuration models 
• DR assumptions and runbooks that survive destination changes 
• request intake and provisioning workflows that don’t devolve into tickets and exceptions 
• governance guardrails that work across platforms 

Teams that succeed here standardize the operational primitives early and reduce the number of bespoke workflows required to provision and govern infrastructure across environments. 

If these are inconsistent, mixed-estate operations become sprawl. Sprawl becomes fatigue. Fatigue becomes stalled programs and default renewals. 

3. Commercial optionality 

Renewals stop being cliffs. 

Commercial optionality is what keeps the strategy executable without panic. It also keeps sequencing from being hijacked by deadlines. 

It includes: 

• explicit measurement of renewal exposure and trapped footprint 
• a plan that reduces exposure quarter by quarter, even if full exit takes years 
• a cost model that reflects mixed-estate reality 
• chargeback/showback discipline so platform decisions are legible to the business 

When this layer is missing, organizations still move. They just move under pressure, and pressure forces bad trade-offs. 

A capability map to diagnose what’s missing 

Treat this table as a diagnostic. What is currently preventing optionality from being real? 

Capability	What it enables	What happens when it’s missing
Net-new landing policy	Stops dependence from growing	New workloads default to the incumbent platform out of convenience
Standard workload patterns	Repeatable change	Each move becomes custom engineering
Dependency visibility	Predictable sequencing	Hidden dependencies expand scope mid-program
Standardized observability	Mixed-estate operations without blind spots	Incidents rise as visibility fragments
DR model across destinations	Safe re-homing	DR becomes the blocker late in the move
Guardrails for provisioning and governance	Controlled diversification	Exceptions multiply and platform sprawl accelerates
Skills and operating model plan	Sustainable execution	Program becomes fragile or consultant-dependent
Renewal exposure tracking	Negotiation leverage	Decisions get made under renewal deadlines

A note on practicality. Every item in this list can be built with internal standards and disciplined execution. It’s all possible. The constraint is sustainability at enterprise scale without turning into a backlog of tickets, exceptions, and one-off automation. 

What to build in the next 90 days 

The first 90 days are about preventing drift. Enforceable net-new defaults, an operable second landing zone, and visibility into renewal exposure. 

1. Establish a net-new landing zone policy, not a preference 

If you don’t have a standardized landing zone ready outside of VMware, every new workload defaults back to the incumbent out of convenience. That environment needs identity, networking, observability, and governance already in place. Without it, new workloads keep landing in VMware by default.  

This is how you stop growing dependence before you start reducing it.  

2. Standardize one operational layer early 

Pick the layer most likely to fail first and standardize it across environments. Observability is a common starting point because it protects you while everything else changes. Identity patterns are another. 

The goal is to keep mixed-estate operations manageable long enough for the program to gain credibility. 

3. Define what repeatable means for your organization 

Pick one workload class and define the standard move: prerequisites, baselines, validation steps, and post-move operational expectations. 

This is how you stop relying on heroics and start building a machine. 

4. Start measuring trapped footprint and renewal exposure 

If leadership can’t see exposure, leadership can’t defend sequencing. 

Track it. Report it quarterly. Use it to keep the program oriented around leverage rather than activity. 

If you do nothing else in the first 90 days, make two things true: net-new defaults don’t drift, and mixed-estate operations don’t become a second full-time job. 

What to build over the next 12 months 

The next year is when you remove the constraints that make change slow, risky, and expensive. 

1. Operationalize dependency mapping 

Treat dependency work as a living capability, not a one-time audit. The estate changes and assumptions rot. 

2. Rebuild DR and security assumptions for a mixed estate 

Single-platform assumptions rarely survive multi-platform reality. As organizations diversify, multi-platform complexity and skills gaps persist as challenges. Treat this as predictable. Build for it early. 

3. Expand repeatable patterns from one class to three 

Once one move becomes repeatable, expand deliberately. The goal is cumulative capability that accelerates each subsequent quarter. 

4. Align commercial sequencing with technical reality 

Renewal exposure should fall as repeatable moves increase. If those lines aren’t moving together, something is off, whether it’s scope, constraints, or operating model. 

How to tell if optionality is actually improving 

Optionality is improving when you can say these things without handwaving: 

• net-new workloads are landing on the incumbent platform by default 
• key operational layers are standardized enough to make a mixed estate sustainable 
• at least one workload class can be re-homed repeatably 
• DR assumptions have been validated for at least two destinations 
• renewal exposure is measured and trending down where it matters 

If these signals aren’t visible yet, the work is still mostly intent and motion. That’s a normal stage of the program. 

Note: If you’re in the early stages, still mapping, still debating, still piloting, that’s not failure. It’s the program working as designed. The organizations in trouble aren’t the ones still iterating. They’re the ones who stopped. 

The practical takeaway 

For most enterprises, reducing VMware dependence under Broadcom does not result in a clean cutover. It plays out over years in a mixed estate, where some workloads move, some wait, and some stay longer than anyone wants.  

That is where optionality matters. In this context, optionality means having the technical, operational, and commercial capacity to reduce VMware dependence without letting renewal timing, operational sprawl, or execution drag dictate the roadmap. 

CloudBolt can help operationalize that by providing a consistent control plane for provisioning, governance, and lifecycle automation across VMware and alternative environments. The underlying principles apply regardless of tooling, but the goal is the same: make dependence reduction executable, repeatable, and measurable. 

Read the full report: The Mass Exodus That Never Was: The Squeeze Is Just Beginning