Strategic Assessment for Cloud Service Providers and Enterprise Organisations Ahead of the 2027 Landscape Shift

For more than a decade, VMware has been the backbone of virtualised infrastructure across two distinct worlds: Cloud Service Providers delivering VMware-based IaaS, and enterprise organisations running private datacentres with vSphere at the core. Both groups-built processes, tooling and operational cultures around the platform.

But over the last two years, the VMware landscape has been fundamentally reshaped. Broadcom’s restructuring of licensing models, subscription-only offerings, product bundling, and the consolidation of the VMware Cloud Service Provider (CSP/VCSP) ecosystem have introduced uncertainty for both markets.

For CSPs, the impact is direct: since late 2025, the CSP programme has become invite-only, and contracts for providers not requalified will expire by March 2027.
For enterprise organisations, the challenges are different but no less relevant: pricing models have changed, perpetual licences have ended, some products have been discontinued, and long-term architectural direction is less predictable.

In both cases, organisations now face a strategic question: does continuing on VMware align with our long-term goals, budgets, and operational strategy?

Apache CloudStack enters this conversation not as a one-to-one replacement for vSphere, but as a mature open platform for IaaS orchestration: stable, predictable, and widely used in both enterprise and CSP environments.

This article presents a structured, editorial framework to help organisations, CSPs and enterprises, evaluate whether, when, and how to move from VMware to CloudStack. No hype, no pressure, just clarity.

Evaluation Framework at a Glance

Before diving into the detailed sections, it helps to view the migration evaluation as a clear sequence of eight steps. This structure acts as a decision map, guiding organisations through motivation, analysis, readiness, design and validation before committing to any transition. It also ensures that both enterprises and service providers move with clarity rather than urgency, especially as the VMware landscape continues to evolve.

Step 1 – Define Motivation

Start With the Real Motivation, Not the Superficial One

Many organisations name “cost” as the initial driver, but cost is rarely the whole story. The underlying motivations differ slightly for CSPs and enterprises, but the themes overlap: predictability, autonomy, vendor strategy, and long-term control.

Table 1 – Common Triggers for Evaluating Alternatives

Objective	Description	Typical Motivation
Predictable long-term cost	Avoid unpredictable per-core or bundled licensing	Budget stability, reduced exposure
Autonomy and control	Reduce dependency on a single vendor’s roadmap	Strategic independence
Architectural simplification	Move away from complex multi-layer stacks	Lower operational overhead
Better use of internal skillsets	Align with Linux/KVM and automation practices	DevOps maturity, IaC
Future-proofing	Ensure continuity beyond 2027 CSP changes	Enterprise & CSP long-term planning

Whether enterprise or CSP, clarity of motivation anchors the entire evaluation. It shapes every decision that follows, from how the VMware estate is assessed, to the level of operational readiness required, to the type of architecture that makes sense as a target state. A well-defined motivation also prevents the migration from becoming a purely reactive move, keeping the strategy aligned with long-term objectives rather than short-term pressure.

Step 2 – Inventory VMware

Understand Your VMware Estate in Practical Terms

Before CloudStack even enters the evaluation, organisations need a realistic view of their VMware environment. This means going beyond VM listings and mapping the operational, architectural and support boundaries that define what can and cannot be moved.

Table 2 – Useful Questions During Environment Mapping

Area	Key Questions	Why It Matters
Compute	What VM shapes, hosts, clusters?	Defines migration and host repurposing strategy
Networking	NSX? stretched L2? VLAN complexity?	Directly affects CloudStack network design
Storage	IOPS, VMFS/NFS, latency-sensitive workloads?	Ensures correct Primary Storage selection
Virtual appliances	Firewalls, load balancers, vendor-specific VMs?	Compatibility checkpoints
Criticality	What can tolerate downtime? What cannot?	Shapes sequencing and pilot selection
Certification & Vendor Support	Do workloads require certified hardware, hypervisors or OS versions (e.g., SAP HANA, Oracle, vendor appliances)?	Ensures workloads remain supported after migration and highlights cases requiring redesign or dedicated VMware infrastructure

