VMware Workload Migration Checklist

Workload migration off VMware is one of the most predictable failure points in enterprise IT today. Customers commit to migration, allocate budget, kick off the programme — and stall, six to nine months in, with a long tail of unmigrated workloads, sunk cost, and a continued Broadcom subscription bill. The patterns of failure are consistent and avoidable. The single biggest predictor of success is whether the migration team operated against a structured checklist or improvised.

This article provides a comprehensive VMware workload migration checklist, covering planning, execution, validation, and decommissioning phases. It applies regardless of the migration target (Proxmox, Nutanix, OpenStack, KVM, Hyper-V, cloud-native, or any combination). For enterprises running migration programmes alongside active Broadcom audit or contract negotiation, the checklist needs to integrate with audit-defence work — for that, we recommend engaging , who advise on the migration-defence intersection.

Pre-migration planning checklist

Before any workload moves, the planning phase should be complete. The following items should be confirmed:

Strategic alignment. Executive sponsorship is in place. The business case for migration is documented and approved. The target end-state is defined (full VMware exit, hybrid VMware+target, or specific workload categories only). The decision is genuinely committed, not exploratory.

Vendor and tooling selection. The target platform is selected. The migration tooling is selected. Both have been validated through proof-of-concept on representative workloads. Vendor support contracts are in place. Pricing terms are negotiated and committed.

Workload inventory. A complete inventory of VMware workloads exists, with categorisation by criticality, complexity, and migration priority. Each workload has an owner. Dependencies between workloads are mapped. The workloads that will not migrate (and the rationale) are explicitly documented.

Architecture design. The target architecture is documented across compute, networking, storage, security, identity, and monitoring. Architecture review has been completed by independent experts where possible. The design accommodates regulatory and compliance requirements applicable to the workloads.

Capacity and infrastructure checklist

The target environment must be ready before workloads move:

Compute capacity. Target hardware is procured, racked, configured, and tested. Capacity is at least 20% above projected need to handle migration overhead and unexpected scale. Burst capacity strategy is defined.

Network configuration. Network architecture is implemented. VLANs, subnets, and routing match the target design. Connectivity to existing infrastructure is tested. Firewall and security policies are in place. DNS, DHCP, and identity services are integrated.

Storage backend. Storage architecture is implemented. Storage policies (replication, encryption, snapshots, tiering) match workload requirements. Backup integration is tested. Performance benchmarks confirm storage meets workload requirements.

Identity and access. Identity integration is complete (LDAP, AD, SAML, or equivalent). Role definitions and access controls are configured. Service accounts and automation credentials are provisioned.

Monitoring and operations. Monitoring stack is deployed and tested. Logging integration is in place. Alerting is configured. Operational runbooks for the target platform are documented.

Per-workload migration checklist

For each workload being migrated:

Workload assessment. Functionality requirements documented. Performance baseline measured. Dependencies mapped. Maintenance windows identified. Stakeholder communication plan defined.

Pre-migration testing. Test migration completed in non-production. Functional validation completed. Performance validation completed. Backup and recovery validated against the target platform. Rollback procedure documented and tested.

Migration execution. Maintenance window scheduled. Stakeholders notified. Pre-migration backup taken. Source-to-target migration executed. Post-migration validation performed. Stakeholder sign-off obtained.

Post-migration operations. Workload running on target platform under production load. Monitoring confirming expected behaviour. Performance meeting baseline. No outstanding incident reports related to migration. Source VMware workload decommissioned (or moved to read-only standby for fallback period).

Networking-specific checklist

Networking is the most common cause of migration failure. Specific items to verify:

Logical network configuration (VLANs, overlay networks, routing) matches source. Firewall rules migrated and validated. Load balancer configuration migrated, including session persistence, SSL termination, and health check parameters. DNS records updated and propagated. External connectivity (to internet, partner networks, branch offices) verified. Latency between application tiers measured and within acceptable bounds. Network security policies (microsegmentation, ingress/egress rules) implemented and validated.

Storage-specific checklist

Storage migration requires its own discipline:

