VMware Migration to Red Hat OpenShift

A VMware migration needs a solid plan. But even a solid plan can go wrong if the first wave is picked badly.

The first wave is the first small group of VMware VMs moved to Red Hat OpenShift. It sets the tone for the rest of the migration.

One common mistake is picking VMs that feel safe because they have low traffic, light storage use, few users and almost no links to other applications. The migration may pass, but the team learns very little from it.

The other mistake is picking a workload with too much pressure around it. It may have many users, unknown application links, strict downtime limits, or a cutover window with no room to fix issues.

That is when a good migration plan starts to feel shaky.

For VMware migration to Red Hat OpenShift, the first wave should be small enough to manage and real enough to test the work. It should check storage, network access, backup, monitoring, user sign-off and rollback before larger services are moved.

Red Hat OpenShift Virtualization lets enterprises run virtual machines on OpenShift. Red Hat Migration Toolkit for Virtualization helps move VMs from VMware vSphere to OpenShift Virtualization.

Why VMware migration is being reviewed now

VMware has run enterprise workloads for years. Many firms know it well and have built operations around it. But now arises questions around it if the same virtualisation model fits the next five years.

Broadcom completed its acquisition of VMware on November 2023. VMware by Broadcom later announced a move to subscription licences and the end of sale of perpetual licences for many offers.

That change has pushed many IT and finance teams to review future cost, vendor risk and platform options.

Red Hat OpenShift is part of the review because it gives a different answer for each type of workload. A payroll plug-in bought from a vendor can move as a VM. A customer portal that changes every sprint can be rebuilt later. A reporting server nobody has used for months should be checked before it gets a migration slot.

That is the business reason for looking at OpenShift. It helps the company reduce VMware dependency without treating every VM as worth saving.

What the first wave should prove

The first wave should test the parts of migration that affect real work.

Pick VMs that people use. Pick VMs with data, login rules, network access, backup needs and monitoring. Each VM should also have an owner who can test the application after cutover.

After migration, the team should check real actions. Can users log in? Can the app read and write data? Can it reach the database, file share or API it uses? Are alerts reaching the right dashboard? Can backup restore the VM if needed? Can access rules match the old environment?

A dummy VM gives a weak result. It may move across, but it says little about production use.

A high-risk finance, ERP or customer portal also belongs later. It puts too much pressure on the first attempt.

The first wave should sit between those two choices. Real enough to test the plan. Low-risk enough to fix issues before larger workloads move.

How to choose the first batch of VMs

Use a short scoring method. Each VM should be reviewed against business use, technical fit and cutover risk.

The first batch should include 5 to 15 VMs for many mid-sized environments. Large enterprises may use a bigger number, but only after the process has been tested with a smaller set.

What Red Hat Migration Toolkit for Virtualization does

A VMware migration becomes risky when the old environment and the new environment are treated as if they work the same way.

They do not.

A VM in VMware has its own storage, network paths, access rules and backup routine. Red Hat OpenShift uses a different platform model. So before a VM can land there properly, those parts need to be matched with care.

That is where Red Hat Migration Toolkit for Virtualization helps.

It reads the selected VMware VMs and helps prepare them for Red Hat OpenShift Virtualization. The useful part is the mapping work. The tool helps connect the old VMware storage to the right OpenShift storage option. It also helps match the old VMware network to the right OpenShift network path, so users, databases, file shares and internal services can still reach the application after cutover.

The toolkit also gives teams two ways to run the migration.

Cold migration is the slower, easier option. The VM is switched off first. Its data is copied to OpenShift. Then the VM starts on OpenShift. This works well for workloads that can accept planned downtime.

Warm migration is used when downtime needs to be shorter. The first data copy happens while the VM is still running on VMware. During cutover, the VM is stopped, the last changes are copied, and the VM starts on OpenShift. This needs better timing, testing and team coordination.