Some workloads introduce constraints that go beyond simple technical compatibility. Applications tied to certified hardware, hypervisor-specific support or strict vendor requirements may not be suitable for a direct move to KVM. Identifying these cases early clarifies which workloads can migrate, which require redesign and which may need to remain on VMware, ensuring the migration plan is built on facts rather than assumptions.

Step 3 – Check Readiness

Evaluate Your Operational Readiness for a KVM-Based Model

CloudStack removes much of the complexity of orchestration, but the underlying operational model is different. At the host layer, it relies on Linux and KVM, and organisations vary widely in how prepared their teams and processes are for that shift.

Another factor that often shapes readiness is how much the organisation depends on its CMDB. If provisioning, change management or incident workflows are tightly bound to a central database, a new virtualisation platform must either integrate with those processes or prompt adjustments to them. Identifying this early helps avoid gaps in automation or governance later on. CMDB dependency is often underestimated; recognising it here prevents operational surprises during migration or after go-live.

Table 3 – Operational Readiness Indicators

Capability	Practical Examples	Impact
Linux familiarity	Managing services, logs, packages	Smooth host operations
Networking	Bridges, VLANs, OVS, SDN	Correct CloudStack network design
Storage knowledge	IOPS, latency profiles, block vs. file vs. SDS	Right storage tiers and expectations
Monitoring	Tools not tied to vSphere	Preserves visibility
Automation	Ansible, CI/CD, config management	Predictable rollout of hosts/zones
CMDB Integration	Provisioning, change control, asset tracking tied to a central CMDB	Ensures CloudStack fits into existing governance workflows or highlights areas needing redesign

Readiness is not binary; it simply indicates whether the team can transition smoothly or will benefit from a ramp-up period or external guidance.

As part of this readiness assessment, it is also worth rethinking the support model. Moving to an open-source stack often means strengthening in-house skills while identifying external partners who can provide long-term support for CloudStack and the surrounding ecosystem. A balanced strategy, deeper internal capability combined with trusted open-source support partners, leads to more predictable operations once the new environment is in place.

Step 4 – Surface Risks

Identify Risks Before They Dictate the Timeline

Risk identification is crucial for both CSPs and enterprises, but CSPs also face a calendar deadline (2027), while enterprise risks are more architectural and operational.

Some of the constraints identified earlier, such as workloads tied to certified hypervisors or hardware, become practical risks during planning. These workloads may require exceptions, parallel infrastructure or longer migration windows, influencing sequencing and operational complexity. Recognising this early helps set realistic timelines and prevents surprises later in the process.

Table 4 – Typical Migration Risks and Their Early Signals

Risk Type	Early Signal	Mitigation
Compatibility	VMware Tools dependencies	Early virt-v2v testing
Networking	NSX reliance	Redesign using CloudStack network models
Storage	Latency/IOPS-sensitive workloads	Benchmark on target storage
Process	Strong dependency on vCenter workflows	New runbooks + pilot practice
Timeline (CSP)	Provider not re-invited to programme	Plan transition before 2027
Timeline (Enterprise)	Renewals unclear or cost-prohibitive	Evaluate predictable alternatives
Workload Constraints	Apps requiring certified hypervisors/hardware/OS	Define exceptions, parallel infrastructure or redesign path

Enterprises and CSPs face different kinds of pressure, but both benefit from surfacing these risks early. Clear visibility allows teams to plan realistic timelines, define migration boundaries and decide whether exceptions, redesign or hybrid models are needed. More importantly, it prevents the evaluation from being driven by deadlines or assumptions, ensuring that the migration strategy is based on informed choices rather than reactive decisions.

Step 5 – Design Target Architecture

Translate Your VMware Reality Into a CloudStack Model

At this stage, the evaluation shifts from understanding the current environment to outlining how it maps into CloudStack. The goal is not to build a full blueprint, but to create a clear conceptual architecture that shows how workloads, networks and storage would fit into the CloudStack model.

Table 5 – Mapping VMware Reality to CloudStack Concepts

VMware Concept	CloudStack Equivalent	Notes
vCenter folders/tenants	Domains / Accounts	Logical grouping
VM shapes	Compute Offerings	Standard resource profiles
Storage classes	Disk Offerings	Maps to performance tiers
Port groups / NSX	Isolated, VPC, Shared, L2 Networks	Security & connectivity
Clusters	Clusters (KVM)	HA & capacity boundaries

