KungFuPandiKungFuPandi
← Back to cloud
cloud

what commonly goes wrong - When you plan to migrate from Vmware environment to hyperscalers

General Mistakes we do when we planning migration

August 21, 2026
  1. Discovery and Assessment Gaps
  • Incomplete inventory: missing VMs, shadow IT servers nobody documented, or apps someone forgot exist
  • Stale CMDB data used instead of live discovery, leading to sizing based on wrong numbers
  • Dependencies not mapped: app A silently needs app B, and B doesn’t get migrated in the same wave
  • Underestimating actual utilization (sizing off peak vs average CPU/memory can blow up costs or cause performance issues)
  • Skipping a proper OLA-style licensing analysis, missing savings or compliance exposure
  1. Application Compatibility
  • Legacy apps hardcoded to specific OS versions, drivers, or hardware quirks that don’t exist in the cloud
  • Apps that assume low, consistent latency to a database or file share now separated by a WAN link
  • License checks tied to hardware identifiers (MAC address, CPU ID, physical dongles) that break the moment hardware changes
  • Clustered applications (like database clusters) relying on shared storage or multicast, which behave differently or aren’t supported the same way in cloud networking
  • 32-bit or unsupported OS versions that cloud providers won’t fully support
  1. Networking
  • Hardcoded IP addresses scattered across configs, scripts, and license files (covered in detail earlier), causing outages after re-IP
  • DNS not updated everywhere, some services still resolving to old on-prem addresses
  • Firewall rules and NSX-style micro-segmentation not recreated correctly in the cloud, either breaking connectivity or leaving gaps
  • Insufficient bandwidth or high latency on the connection used for the actual data transfer (VPN vs Direct Connect/ExpressRoute)
  • Overlapping IP ranges between on-prem and cloud VPC/VNet, blocking a clean hybrid connection
  • MTU mismatches over VPN tunnels causing silent packet fragmentation issues
  1. Storage and Data
  • VMDK to cloud disk conversion issues (alignment, format, corruption during conversion)
  • RDMs or SAN-attached storage with no direct cloud equivalent, requiring redesign, not just a copy
  • Underestimating data transfer time for large datasets over available bandwidth
  • Data consistency issues if replication runs for days and the source keeps changing (a common problem with big databases)
  • Forgetting to migrate file shares, backups, or archived data sitting outside the VM itself
  1. Security and Compliance
  • Overly permissive default settings on new cloud resources (open security groups, public S3 buckets/blob storage)
  • Data residency violations, workloads landing in the wrong geographic region for regulatory reasons
  • Encryption gaps, data unencrypted in transit during migration or at rest post-migration
  • Identity and access setup rushed, leading to over-privileged accounts or unmanaged root/global admin access
  • Compliance certifications (HIPAA, PCI-DSS, etc.) assumed to carry over automatically, when they actually require separate validation in the new environment
  1. Licensing
  • Windows Server/SQL Server licensing not properly transferred (License Mobility rules, BYOL vs pay-as-you-go)
  • Third-party software licenses tied to on-prem hardware counts or physical dongles, breaking after migration
  • Oracle licensing traps, Oracle’s cloud licensing rules are notoriously strict and can create unexpected cost or compliance exposure
  • Missing out on BYOL discounts because nobody checked eligibility before migrating
  1. Cost
  • No reserved instances/savings plans purchased after migration, paying full on-demand rates indefinitely
  • Right-sizing skipped, VMs migrated at the same specs as on-prem “just to be safe,” resulting in oversized (and overpriced) cloud instances
  • Data egress costs underestimated, especially in hybrid setups with lots of back-and-forth traffic
  • No cost monitoring/alerts set up, so overspend isn’t caught until the bill arrives
  1. Testing and Cutover
  • Insufficient testing in the new environment before cutover, performance and functionality assumed rather than verified
  • No rollback plan if something goes wrong post-cutover
  • Cutover window underestimated, especially for large databases needing final sync
  • DNS TTLs not lowered in advance, causing slow failover during cutover
  • Skipping a proper pilot/wave-based approach and trying to move everything at once (“big bang” migrations carry much higher risk)
  1. Operational Readiness (Post-Migration)
  • Monitoring and alerting not recreated in the cloud (teams flying blind right after go-live)
  • Backup strategy not re-established in the new environment
  • Runbooks and operational documentation not updated to reflect the new architecture
  • On-call teams not trained on the new platform’s tools before go-live
  • DR/failover plans not tested in the new environment
  1. People and Process
  • Underestimating the skills gap, ops teams used to VMware tools need real ramp-up time on AWS/Azure-native tools
  • Business stakeholders not looped in early enough, surprises during UAT that could’ve been caught during planning
  • No clear ownership after migration (who supports what, especially with a partner/SI involved)
  • Change freeze not respected, other teams making changes to the source environment mid-migration, causing data drift
  1. Governance and Landing Zone
  • No proper landing zone/account structure set up before migrating (security boundaries, tagging strategy, cost allocation)
  • Tagging/naming conventions skipped, making cost tracking and resource management painful later
  • No guardrails (policies, budgets, service control policies) in place before workloads start landing