The toolkit can manage the migration steps, but it cannot fix a weak first batch. If the wrong VMs are selected, the result may still disappoint. The first batch should include real workloads with known owners, known access paths, backup needs and enough usage to prove that the migration approach works.

What to check before the first wave

1. Ownership

Every VM in the first wave needs a named owner. That owner must approve the cutover window, test the app after migration and confirm that the service works.

Unnamed VMs should be reviewed before migration. Some may no longer be needed.

2. Storage

Storage is where many migration surprises appear.

Check disk size, growth rate, performance needs, backup policy, and restore targets. The first wave should include storage use that reflects the wider VMware footprint, but avoid the largest and riskiest data workloads at the start.

3. Network access

Map how users, APIs, databases, file shares and identity services reach each VM.

A migrated VM that boots fine but cannot be reached by users has failed the business test.

4. Backup and restore

Backup is part of the first wave, not a later task.

Before cutover, agree restore targets, backup tooling, retention needs and recovery tests. After migration, prove restore works from the new platform.

5. Security

Check access rights, privileged accounts, firewall rules, logging, patching and audit needs.

For firms under GDPR, ISO 27001, SOC 2, HIPAA or public sector review, evidence should be captured during the migration, not reconstructed later.

6. Rollback

Rollback should be written before cutover starts.

The team should know who makes the rollback call, how long they can wait, what data may change during the window and how users will be informed.

A practical first-wave plan

Week 1: Review candidate VMs

Pick a shortlist of 20 to 30 VMs. Remove anything with no owner, unknown app links or high business pressure.

Week 2: Score and select

Choose 5 to 15 VMs that give a useful test of storage, network, access, backup and monitoring.

Week 3: Prepare OpenShift

Check identity, access roles, storage classes, network mapping, monitoring, backup and support routes.

Week 4: Run a test migration

Migrate the selected VMs in a non-production window first where possible. Validate app behaviour, user access, logs and restore.

Week 5: Cut over

Run the agreed cutover. Keep the rollback window active until the owner signs off.

Week 6: Review results

Record what worked, what failed, what needs automation and which workloads are ready for the next wave.

What success should look like

By the end of the first wave, the team should know how a real VMware VM behaves on Red Hat OpenShift.

You should know how long the migration took, where storage needed attention, which network rules had to change, how backup worked, and what application owners had to test before sign-off.

The first wave should also give you a better migration script for the next group of VMs. That script should include cutover steps, testing steps, rollback steps, owner approvals, monitoring checks and handover notes.

This is where the value of the first wave comes from. It turns a migration idea into working knowledge. The next group of VMs can then be chosen with better timing, better testing and fewer surprises.

You should finish with:

• a tested migration playbook

• known storage and network patterns

• working backup and restore

• monitoring and alerts in place

• owner sign-off for each VM

• a list of workloads ready for wave two

• a list of workloads that need more work

• a list of workloads to retire

That is how VMware migration becomes a controlled programme instead of a large technical bet.

Work With a Red Hat Partner for VMware Migration to OpenShift

VMware migration needs a partner who can understand both sides: the current VMware environment and the OpenShift platform your team wants to run next.

Phases is a Red Hat partner with delivery in Denmark and India. We help enterprise teams plan the first wave, prepare OpenShift Virtualization, and use Red Hat Migration Toolkit for Virtualization with the right storage, network, access, backup and rollback checks in place.

The first step is a readiness review. We review a small group of VMware VMs, check ownership, usage, downtime, backup, access and risk, then help choose the right first wave.

Security is part of the same review. We check SSO, MFA, least privilege, logging, audit evidence, backup and disaster recovery needs, including GDPR, ISO 27001, SOC 2, HIPAA or public sector requirements where relevant.

Phases also brings wider trust marks as a Microsoft CSP, Umbraco Platinum Partner and Citrix Partner.

To plan your VMware migration to OpenShift with a Red Hat partner, start with a readiness review with Phases.

Book a VMware to Red Hat OpenShift readiness review