CloudStack does not require an immediate switch from VMware to KVM. In many environments, both hypervisors can coexist under the same CloudStack management plane. This can be useful when certain workloads must remain on vSphere due to certification, performance characteristics or vendor requirements.

However, the viability of a mixed environment depends on the organisation’s architecture, operational model and licensing position. The feasibility of managing both platforms through CloudStack should therefore be evaluated as part of the target design rather than assumed by default.

Step 6 – Select Migration Style

Choose a Migration Style That Fits Your Organisation

Another consideration when selecting a migration style is the level of automation required. Some organisations prefer a manual, instance-by-instance approach for the early waves, especially when dealing with complex or business-critical systems. Others opt for automated, large-scale execution once patterns are validated and tooling is in place. Both strategies are valid: manual execution offers control and a smaller blast radius, while automated execution accelerates throughput. The right balance depends on the organisation’s risk tolerance, operational maturity and workload diversity.

Table 6 – Choosing a Migration Style

Scenario	Recommended Approach	Why
Team is new to KVM	Incremental (host-by-host)	Lower blast radius
Strong separation by business unit	Wave-based	Natural grouping
CSPs approaching 2027 deadline	Wave-based with structured pilot	Minimises dual-stack time
Enterprise with deep NSX	Incremental	Allows network redesign in stages
Strict change controls	Small controlled waves	Aligns with governance
Need for high control or diverse workloads	Manual (individual) execution	Reduces blast radius, allows careful validation
Large homogeneous estates, strong automation capability	Automated (mass) execution	Accelerates migration once patterns are proven

A hybrid approach is also possible, since CloudStack can orchestrate both VMware and KVM clusters in parallel. This enables gradual migration under a unified control plane. That said, a hybrid model is not universally the best choice: it introduces overhead in tooling, governance and support, and may not align with organisations aiming for full standardisation on Linux + KVM. Whether hybridisation makes sense should be evaluated on a case-by-case basis rather than assumed by default.

Step 7 – Execute Pilot

Run a Meaningful Pilot With Clear Measures of Success

A pilot turns the evaluation into something tangible. It tests conversion, architecture, operations and user expectations in a controlled environment before committing to broader migration.

Table 7 – Elements of an Effective Pilot

Element	Description	Purpose
Representative VMs	Linux, Windows, DBs, vendor appliances	Tests conversion diversity
Realistic CloudStack layout	Domains, networks, offerings	Ensures architecture viability
Operational rehearsal	Monitoring, runbooks, backup tests	Prepares Day-2 operations
Defined success metrics	Downtime limits, performance baselines	Anchors acceptance criteria

A well-designed pilot provides more than technical validation. It reveals how CloudStack fits into real workflows, how teams respond to new procedures, and whether performance and operability align with expectations. For both enterprises and CSPs, this step replaces assumptions with evidence and gives stakeholders the confidence needed to move forward deliberately.

Step 8 – Decide with Clarity

Make the Decision With the Full Picture, Not the Emotional One

At this point, the decision is grounded in evidence rather than assumptions.

The organisation now understands:

1. The true motivation
2. The real VMware environment
3. Operational readiness
4. Risks
5. The CloudStack mapping
6. The migration style
7. The pilot results

Table 8 – Outcomes of a Well-Structured Evaluation

Outcome	When It Applies	Next Step
Full Go	Motivations clear, design validated	Begin phased migration
Conditional Go	Gaps identified, or some workloads unsuitable for KVM	Address gaps, define exceptions, build hybrid model
Not Now	Timing, roadmap or constraints not aligned	Reassess later

A Conditional Go often leads to a hybrid architecture, where some workloads move to KVM while others remain on vSphere. CloudStack can manage both hypervisors, providing a unified orchestration layer.

Still, hybridisation is only effective when the organisation’s architecture, licensing model and operational team can support two hypervisors without unnecessary complexity. In some cases, keeping VMware for specific workloads is the right outcome; in others, it introduces more cost and operational friction than it solves. The decision should be deliberate, based on technical and business constraints rather than the assumption that hybrid is always beneficial.

