VMware Migration to the Cloud: How to Make the Move Succeed

The news shook the IT world to its core: since Broadcom's acquisition of VMware, licensing costs have multiplied for many companies. Some customers report price increases by a factor of three to ten. Anyone who had been comfortably relying on vSphere and vCenter is suddenly facing an unpleasant bill and an even more unpleasant question: stay or go?

Why Now Is the Right Time

The licensing changes at VMware have an effect that Broadcom probably did not plan for: they force IT departments to fundamentally rethink their infrastructure. And that is actually a good thing. Because let's be honest, many VMware environments have grown organically over the years. There are VMs nobody can attribute to anyone anymore, snapshots older than some of the trainees, and network configurations that only a single person in the company understands (and that person is currently on vacation).

A cloud migration is the opportunity to clean house. Not everything has to be carried over 1:1. In fact, it should not be.

The Three Migration Paths

Lift & Shift: Fast, but Not Smart

The most obvious approach: take the VMs and push them into the cloud. Tools like VMware vCenter Converter or third-party solutions make this technically possible. You get your workloads into a new environment quickly, but you also take all the legacy baggage with you. It is like moving without decluttering first. Fine as a transitional solution, questionable as a long-term strategy.

Re-Platforming: The Golden Middle Ground

Here, workloads are lifted onto a modern platform without completely rewriting the application. A classic example: a VM running a Java application is packaged into a container and deployed on Kubernetes. The application itself remains largely unchanged, but the infrastructure around it is radically simplified. Automatic scaling, self-healing, declarative deployment: all of that comes practically for free.

Re-Architecting: The Supreme Discipline

Those who think long term rebuild their applications for the cloud. Microservices instead of a monolith, API-first, Infrastructure as Code. This costs time and money, but it pays off if the application is going to be developed further over the years. For an internal time-tracking tool with 50 users, it is overkill. For a customer-facing SaaS platform, it can be the decisive competitive advantage.

What Can Go Wrong in Planning

Underestimating the Network

The most common source of errors in cloud migrations is not the compute layer, but the network. In a VMware environment, you typically have flat networks, VLANs, and perhaps NSX for microsegmentation. In the cloud, the world looks different. VPCs, subnets, security groups, ingress controllers: the network model is fundamentally different. If you do not plan this cleanly from the start, you are building yourself a world of pain.

Ignoring Dependencies

VM A talks to VM B on port 8443, VM B needs an NFS share from storage system C, and storage system C has a backup window from 2 to 4 a.m. Dependency chains like these exist in every environment that has grown over time. They must be documented and understood before anything gets migrated. Application dependency mapping is not a nice-to-have, it is mandatory.

Miscalculating Costs

Cloud costs work differently from on-premises costs. No more CapEx, OpEx instead. That sounds liberating at first, but it can get expensive if nobody keeps an eye on the running costs. A VM running 24/7 is not automatically cheaper in the cloud than on your own hardware. The cost advantage comes from elasticity: scaling resources up when they are needed and back down when they are not. If you simply push your VMs 1:1 into the cloud and let them run permanently, you often pay more than before.

Data Sovereignty as a Decision Criterion

For German companies in particular, the location of the infrastructure plays a central role. GDPR compliance, industry-specific regulation (BAIT, KAIT, VAIT for financial services providers), or simply the requirement that data must not leave Germany: all of this argues against the big US hyperscalers and in favor of a German cloud provider.

That does not mean AWS or Azure are bad. But if your compliance team gets nervous at every audit because the data could theoretically be subject to the US CLOUD Act, then a German data center is the less stressful option. We have documented the entire sovereignty model with data center locations, GDPR architecture, and Schrems II position.

The Technical Migration Process

A proven process looks like this:

Phase 1: Assessment (2-4 weeks) Inventory of all workloads, classification by criticality and migration path. Which VMs can be migrated immediately? Which need adjustments? Which should perhaps simply be decommissioned?

Phase 2: Pilot (2-4 weeks) A non-critical application is migrated as a pilot. The team gets to know the new environment, makes mistakes in a safe space, and develops runbooks for the main migration.

Phase 3: Migration in waves (4-12 weeks) The remaining workloads are migrated in planned waves. Each wave is tested and validated before the next one starts. Rollback plans are defined for every wave.

Phase 4: Optimization (ongoing) After the migration, the real work begins: right-sizing resources, optimizing costs, building out monitoring, deepening automation.

Kubernetes as the Target Platform

If you are migrating anyway, why not do it right? Managed Kubernetes is a natural choice as a target platform, especially for applications that can be containerized. Instead of managing VMs, you define your infrastructure declaratively. GitOps workflows enable reproducible deployments. Horizontal Pod Autoscaling reacts automatically to load. And if a node fails, Kubernetes redistributes the workloads to the remaining nodes on its own. If you want to keep classic VMs, however, you can continue running without an architecture change on our VMware Cloud Director IaaS or the HCI-based Managed SUSE Virtualization.

The shift from VM-based thinking to containers and Kubernetes is a paradigm shift. But one that pays off. Your developers will thank you (at the latest, once the initial learning curve is behind them).

Conclusion

A VMware migration is not a weekend project. But it is not rocket science either. With the right planning, a clear migration path, and a partner who knows both the old and the new world, the move succeeds without production outages or sleepless nights.

Planning a VMware migration and looking for a partner to move your workloads safely into a German cloud environment? focusnet operates its own data centers in Germany and offers Managed Kubernetes, S3 Object Storage, and IaaS from a single source. Get in touch with us — together we will develop your migration roadmap. Contact us