Broadcom’s VMware acquisition has forced a reckoning. You’re looking at two paths: migrate to cloud (AWS, Azure, or GCP infrastructure) or adopt on-premises alternatives (hypervisors like Hyper-V, Proxmox, or Nutanix).
Neither is universally “better”. What works depends on your workload, your budget, your compliance requirements, and your team’s capabilities.
You’re probably stuck in decision paralysis right now. The options are overwhelming and the fear of making an expensive mistake is real. This article is part of our comprehensive guide to the VMware exodus, providing a systematic framework for evaluating cloud versus on-premises based on what you actually need.
We’ll cover cost comparisons, workload suitability, hybrid transition strategies, and the risks of each path. The goal is helping you make an informed decision aligned with your technical requirements and business objectives.
What are the main differences between cloud and on-premises virtualisation?
Cloud virtualisation means running VMs on AWS, Azure, or GCP infrastructure with the provider managing physical hardware, networking, and facilities. On-premises means you operate VMs on your own physical servers using hypervisors like Hyper-V, Proxmox, or Nutanix in data centres you own or colocate.
The cost structure is fundamentally different. Cloud uses an OpEx model with pay-as-you-go pricing. On-premises follows a CapEx model with upfront costs for hardware, licensing, and infrastructure.
Scalability works differently too. Cloud lets you scale resources in minutes to hours. On-premises requires hardware procurement that takes weeks or months.
There’s a control trade-off. Cloud offers convenience and managed services. On-premises gives you complete infrastructure control and customisation. The difference shows up in compliance—on-premises is often favoured for data sovereignty requirements, while cloud offers geographic region selection but your data leaves your direct control.
Vendor dependency is another consideration. Cloud creates provider lock-in through proprietary services. On-premises lets you switch hypervisors but requires in-house expertise.
How do cloud and on-premises virtualisation costs compare for different business sizes?
Small businesses (10-50 VMs) often find cloud cheaper initially. Zero upfront investment is appealing. But on-premises can provide better 3-year TCO if your workloads are stable.
Mid-size businesses (50-200 VMs) hit the crossover point where on-premises becomes cost-competitive, especially with open-source hypervisors like Proxmox reducing licensing costs.
Enterprises (200+ VMs) typically see on-premises winning on TCO for baseline workloads. Cloud works best for burst capacity and dev/test environments.
Cloud infrastructure offers flexibility through pay-as-you-go pricing, reducing upfront capital expenditure. But costs can quickly escalate due to data transfer, storage, and usage-based pricing.
On-premises demands upfront investments and ongoing operational expenses. The breakeven point is reached at approximately 8,556 hours or 11.9 months of usage.
Hidden cloud costs add up quickly. Egress fees for data transfer, storage IOPS charges, premium support contracts, and licensing (Windows Server and SQL Server on cloud are often more expensive) can surprise you.
Hidden on-premises costs include facilities (power, cooling, physical security), hardware refresh cycles every 3-5 years, backup infrastructure, and personnel for 24/7 operations.
A hybrid approach makes sense for many organisations. Run baseline workloads on-premises for cost efficiency. Use cloud for variable or seasonal capacity needs.
The reality check: organisations will run dual platforms during transition, meaning paying both Broadcom AND new platform vendor for 3-5 years. That’s painful, but it’s the price of avoiding worse pain later.
Which workloads are better suited for cloud versus on-premises virtualisation?
Cloud-suitable workloads have variable traffic patterns—think e-commerce sites and seasonal apps. Development and test environments, short-lived projects, and applications benefiting from managed services (databases, caching, AI/ML) work well in cloud.
On-premises-suitable workloads have predictable steady-state traffic. Data-intensive applications requiring high storage IOPS or network throughput fit better on-premises. So do compliance-restricted workloads in financial services and healthcare. Legacy applications with specific hardware dependencies often need on-premises infrastructure.
Consider a customer-facing web application with variable traffic—that’s an excellent cloud candidate. An internal ERP system with steady predictable load? Better on-premises.
Database considerations matter. AWS offers managed database services including Amazon RDS, DynamoDB, and Aurora. These managed cloud databases offer convenience but can be 2-3x the cost of on-premises equivalents for large, always-on workloads.
Development and test environments are nearly always cheaper in cloud. You can spin environments up and down, paying only when used.
Disaster recovery is easier in cloud. Geographic redundancy comes more easily than building a secondary on-premises data centre.
What are the risks of staying with VMware versus migrating to cloud or alternatives?
As we explore in the virtualisation reset, Broadcom has fundamentally changed the rules of engagement for VMware customers. Staying with VMware carries these risks: continued price increases, reduction in product flexibility, and potential feature limitations as Broadcom focuses on enterprise customers.
VMware customers fall into two types. Platform-Abstracted customers (the minority) treat the hypervisor as relatively interchangeable. Platform-Integrated customers (the majority) have deeply integrated operations with VMware’s Software Defined Data Centre.
Type 2 customers have built their IT operating model on VMware’s SDDC platform using vSphere DRS, NSX, vSAN, vCenter orchestration, Site Recovery Manager, and vRealize integrations. For these customers, changing isn’t a hypervisor swap but an operating model transformation.
Migration risks include application compatibility issues, downtime during transition, personnel skills gaps with new platforms, and hidden complexity in workload dependencies.
Cloud migration carries its own risks—unexpected egress costs, performance issues from latency, and difficulty repatriating workloads if cloud doesn’t work out.
On-premises alternative risks include less mature tooling than VMware, learning curves for operations teams, and potential feature gaps.
The do-nothing risk is worth considering. Staying with VMware on old licensing may work short-term but creates future migration pain when you’re forced to change. You’ll negotiate from a weaker position.
Risk mitigation: start with non-critical workloads, implement a hybrid strategy allowing gradual transition, and maintain fallback options. For detailed guidance on executing your transition, see our comprehensive migration planning guide.
How do you implement a hybrid virtualisation strategy during transition?
Hybrid means running workloads across both cloud and on-premises simultaneously. This can be a transition state or permanent architecture.
Network connectivity is required. Site-to-site VPN or dedicated connections (AWS Direct Connect, Azure ExpressRoute) enable seamless communication between environments.
Workload prioritisation matters. Migrate non-critical workloads first to learn the platform. Save mission-critical systems for later when your team has experience.
Multi-hypervisor management requires tools like Terraform and Ansible for infrastructure-as-code across different platforms. You’ll need centralised monitoring solutions that work across both environments.
Data synchronisation challenges arise when maintaining consistency for applications spanning cloud and on-premises. Replication strategies need careful planning.
Cost management requires attention. Avoid paying for duplicate infrastructure longer than necessary. Plan your transition timeline to minimise overlap.
An example strategy: move dev/test to cloud immediately for cost savings, migrate public-facing apps next, keep data-intensive systems on-premises long-term.
Should small businesses and enterprises make different cloud versus on-premises decisions?
Small businesses have advantages in cloud. No upfront capital is required. You avoid hiring specialised infrastructure personnel. Provider-managed security and updates reduce operational burden. Rapid deployment gets you to market faster.
Small business on-premises challenges include hardware costs that are prohibitive for small VM counts, lack of economies of scale, difficult 24/7 operations coverage, and skills gaps.
Enterprise advantages on-premises include scale making per-VM costs competitive, existing data centre facilities already amortised, specialised teams already employed, and compliance frameworks established.
Enterprise cloud considerations include massive egress costs for data-intensive workloads, cloud sprawl management complexity, and multi-account governance overhead.
The crossover point is typically 50-100 VMs. Below this, cloud is often more cost-effective. Above this, on-premises becomes competitive, especially with open-source hypervisors.
Small business option: start cloud-only, then evaluate moving to on-premises colo or edge infrastructure as you grow past 50-75 VMs.
Enterprise hybrid is almost imperative. Most enterprises benefit from both—on-premises for steady-state, cloud for variable capacity and innovation workloads.
What is cloud-native refactoring and when should you consider it versus lift-and-shift?
Lift-and-shift means migrating existing VMs to cloud with minimal changes. It’s the fastest migration path but doesn’t leverage cloud advantages.
Cloud-native refactoring means redesigning applications to use cloud services (containers, serverless, managed databases, object storage) instead of VMs. It maximises cloud benefits.
Refactoring benefits include better scalability, reduced operational overhead, cost optimisation through right-sizing and serverless, and improved resilience.
But refactoring requires development time, cloud expertise, potential re-testing and re-certification, and carries business disruption risk.
Lift-and-shift is appropriate for time-constrained migrations, legacy applications difficult to modify, interim solutions while planning modernisation, and situations with unclear cloud ROI.
Refactoring is worthwhile for greenfield development, applications with high operational costs, situations with clear cloud-native benefits (auto-scaling, global distribution), and when you have a long-term cloud commitment.
The pragmatic approach: lift-and-shift for a quick VMware exit, then selectively refactor high-value applications over time as the business case justifies investment.
Kubernetes serves as a middle ground between VMs and full serverless refactoring. Container orchestration lets you modernise without going all-in on serverless.
For a complete overview of all aspects of the VMware migration landscape, including pricing analysis, alternative platform comparisons, and security considerations, see our comprehensive guide to the VMware exodus.
FAQ Section
Is cloud actually cheaper than on-premises for most businesses?
It depends on scale and workload characteristics. For organisations under 50 VMs or with highly variable workloads, cloud typically offers better TCO. For 200+ VMs with steady-state usage, on-premises often wins on a 3-5 year analysis. Hidden cloud costs (egress, storage, premium support) and hidden on-premises costs (facilities, hardware refresh, 24/7 staffing) must be factored in. A hybrid approach is often optimal: on-premises for baseline, cloud for burst capacity.
What happens if I don’t migrate away from VMware in 2025?
Staying with VMware remains viable if you can afford Broadcom’s new pricing and accept vendor lock-in risks. Many enterprises are negotiating multi-year agreements to maintain current functionality. The risk: reduced negotiating leverage over time as Broadcom focuses on largest customers, potential for further price increases, and diminishing support for smaller deployments. Eventual migration will likely be more painful if delayed until forced by circumstances rather than planned strategically.
Can I run both cloud and on-premises virtualisation together?
Yes, hybrid virtualisation is a common transition strategy and permanent architecture for many organisations. It requires network connectivity (VPN or dedicated connections like AWS Direct Connect), consistent management tooling (infrastructure-as-code, centralised monitoring), and a workload placement strategy. Benefits include gradual migration reducing risk, ability to optimise each workload for the best platform, and cloud bursting for peak capacity. Challenges include increased complexity, potential data synchronisation issues, and dual operational burden during transition.
Which cloud provider is best for migrating from VMware?
It depends on your existing technology stack and migration strategy. AWS offers VMware Cloud on AWS for true lift-and-shift maintaining vSphere compatibility. Azure provides tight Windows Server integration and Azure VMware Solution, ideal for Microsoft-centric environments. GCP is strong for organisations pursuing cloud-native refactoring and Kubernetes adoption. For pure cost, native cloud services (EC2, Azure VMs, Compute Engine) are cheaper than VMware-compatible offerings but require more migration effort. A multi-cloud strategy is increasingly common to avoid recreating vendor lock-in.
How long does it take to migrate from VMware to cloud or alternative hypervisor?
Timeline varies dramatically based on scale and approach. Lift-and-shift of 50 VMs to cloud: 1-3 months. Migration of 500 VMs with dependencies: 6-18 months. Cloud-native refactoring: 12-36 months depending on application portfolio complexity. On-premises hypervisor migration follows similar timeline to cloud but requires hardware procurement adding 2-4 months. A phased approach is recommended: pilot with 5-10 non-critical workloads (1-2 months), learn the platform, then systematic rollout. Don’t underestimate dependency mapping and testing time.
What are the main security differences between cloud and on-premises virtualisation?
Cloud follows a shared responsibility model where the provider secures infrastructure and physical facilities, while you secure applications and data. You benefit from the provider’s security expertise and compliance certifications. Concerns exist about multi-tenancy and data stored outside direct control. On-premises gives you complete security control and customisation, required for certain compliance frameworks, but your organisation bears full responsibility for physical security, network security, patch management, and threat detection. Neither is inherently more secure—it depends on your organisation’s security expertise and implementation.
Do I need different skills for managing cloud versus on-premises virtualisation?
Yes, skill requirements differ. Cloud (AWS, Azure, GCP) requires understanding of cloud service models, identity and access management, cloud networking, cost management, and cloud-native services. On-premises hypervisors (Hyper-V, Proxmox) require hardware knowledge, storage systems, network infrastructure, and traditional data centre operations. Kubernetes introduces containerisation and orchestration skills. Teams with development backgrounds often find cloud concepts more accessible than traditional infrastructure engineering. Skills gap mitigation: training programmes, hiring, managed service providers, or partnering with consultants during transition.
Should I consider managed service providers instead of cloud or self-managed on-premises?
Managed service providers offer a middle ground. Infrastructure can be on-premises, cloud, or hybrid, but the MSP handles operations, monitoring, and support. Benefits include filling the skills gap, providing 24/7 coverage, and often being more cost-effective than building an internal team for small and mid organisations. Trade-offs: less direct control, dependency on MSP quality and responsiveness, and long-term costs may exceed self-managed cloud. Best for organisations under 200 VMs lacking an infrastructure team, during transition periods while building internal capabilities, or when focusing internal resources on application development rather than infrastructure operations.
What is the difference between Kubernetes and traditional virtualisation?
Traditional virtualisation (VMs) means each workload runs in a complete virtual machine with its own OS. There’s heavy resource overhead but strong isolation and compatibility with legacy applications. Kubernetes is container orchestration running multiple lightweight application containers sharing an OS kernel, providing more efficient resource utilisation and faster scaling. Kubernetes is increasingly a viable alternative to VMs for modern applications, especially in cloud-native refactoring scenarios. It’s not a direct replacement: legacy applications and Windows workloads often still require VMs. Many organisations run both—VMs for traditional workloads, Kubernetes for containerised applications.
How do I calculate TCO for cloud migration versus staying on-premises?
TCO calculation must include all 3-5 year costs across multiple categories. Cloud: compute instances, storage, network egress, managed services, premium support, licensing (Windows/SQL on cloud), cost management tooling, and personnel (reduced but not eliminated). On-premises: hardware (servers, storage, network), facilities (power, cooling, physical security, rack space), licensing (hypervisor, OS, applications), personnel (infrastructure team, 24/7 coverage), hardware refresh, and backup infrastructure. Use cloud provider calculators (AWS TCO Calculator, Azure TCO Calculator) but validate assumptions. Model realistic scenarios: stable baseline workloads versus variable traffic, data transfer volumes, and disaster recovery requirements.
Can I move workloads back from cloud to on-premises if cloud doesn’t work out?
Yes, but reverse migration (“cloud repatriation”) can be expensive and complex. Challenges include egress fees for large data transfers, application modifications made for cloud may create incompatibilities, loss of cloud-native service benefits, and the need to acquire hardware. Some organisations report cloud repatriation saving 50-75% ongoing costs but requiring 6-12 months effort and capital investment in hardware. Prevention strategies: maintain cloud independence by avoiding proprietary cloud services, use infrastructure-as-code for portability, and pilot before full commitment. A hybrid architecture provides flexibility to move workloads between environments based on economics.
What compliance requirements favour on-premises versus cloud virtualisation?
Data sovereignty regulations (GDPR, financial services regulations) may require data remain within specific geographic jurisdictions. This is achievable in cloud through region selection but some organisations prefer on-premises for absolute control. Highly regulated industries (defence, healthcare, finance) may have certification requirements or air-gapped network mandates favouring on-premises. However, major cloud providers now offer compliance certifications (FedRAMP, HIPAA, PCI-DSS, SOC 2) meeting most requirements. The compliance decision requires evaluating specific regulatory requirements, data classification, and whether cloud provider’s compliance frameworks are sufficient versus the need for on-premises control.