Conclusion: A Transition Already Underway, Affecting CSPs and Enterprises Alike

The VMware ecosystem has changed fundamentally.
For CSPs, the 2027 deadline for non-reinvited partners is a fixed milestone, after which renewals and service continuity become uncertain.
For enterprises, the shift to subscription-only licensing, the retirement of perpetual models, bundled product constraints and the narrowing of the partner ecosystem raise long-term strategic questions.

This transition is not about urgency but preparedness. Organisations, both service providers and enterprises, that begin planning now can migrate under controlled conditions, with thoughtful pilots, redesigned architectures and clear timelines. Those who wait risk facing time pressure, limited resources, or unplanned operational disruption.

CloudStack offers a stable, transparent, open model for IaaS orchestration. But its benefits are best realised when the migration is deliberate, grounded in an evaluation framework rather than in reaction to market shifts.

Next Steps: Building Your Roadmap

Whether you are a CSP facing 2027 or an enterprise evaluating a long-term alternative, the next steps are the same:

1. Finalise your VMware inventory
2. Draft your CloudStack reference architecture
3. Choose a migration style and timeline
4. Run a meaningful pilot
5. Validate readiness and stakeholder alignment
6. Build a phased migration plan

Begin early. Move with clarity.

When External Support Adds Value

Most enterprises and CSPs can cover the early stages of the evaluation internally: motivation, inventory, readiness, architectural thinking and even an initial pilot. But as the 2027 horizon approaches for CSPs, and as enterprises plan for long-term platform stability, many organisations reach a point where external expertise accelerates clarity and reduces risk.

External support becomes especially valuable when:

• The VMware environment includes NSX, stretched L2 networks or highly segmented architectures
• Vendor appliances or legacy workloads need careful analysis before conversion
• Internal teams are new to Linux + KVM and need structured onboarding
• Storage and network layers require redesign rather than simple “lift-and-shift”
• The migration timeline intersects with contract end-dates or business-critical milestones
• Leadership requests an independent architecture review before committing

ShapeBlue, as a long-standing contributor to Apache CloudStack and specialist in CloudStack architecture, deployment and long-term operations, provides structured assistance precisely for these scenarios.

The company maintains a set of openly available materials that help organisations frame, validate and accelerate their decision-making:

• Apache CloudStack Proof-of-Concept Guide

https://www.shapeblue.com/apache-cloudstack-poc-guide/

• CloudStack PoC Evaluation Checklist

https://www.shapeblue.com/apache-cloudstack-poc-evaluation-checklist/

• Evaluating the Top 5 VMware Alternatives

https://www.shapeblue.com/evaluating-top-5-vmware-alternatives/

• VMware to Apache CloudStack Migration Guide

https://www.shapeblue.com/vmware-to-apache-cloudstack-migration-guide/

• Apache CloudStack as a VMware Alternative – Resource Hub

https://www.shapeblue.com/resources/apache-cloudstack-as-a-vmware-alternative/

And importantly, ShapeBlue also provides a dedicated migration framework for VMware environments:

• VMware Migration to Apache CloudStack — Consulting & Migration Services

https://www.shapeblue.com/vmware-migration-to-apache-cloudstack/

This migration service outlines a structured approach for transitioning from VMware to CloudStack, covering architecture discovery, environment assessment, pilot design, workload conversion, CloudStack build-out, knowledge transfer and long-term operational support. It is designed for both enterprises and service providers that prefer a guided transition rather than navigating the full process alone.

The goal of external involvement is not to replace internal teams, but to multiply their effectiveness, providing validation, reducing blind spots, accelerating the design phase and ensuring that migration steps are grounded in proven patterns rather than trial-and-error. For organisations facing CSP contract deadlines or enterprise transitions, this support can significantly reduce risk and uncertainty.

Final Thoughts

The VMware landscape has already changed, and the implications will continue to unfold through 2027 and beyond. Evaluating CloudStack is not a reaction to unexpected news; it is a rational step toward ensuring technical and operational continuity.

By following a structured framework, enterprises and CSPs can make the transition confidently, with a clear understanding of motivations, risks and long-term goals.