For more than two decades, VMware has been one of the most familiar names in enterprise infrastructure. It helped turn virtualization from an efficiency play into the foundation of the modern data center. Entire operating models, career paths, partner ecosystems, disaster recovery plans, and application portfolios have been built around VMware technology.
Now the proposed acquisition of VMware by Broadcom is forcing technology leaders to ask a question many have avoided for years:
Is our infrastructure strategy still the right strategy for the next decade?
The United Kingdom’s Competition and Markets Authority cleared the transaction in August after an extended review. Regardless of the final closing date, the acquisition has already created enough uncertainty to trigger serious conversations inside enterprises, managed service providers, software companies, and IT consulting firms.
That does not mean every VMware customer should panic, cancel a renewal, or begin moving thousands of virtual machines next Monday. It does mean every CIO, CTO, infrastructure leader, and enterprise architect should have a documented Plan A, Plan B, and preferably a Plan C.
After 20 years in IT leadership, I have learned that the worst time to design an exit strategy is when you desperately need one.
This Is Bigger Than One Acquisition
It is tempting to view the Broadcom-VMware deal as a procurement event. Licenses, product bundles, support models, and partner relationships may change. Those issues matter, but the larger issue is concentration risk.
Many organizations have allowed one virtualization platform to become the center of their infrastructure universe. Compute, storage, networking, backup, disaster recovery, monitoring, security, and automation may all depend on the same ecosystem. The platform becomes so deeply embedded that changing it feels impossible.
That comfort can become expensive.
When a critical vendor changes ownership, pricing, packaging, or strategic priorities, customers discover how much leverage they have surrendered. The technology may continue to perform well, but the business relationship becomes less predictable.
A strong technology strategy should survive a vendor acquisition, a price increase, a product retirement, a security incident, and a cloud outage. Managing cloud uncertainty with explicit options and accountable decisions makes the roadmap more resilient when an external assumption changes. If one external decision can throw the infrastructure roadmap into chaos, the roadmap depends too heavily on one assumption.
Do Not Confuse Migration With Evacuation
Technology uncertainty has a habit of becoming artificial urgency. An acquisition is announced, executives become nervous, vendors begin campaigning, and suddenly everyone wants a 90-day migration plan.
That is not strategy. That is adrenaline wearing a project-management badge.
A successful data center migration begins with the outcome. Leaving a platform is not an outcome. Lowering total cost, improving resilience, accelerating application delivery, reducing licensing exposure, strengthening cybersecurity, and enabling hybrid cloud flexibility are outcomes.
For some companies, the right answer may be to remain on VMware while renegotiating contracts, eliminating unused products, increasing automation, and developing a tested contingency plan.
For others, the acquisition may justify evaluating Microsoft Hyper-V, Nutanix AHV, KVM-based platforms, Red Hat OpenShift Virtualization, public cloud, or a broader application-modernization program.
The goal is not to replace one form of lock-in with another. The goal is to create options.
Start With an Honest Infrastructure Inventory
Every migration program eventually encounters the same awkward truth: the organization does not fully know what it owns.
There are production systems with clear owners and documentation. There are also abandoned development machines, mystery appliances, unsupported operating systems, dormant test environments, duplicate services, and servers created by employees who left years ago.
Some are useless. Some are quietly running an essential process nobody remembers until it stops.
Before choosing a destination, inventory the virtual machines, physical servers, containers, databases, storage, application owners, dependencies, performance requirements, licensing terms, recovery objectives, compliance obligations, and current costs.
This is not administrative overhead. It is where much of the financial value is uncovered.
A migration is an opportunity to retire zombie infrastructure, consolidate duplicate systems, eliminate technical debt, right-size capacity, and clean up years of operational drift. Moving everything exactly as it exists may be faster, but it also carries yesterday’s inefficiencies into tomorrow’s platform.
Organize the Migration Around Applications
Infrastructure teams naturally think in hosts, clusters, storage arrays, VLANs, and virtual machines. The business thinks in applications and services.
A server-by-server migration can appear technically successful while leaving an application unusable because a database, file share, identity service, firewall rule, certificate, scheduled task, or DNS record was overlooked.
Application-centric migration treats the web tier, application tier, database tier, integrations, identity dependencies, monitoring, backup, security controls, and network paths as one migration unit.
For each application, determine whether the best strategy is to retire, retain, rehost, relocate, replatform, repurchase, or refactor it. These options are commonly called the “7 Rs.” AWS Prescriptive Guidance explains that large migrations often favor rehosting, relocating, replatforming, and retiring before deeper modernization.
This framework is far more useful than treating every workload as a generic virtual machine.
Public Cloud Is an Option, Not an Automatic Answer
When enterprise leaders hear “data center migration,” many assume the destination should be AWS, Microsoft Azure, or Google Cloud.
Sometimes it should.
Public cloud can provide rapid provisioning, global scale, advanced data services, improved development velocity, and consumption-based economics. It can be especially attractive for variable workloads, analytics, disaster recovery, and organizations that need to expand quickly.
However, moving virtual machines into a public cloud without changing how they are operated can produce an unpleasant invoice. An oversized, always-on VM may cost more in the cloud than it did in the data center. Add storage, snapshots, network traffic, backup, security tools, premium support, and licensing, and the economics can shift quickly.
Cloud cost optimization must begin with the architecture. Establish tagging standards, budgets, ownership, rightsizing, automated shutdown policies, cost alerts, and regular optimization reviews before the first production wave.
Tools such as Azure Migrate can support discovery, assessment, readiness analysis, business-case development, and migration execution. The important point is not which tool wins. The important point is using evidence rather than enthusiasm to select a landing zone.
Hybrid Cloud May Be the Most Practical Destination
The future of enterprise infrastructure is unlikely to be entirely on-premises or entirely in public cloud. Most organizations will operate across several environments for years.
Some workloads must remain close to specialized hardware. Others have latency, sovereignty, compliance, or cost requirements. Some applications are ideal for SaaS, while others benefit from public cloud elasticity. Edge systems may require local processing with centralized governance.
That makes hybrid cloud a long-term operating model, not merely a transition phase.
A successful hybrid cloud strategy standardizes identity, security policy, observability, automation, backup, cost management, and application lifecycle practices wherever possible. The winning architecture is not the one with the most platforms. It is the one that lets teams place workloads intelligently without multiplying complexity.
Migration Automation Changes the Risk Equation
Data center migrations once required enormous manual effort. Teams exported machines, converted disk formats, rebuilt networks, recreated security policies, synchronized data, and scheduled long outage windows.
Modern migration platforms can automate much of the discovery, replication, conversion, synchronization, testing, and cutover process.
For example, Nutanix Move supports workload mobility across virtualized and cloud environments. Microsoft, AWS, Google Cloud, backup vendors, and specialist migration providers offer their own tools and services. The source article highlights how replication and snapshot-based synchronization can reduce disruption, although every environment still requires careful planning.
Automation is powerful, but it cannot automatically repair undocumented dependencies, unsupported operating systems, licensing restrictions, hard-coded IP addresses, fragile integrations, or unclear ownership.
The best programs combine automation with disciplined discovery, application testing, business validation, and rollback planning.
Begin With Low-Risk Migration Waves
One of the smartest things an IT leader can do is resist beginning with the most important system.
Start with workloads that are visible enough to teach the team something but not so critical that a problem becomes a corporate incident. Development systems, standalone internal tools, and low-risk departmental applications are good early candidates.
Then increase complexity through controlled waves.
Measure migration time, outage duration, defect rates, rollback frequency, performance changes, support tickets, and actual operating cost. A focused infrastructure monitoring practice gives each migration wave comparable evidence instead of relying on impressions. Turn every lesson into an updated runbook.
Migration factories work because they make the process repeatable. The first ten workloads may be slow. The next hundred should not be.
Test the Rollback, Not Just the Cutover
Most migration plans devote pages to moving forward and one vague sentence to going back.
That is backwards.
A cutover plan should define what happens if validation fails. Who makes the rollback decision? How much data could be lost? How are writes handled during transition? How long can the business tolerate degraded performance? What evidence is required before the destination becomes the system of record?
The rollback process should be tested before production cutover.
This is also the time to validate disaster recovery, backup integrity, cybersecurity controls, permissions, logging, monitoring, patching, and incident response. A migration that improves infrastructure but weakens recoverability is not progress.
Make the Business Case About More Than Licensing
Licensing uncertainty may start the conversation, but it should not be the entire financial model.
A credible analysis should include software subscriptions, hardware refreshes, storage, networking, data center facilities, cloud consumption, backup, security, migration services, temporary dual-running costs, training, staffing, productivity gains, downtime risk, and delayed-project costs.
Executives should see several scenarios: remain and optimize, partially migrate, fully migrate, or modernize over several years.
The cheapest option on a spreadsheet is not always the lowest-risk option. The most technically exciting option is not always the best business choice. The right answer is the one that delivers sustainable value while keeping risk inside the organization’s tolerance.
The Best Outcome Is Optionality
The Broadcom acquisition of VMware may ultimately produce stronger products and meaningful innovation. It may also bring changes that some customers do not prefer. In October 2023, nobody outside the companies can know every decision that will follow.
That uncertainty is exactly why now is the right time to prepare.
Technology leaders do not need to predict the future perfectly. We need to build organizations that can respond to it.
Inventory the environment. Understand application dependencies. Benchmark costs. Evaluate alternative platforms. Build a proof of concept. Test migration tools. Train the team. Negotiate from a position of knowledge. Create a timeline aligned with renewals and hardware lifecycles.
Most importantly, do not frame the project as escaping a vendor.
Frame it as building a more resilient, flexible, secure, and economically sustainable technology platform for the business.
That is the part of this story I find exciting. Major industry changes force us to revisit assumptions that became invisible through familiarity. They give us permission to simplify, modernize, automate, and design the environment we would choose today—not merely maintain the one we inherited.
A VMware migration may or may not be right for your organization.
A VMware migration strategy absolutely is.
