Migrations are complex, time-consuming, and costly. When deciding to leave VMware due to Broadcom price increases and their cancellation of perpetual licensing, the cost associated with the act of migration should be the second most important item.  

This blog will touch on the top 5 considerations for migrating from VMware to any alternate hypervisor for on-premises and edge.  

Consideration 1: Licensing costs 

Licensing is the first evaluation everyone considers: will the new platform license cost the same, less, or more than what Broadcom is now asking for? This sounds basic, but there are other items to consider such as: 

1. Will my migration capability impact how quickly I can consume my new licenses?  
2. License type changes: are the new license socket, core, or node-based? Is it a direct comparison?  
3. Would an enterprise agreement make sense?  
4. Important: Are you planning to containerize? 

Consideration 2: Storage 

All VMs leverage persistent storage, and your new hypervisor needs to support your existing storage unless you are willing to execute an entire data center transformation. When evaluating your new hypervisor, ask the following: 

1. Do I need to change my storage in any way? 
2. If you are using hyper-converged, ensure the new hypervisor is HCI.
3. Which forms of connectivity are used today in your enterprise storage, and does the new hypervisor support it?  

Consideration 3: Backup 

After creating a VM, it’s essential to protect the data it holds. Beyond the litany of headlines about Broadcom and all their changes to VMware, 2024 is proving to be a year where ransomware attacks cease to abate.  

When making a move as the following: 

1. Does my backup product support my new hypervisor? 
2. If you are using agent-based backups, ask this: will the agent be impacted during the actual migration?  

Consideration 4: Monitoring  

24/7 uptime and 99.999% SLAs cannot achieved without broad and deep support for monitoring. Although VMware hypervisor and VM monitoring are only a piece of your monitoring stack, you need to ensure that there isn’t a regression when you change.  

Ask the following: 

1. Does my existing monitoring support the new hypervisor? 
2. If you are using Opensource, how much work is required to update all scripts to support the new environment?  
3. Once migrated, what processes and integrations need to be updated to ensure correct responses? 

Consideration 5: Disaster Recovery & Compliance  

DR and compliance should not be overlooked. Ask your internal stakeholders immediately! Compliance should not be underestimated and left to chance. If there are regulatory requirements, ensure you stay compliant and take the time to discuss any changes early.  

Ask the vendor you’re working with about disaster recovery and how they would architect the new environment to achieve your existing DR capabilities.   

28 Answers your CTO and CIO need before making a change

1. How will networking configurations and virtual switches need to be adapted? 
2. What changes will be required for storage management and provisioning? 
3. How will high availability and live migration capabilities change? 
4. How will monitoring, backup, and disaster recovery processes need to be modified? 
5. Do your current monitoring tools natively support the new environment? Will escalations and 24/7 run-books/knowledge base articles need to be updated? 
6. What DR processes need to be reviewed? 
7. Does the current backup platform natively support the new platform? Will any changes impact RPO and RTO? 
8. How will the migration impact existing automation, orchestration, and management tools and workflows? 
9. Will existing self-service workflows regress or improve? 
10. Can you reduce reliance on vendor-supplied tooling such as Ansible Tower or Hashicorp Cloud? 
11. Will end-of-day or monthly batch processing be impacted?
12. Are there aspects of compliance and audit that will need to be tackled upfront to avoid lengthy reviews at year-end? 
13. When running the migration, will throughput limitations (bottlenecks) reduce the number of VMs you can migrate concurrently? 
14. Will any databases require vendor-supported migration tooling, such as Oracle Goldengate or Quest Shareplex? 
15. Does the storage platform have the capacity to support 1.5x current usage whilst migration is in progress? 
16. How will user acceptance testing (UAT) impact migration timelines? 
17. During UAT, when is a fail-back considered? 
18. Will any applications run active/active? 
19. Is DNS cutover the only option for live applications? 
20. How will outage windows be communicated to internal and external users? 
21. Will any database or other software licensing change with a change in hypervisor? (Oracle, SAP, Exchange?) 
22. When migrating in place, that is, migrating without purchasing additional hypervisor nodes, what is the realistic number of VMs that can be migrated at one time? 
23. How will backup and DR be handled whilst two environments co-exist? 
24. What fail-back plans have been considered? 
25. When is fail-forward an option? 
26. Do you have the capacity to create a test environment? 
27. How will day-2 operations such as CVE, Upgrades, and scaling be tested prior to changing hypervisors? 
28. Does it make sense to simulate an outage and try/test a new vendor’s support teams and support workflows? 

• Author
• Recent Posts

Chris Jones

Latest posts by Chris Jones (see all)

• Top 5 considerations for migrating off VMware - September 20, 2024
• FinOps: Applying Earned Value Management to maximize ROI - June 18, 2024
• Top 6 FinOps KPIs for EKS   - June 17, 2024