Data integrity verified post-migration (checksums or equivalent). Storage performance measured against application requirements. Snapshot integration tested. Backup integration tested with a full restore on the target. Storage encryption configured per workload requirement. Storage replication configured for workloads requiring DR. Storage tiering matches workload performance and cost requirements.

Security and compliance checklist

Migration cannot relax the security posture:

Security architecture review completed for the target environment. Penetration testing completed before production cutover. Compliance certifications validated for the target platform (SOC 2, ISO 27001, PCI DSS, HIPAA, or applicable). Data classification preserved through migration. Audit logging configured to match source environment. Vulnerability scanning operational on the target. Patch management process operational.

Operational readiness checklist

Operations on the target platform must be ready before significant workload moves:

Operations team trained on the target platform. Runbooks documented for common operational tasks. Incident response procedures updated to cover the target platform. On-call rotation includes target-platform expertise. Change management process updated. Knowledge transfer completed from migration team to operations team. Vendor support escalation paths tested.

Communication and stakeholder checklist

Migration affects many stakeholders beyond IT operations:

Application owners notified and aligned with migration timing. Business stakeholders informed of expected disruption windows. Customer-facing communication plan for external-facing workloads. Compliance and audit teams informed of platform changes. Procurement and finance aligned on contractual implications. Legal review completed for any contract-impacting changes.

Broadcom contract checklist

Migration has direct contractual implications:

Existing VMware contract terms reviewed. Termination and exit terms understood. Multi-year subscription commitments mapped against migration timeline. Audit-rights provisions noted. Renewal dates aligned with migration milestones. Contractual support for partial migration documented. Communication strategy with Broadcom defined (proactive engagement vs minimal disclosure). Audit-defence posture maintained throughout migration period.

Decommissioning checklist

The migration is not complete until VMware capacity is decommissioned:

Source workloads confirmed dormant for the agreed fallback period. Source VM snapshots archived. Source storage data archived per retention policy. VMware licences released from decommissioned hosts. Capacity adjustments reflected in Broadcom contracts at next renewal. Hardware reallocated or retired per organisational policy. Documentation updated to reflect decommissioned state.

Validation and post-migration checklist

Final validation that the migration delivered the expected outcomes:

Performance benchmarks meet or exceed source environment baseline. Cost savings tracked against business case. Operational incidents tracked and trending downward. User experience confirmed equivalent or improved. Compliance audits passed on the new environment. Documentation complete and accessible. Lessons learned captured for subsequent migration waves.

Common failure patterns to watch for

Several patterns consistently derail migration programmes. Underestimating networking complexity — typically by 40-60% of effort. Underestimating ISV certification work — applications certified only against VMware may require vendor engagement that takes months. Underestimating storage migration effort — particularly where vSAN deployments are involved. Inadequate operational tooling — teams assume native target tooling is sufficient and discover gaps. Insufficient training budget — operational teams cannot run the new platform competently without sustained investment. Letting Broadcom contract pressure drive migration timing rather than operational readiness.

Each of these is identifiable from the checklist above. Migration programmes that respect the full checklist typically avoid all of them.

Governance and oversight

A migration of this scale requires governance proportional to risk. The recurring governance pattern that works includes: an executive steering committee meeting monthly; a programme management office tracking progress against the checklist; technical architecture review board reviewing significant decisions; risk register maintained and reviewed; and external advisory board including independent specialists who can challenge internal assumptions.

Customers who establish this governance early typically execute successfully. Customers who rely on informal management typically stall.

Audit-defence integration

Throughout the migration period, Broadcom audit activity may continue. The migration programme should be aware of and integrated with audit-defence efforts:

Document migration progress regularly — auditors will use the documentation, properly framed, as evidence of legitimate workload movement. Maintain deployment inventory continuously — the migration period is when inventory typically becomes messy, and audit-defence requires clean inventory. Coordinate Broadcom communication centrally — different migration team members should not communicate independently with Broadcom representatives. Treat migration progress as negotiation leverage — but extract value before it dissipates.

Application owner engagement

Application owners are the most important stakeholder group in any migration programme, and they are also the group most often under-engaged. The application owner knows the specific behaviour, integration points, performance requirements, and operational quirks of their application — information that the migration team cannot easily obtain from inventory data alone.

