Every organization still running VMware sits somewhere on the same spectrum right now. On one end are the teams that have already accepted Broadcom’s new terms, signed the bundle, and moved on. On the other are the teams that have already decided to leave and are mid-migration or done. Most organizations we talk to are in between: still weighing the options rather than committed to one, running the numbers on renegotiating, moving to a different hypervisor, or rethinking virtualization altogether as part of a broader infrastructure decision.
What has been missing from that conversation is a way to make a decision on the technology rather than on the bill. Red Hat is offering this option now. On qualifying three-year agreements that include a Virtualization Migration Assessment, it will waive the first year of your OpenShift Virtualization subscription cost. Deals have to be signed by December 31, 2026.
That offer lands at a specific moment. General Support for VMware vSphere 8 ends on October 11, 2027. Sure, the date sounds comfortably distant, right up until you write down everything that has to happen before it.
Neither date is a migration plan on its own. iShift was the go-to regional partner for VMware implementations for years before the Broadcom acquisition, and we have carried that same depth of hands-on migration experience into helping organizations plan and execute their exits since. Here is how we would use these two dates.
October 2027 Sounds Far Away. For a Data Center, It Isn’t.
When General Support ends, Broadcom stops delivering security patches, bug fixes, and hardware compatibility updates for vSphere 8. However, your environment doesn’t stop working that day. But newly discovered vulnerabilities go unpatched and the layer underneath your entire VM estate is in a different risk position than it was the day before.
Here is the part that often gets forgotten. From what we have seen managing VMware exits, organizations don’t just move VMs. They work through a sequence:
| # | Phase | What actually happens |
|---|---|---|
| 1 | Discovery | Inventory what is actually running, who owns it, and what it talks to. |
| 2 | Assessment | Sort every workload: move, retire, replace, or leave alone. |
| 3 | Target Platform | Decide where each group of workloads should land. |
| 4 | Remediation | Fix what would break on the way: unsupported OS versions, drivers, network mappings, integrations. |
| 5 | Pilot | Move a representative slice and prove the playbook before you scale it. |
| 6 | Migration Waves | Batches sized to your change windows and your tolerance for downtime. |
| 7 | Validation | Confirm the applications, backups, DR, and monitoring all work on the new side. |
| 8 | Decommission | Retire the old environment, and with it the cost of carrying it. |
Every phase has owners, dependencies, and change windows attached. Skip one and it shows up later, usually during a migration wave, usually at night.
Start with the Workloads, Not the Hypervisor
The hypervisor is easy to talk about because it has a logo. The workloads are what determine the plan. Before any platform decision, we sort the estate against nine questions:
- OS and application compatibility: What does the application vendor support on the target platform, in writing?
- VM dependencies: What talks to what, and what breaks if the order changes?
- Networking and complex network configurations: VLANs, segmentation, firewall rules, and a decade of accumulated exceptions.
- Storage and large or multi-disk VMs: Big VMs take time to move, and they set your downtime window.
- Backup and DR integrations: Recovery has to work on the new platform from day one, not in phase two.
- Databases and applications with special shutdown and startup procedures: The ones with a runbook and one person who knows it.
- Legacy operating systems and appliances: Some won’t run on the new platform and some won’t be supported there.
- Hardware dependencies: Passthrough devices, GPUs, USB license keys.
- Migration windows and acceptable downtime: Agreed with the application owner, not assumed by infrastructure.
Red Hat’s own product marketing team makes the same point. In its announcement of the promotion, it says the virtual machines themselves are rarely the difficult part. The work is in everything built around them over the years: backup and recovery, DR runbooks, storage, network and segmentation policy, monitoring, and the application vendors whose support statements you need before anything moves.
This is also where we lean on our Proof of Value environment, a standing lab where we test candidate platforms, Red Hat OpenShift Virtualization included, against workload patterns like yours: multi-disk VMs, GPU passthrough, clustered databases, legacy appliances. Instead of taking a vendor’s compatibility claims at face value, you can see how your kind of workload actually behaves on the target platform before it is anywhere near your assessment or your budget.
The Migration Tool Is Not the Migration Strategy
Migration tooling is good and getting better. Red Hat’s migration toolkit for virtualization, for example, is built to move VMs from other hypervisors into OpenShift Virtualization. Tools like that automate conversion and replication. That is their job.
However, they don’t answer the questions that decide whether a migration goes well:
- Should this workload move at all?
- Where should it go?
- What dependencies will break?
- How do we validate it worked?
Those are judgment calls. They depend on your estate, your applications, and your risk tolerance, and no utility makes them for you. A vendor selling a migration tool hands you the tool. Our approach starts from the questions, tests the candidate answers in our Proof of Value environment, and then chooses the tooling that fits.
Building a VMware Exit Strategy
A VMware exit strategy is fundamentally about creating options. Some organizations keep part of their VMware footprint while migrating select workloads. Others move toward Microsoft Hyper-V, another private cloud platform, or public cloud infrastructure. The right destination depends on the workloads, applications, business requirements and economics of each environment.
The first step is understanding your current position.
What the Red Hat Promotion Covers and What It Does Not
The terms, per Red Hat’s promotion page: on qualifying three-year agreements that include a Virtualization Migration Assessment, Red Hat waives the first year of your OpenShift Virtualization subscription cost. It is a limited-time offer for qualifying deals signed by December 31, 2026, and Red Hat determines eligibility.
| What it covers | What stays with you |
|---|---|
| Year-one OpenShift virtualization subscription cost, on a qualifying three-year agreement. | Hardware, migration work, training, and rollout. Your existing platform commitment stays, as well. |
The assessment requirement matters. The Virtualization Migration Assessment is a paid, two-week engagement delivered by Red Hat Consulting or an authorized Red Hat partner. iShift is an authorized delivery partner for the assessment, which means we can run it directly, against your environment, rather than handing you off to a separate team once the paperwork is signed. If you sign a qualifying agreement, the cost of the assessment is credited back through subscription discounts.
What the promotion removes is one real barrier: paying for the platform you are leaving while you fund the one you are moving to. Red Hat is explicit that a free first year shouldn’t be the reason you choose a platform. It takes the cost overlap out of the conversation so the decision can go back to the technology and the migration path. We agree, which makes the assessment work more important, not less. It is what tells you whether a three-year commitment is the right one.
If a three-year term makes you wary, that is a reasonable position, and Red Hat acknowledges it. Find out what qualifies and what years two and three look like before you commit to anything.
Use the Deadline to Create a Roadmap
A VMware exit is not just a hypervisor migration. It is an infrastructure transformation, and a deadline is a useful way to force the sequencing conversation. Work backward from two dates: December 31, 2026 for the promotion, and October 11, 2027 for vSphere 8 General Support.
| When | What should be happening |
|---|---|
| Now | You have a first look at your estate. Red Hat’s free migration advisor gives a snapshot of your VMware VMs, and a run against iShift’s Proof of Value environment shows how your specific workloads actually behave on OpenShift Virtualization. That is a starting point, not a plan. |
| Before you sign anything (promotion ends 12/31/26) | Assessment complete: every workload has a disposition, dependencies are mapped, blockers are named, downtime tolerance is agreed per application, and a wave plan exists. |
| After signing | Remediation, pilot, migration waves, and validation, in that order. |
| Before October 11, 2027 | Production workloads are off vSphere 8 and decommissioning is under way. |
None of this is complicated. It just takes longer than the date on the calendar suggests, which is the whole point of starting now.
Where iShift Fits
Rushed migrations carry risks of their own. The better approach is preparation.
If VMware still meets your organization’s technical, financial and operational requirements, understanding your environment still makes you better prepared to manage it. If you are already weighing VMware migration or alternatives, now is a good time to move from discussion to assessment.
The promotion pays for none of the work above. That work is what we do.
iShift was the go-to partner for VMware implementations for years before Broadcom’s acquisition changed the licensing and support picture for every VMware customer. Since then, we have put that same depth of hands-on VMware experience to work on the other side of the problem: helping organizations plan and execute full exits, with the assessments, migration plans, and execution to back it up.
We are also an authorized Red Hat delivery partner for the Virtualization Migration Assessment, so the assessment, the roadmap, and the migration itself can run as one engagement with one team, instead of being split across a vendor’s consulting arm and whoever executes the actual moves.
Our Proof of Value environment is the piece that ties it together. It lets you test Red Hat OpenShift Virtualization, alongside other candidate platforms, against your own workload patterns, before a single production VM moves and before you sign a three-year agreement. You get evidence from your own environment, not a vendor datasheet, to base the decision on.
If you want to know what a move would involve for your environment and whether the promotion is worth pursuing before December 31, talk to us.
Ready to see where your infrastructure stands?
Map out your path forward on your own terms before the next major security event forces your hand.