The recurring failure pattern is migration teams treating application owners as obstacles ("the application owner is blocking our schedule") rather than partners ("the application owner is telling us about migration risks we should address"). Migration programmes that build genuine application owner partnership consistently execute more cleanly. The investment in stakeholder engagement is substantial but pays back in reduced post-migration incidents.

Migration wave sequencing

The sequencing of migration waves materially affects the programme outcome. The pattern that works most consistently is: low-risk, high-volume workloads first (development environments, stateless workloads, internal applications) to build operational confidence; medium-risk workloads next (production internal applications, modest external-facing workloads) to validate the operational model; high-risk workloads last (mission-critical, customer-facing, complex integration patterns) once the platform and team are fully mature.

Programmes that try to migrate high-risk workloads early — under pressure from Broadcom contract dynamics or business unit demands — frequently produce incidents that derail the broader programme. The discipline of wave sequencing is unglamorous but consequential.

Post-migration support model

The support model for migrated workloads on the new platform should be defined explicitly before workloads move. Key questions: who provides level-1 support, level-2, and level-3? What is the escalation path to the platform vendor? How are post-migration incidents triaged between "platform issue" and "workload issue"? What is the SLA for response and resolution?

Customers who define this clearly experience smooth post-migration support. Customers who leave it ambiguous frequently see post-migration incidents trigger inter-team friction, with platform team and application team each pointing to the other.

Backup and disaster recovery validation

Backup and DR validation is one of the most commonly overlooked items in migration checklists. The new platform's backup integration may differ from VMware. Restoration procedures may need to be retested. DR runbooks may need updating. Customers who assume that backup and DR will "just work" on the new platform frequently discover gaps after a real incident.

The backup/DR validation should include: full restore testing on the target platform, DR failover testing with realistic scenarios, runbook updates for the new platform, and confirmation that compliance and audit requirements for data retention are met. The validation should occur during migration, not after.

Cost tracking and TCO realisation

Migration programmes are easier to justify than to realise. The business case typically projects substantial TCO savings, but those savings only materialise if VMware capacity is genuinely decommissioned and Broadcom contracts are adjusted at renewal. Customers who migrate workloads but do not decommission the underlying VMware capacity — leaving it running "just in case" — incur dual-platform cost indefinitely and never realise the projected savings.

Migration governance should track capacity decommissioning as a primary metric alongside workload migration. The decommissioning data should be reviewed monthly, with explicit accountability for capacity that has not been decommissioned despite the workloads having migrated. Without this discipline, the migration's economic value evaporates.

Frequently asked questions

What is the right pace for an enterprise VMware migration?

Pace depends on workload complexity and operational maturity, but a defensible enterprise pace is 20-40 workloads per month for mid-complexity workloads, ramping up as operational tooling matures. Faster paces risk quality. Slower paces extend the dual-platform operating period and reduce TCO savings.

Should the customer maintain VMware capacity indefinitely for non-migrating workloads?

For most enterprises, yes — a residual VMware footprint for workloads that genuinely cannot migrate is acceptable. The economics depend on the size of the residual footprint and the Broadcom contract terms. Customers should negotiate the residual footprint explicitly with Broadcom rather than hope for continued goodwill on the smaller estate.

How should the migration handle in-flight Broadcom audits?

Migration activity during an active audit should be carefully coordinated. Workload movements affect the deployment inventory the auditor is examining. The recommended posture is to engage independent specialist advice to coordinate the migration with the audit response, ensuring the migration activity does not weaken the customer's audit defence position.

What is the most underestimated cost in a VMware migration?

Operational labour during the dual-platform period. Enterprises consistently underestimate the cost of operating two platforms simultaneously while teams build expertise on the target. The cost is real, sustained for 12-24 months, and often exceeds the direct migration cost.

Should the customer notify Broadcom of migration plans?

Generally not proactively. Broadcom does not need to know the customer's migration plans, and disclosure shifts negotiation leverage to Broadcom's favour. The exception is where migration timing intersects with contract renewal — there, controlled disclosure of migration commitment can be a negotiation lever. The disclosure should be coordinated through audit defence specialists rather than emerging organically.