Getting off VMware without breaking a regulated service: a de-risking method for the CIO who owns the outcome

You have been told to get off VMware, or to justify staying. Either way you own the risk if the migration breaks a service a regulator watches. This post is for the CIO walking the floor at Gartner IT Symposium/Xpo in Orlando this week with that decision open. It uses one invented example, Broadcom's own public notices for the facts, and a method that works whichever destination you are looking at.

The decision, as Larkspur Mutual faces it

Larkspur Mutual does not exist. It is an illustrative regional insurer I invented for this post. It is not a customer, an employer or a composite of any real firm, and nothing about its estate is real data.

Larkspur runs its core platforms on vSphere 8. It has entities in the EU, so DORA applies. Its support term ends in the spring. The board has asked one question, twice: "are we off VMware yet?" The CIO's answer has three possible forms: renew and stay, migrate everything, or migrate part and stay for the rest. All three have the same constraint attached. Whatever Larkspur does, the claims-intake service has a tolerance of four hours (an invented number, set by Larkspur's own risk function), and a migration that breaks it is worse than any platform decision.

So the CIO does not need a destination first. The CIO needs to know what moves, what it takes to prove it can move, and which date on the calendar actually forces the choice.

What changed, from the vendor's own pages

I limited this to what Broadcom and VMware have published themselves, and I quote their wording so you can check it.

• Subscription only, and a smaller menu. Broadcom's January 2024 notice says that, as announced on December 11, 2023, VMware "reached a new milestone in its journey over the last two years to streamline and simplify its portfolio and transition from perpetual licensing to a subscription model." VMware Cloud Foundation and VMware vSphere Foundation are "available as subscription software only", and "many VMware software solutions will only be offered as part of VMware Cloud Foundation (VCF) or VMware vSphere Foundation (VVF). They will not be available for purchase as standalone point solutions." The same page lists vSphere, vSAN, vCenter and Site Recovery Manager among the offers that are no longer standalone.
• What an existing contract keeps. The same notice says that for customers who are not up for renewal, "VMware will continue to offer active support through the duration of your support contract", and that "at the time of renewal" you align your requirements "to VMware's updated portfolio of offerings." The renewal date is the date the bundle question becomes yours.
• vSphere 7 is already out of general support. Broadcom's article on End of General Support for vSphere 6.5/6.7/7.0 gives October 15, 2022 for 6.5 and 6.7 and October 2, 2025 for 7.0. VMware's March 2025 reminder says that after October 2, customers still running 7.x "will not be able to receive product support, security patches and updates", and that previously published fixes remain available as self-service for the remaining agreed maintenance period.
• vSphere 8 has a date. Broadcom's Upcoming End of Service for vSphere 8, vSAN 8, Aria 8, NSX 4 and VCF 5 lists ESXi 8.x, vCenter Server 8.x and vSAN 8.x at October 11, 2027, and says "post the listed End of Service dates, there will be no Technical Support and no new patches for these product versions." That is less than twelve months after Symposium week. The same page recommends adopting VCF 9 or VVF 9.
• One footnote that matters. The March 2025 reminder lists an End of Technical Guidance date of April 2, 2027 for vSphere 7.x, with the note "Does not apply to Broadcom contracts. Applicable to valid VMware contracts only." Which contract paper you hold changes which dates apply to you. Check yours.

That is the whole factual case, and it is short. It does not say what any of this costs, and neither will I. It says there are two dates on your calendar, your own renewal and October 11, 2027 for vSphere 8, and that between them you have to either upgrade, move, or accept an unsupported estate. I make no claim about Broadcom's intent, and I have no figure for how many customers are doing any of this.

The method

The method is vendor-neutral, and "stay" is a legitimate output of it. If the evidence says stay, you have a defensible reason and a dated exit option.

1. Inventory and map dependencies first. Not "how many VMs" but "what does each one talk to." Network flows, shared storage, identity, certificates, scheduled jobs, backup policies, monitoring agents. Larkspur finds that the claims-intake service reaches into a batch scheduler nobody has touched in years. That dependency, not the VM count, sets the order of work.

2. Classify every workload into one of four outcomes.

Do not combine move-as-is and modernise in one wave. It doubles the change to every application and ties your exit date to your slowest refactor.

3. Pick a reversible pilot, with a written rollback. The pilot has to be something you can undo without an outage. Write the rollback before the move: what you restore from, who decides, and at what point the decision has to be taken.

4. Prove the exit on one important business service, and time it. This is the step most plans skip. Take one service, claims intake for Larkspur, move it, and measure the time it is unavailable or degraded. Put that number next to the tolerance. A drill that meets the tolerance is evidence. A drill that misses it is also evidence, and it is better to learn that on one service than on forty. My earlier post on resilience as a regulated number sets out why regulators now ask for this kind of measurement.

5. Run in parallel before you cut. Keep the source running while the destination serves real traffic, or a faithful copy of it, across at least one business cycle that matters to the service: a month-end, a batch run, a peak week. The first time the destination meets quarter-end should not be the cutover.

6. Treat licensing and support overlap as a risk item. I am not talking about money. I am talking about the calendar. Write down three dates: when your current support term ends, when your last workload is expected to finish moving (including the rollback window), and October 11, 2027 if you run vSphere 8. If the second date is later than the first, you have a gap to plan for, and the plan has to exist before the renewal conversation, not after it. Also check that the destination's own support covers what you will run on it, from day one.

7. Plan for skills and operating model. A new platform means new runbooks, new on-call rotations, and a period when two toolchains run side by side. Ask how many people can run each important procedure from the page, at 3 a.m., without calling the person who wrote it. If it is a short list, the migration plan needs training and a second operator before it needs a cutover date.

8. Collect the evidence a regulator would ask for. If you are an EU financial entity, DORA Article 28(8) says, for ICT services supporting critical or important functions, that "financial entities shall ensure that they are able to exit contractual arrangements without: (a) disruption to their business activities, (b) limiting compliance with regulatory requirements, (c) detriment to the continuity and quality of services provided to clients." It adds that "exit plans shall be comprehensive, documented and, in accordance with the criteria set out in Article 4(2), shall be sufficiently tested and reviewed periodically", and that entities shall "identify alternative solutions and develop transition plans enabling them to remove the contracted ICT services and the relevant data from the ICT third-party service provider and to securely and integrally transfer them to alternative providers or reincorporate them in-house." The regulation has applied since 17 January 2025.

I am not saying your VMware licence is itself a DORA arrangement; that is a question for your counsel. I am saying that if the destination supports a critical or important function, Article 28(8) applies to it from the first day. So the exit you prove leaving VMware should also be rehearsed in reverse, from the destination, before you depend on it.

What to ask vendors on the Gartner floor

Ask these of any destination: a hyperscaler, a hypervisor vendor, a hyperconverged platform. The answer you want is a demonstration or a document, not a reassurance.

1. Show me a rollback. Take a migrated workload back to where it came from, live or on video, with the elapsed time on screen.
2. Who carries the migration risk? If cutover misses my tolerance, what is yours to fix, what is mine, and where is that written?
3. What moves VMs without re-IP? Which of my addresses, identities, certificates and DNS records survive the move, and which have to change?
4. What breaks in backup, DR and security tooling? Which of the tools I run today work on day one, which need replacing, and which have no equivalent?
5. What will my team need to do at 3 a.m. that they cannot do today? How long does that take to learn, and who trains them?
6. Which decisions are fixed at deployment? Show me the constraints that cannot be changed later, in your own documentation.
7. What is the exit from you? In what documented form do my data and configuration leave, and who has done it?

If a vendor cannot answer number 1 or number 7, that tells you something about the other five.

One test before you sign anything

Before you sign a renewal, a purchase order or a migration contract, run this: take one important business service, move it, roll it back, and write the measured times beside its tolerance. Then check that the date your rollback window closes falls inside your current support term.

If both pass, you have evidence for whichever path you choose, including staying. If either fails, that is the finding, and you want it before the signature, not after.

What this post does not claim

• Larkspur Mutual is invented. Not a customer, not a composite, not a case study. Its tolerance and timeline are made up to show the method.
• No prices. Cost here means tech debt, operational load, lock-in and exit. Subscription and contract prices are left out on purpose.
• Nothing about intent or customer numbers. The facts are Broadcom's own published notices, quoted. I make no claim about why Broadcom made these changes or how many customers are affected.
• Not a verdict on any platform, including staying. The method is vendor-neutral and "stay" is a valid outcome.
• Not legal advice. DORA is quoted from the Official Journal text I read. Check the regulation, and your own regulator's guidance, before relying on it.
• Not a forecast. I make no claim about how long any migration takes. The drill is how you find out.

I work at Nutanix; this is my personal view and not a company statement.

Sources (all opened 2026-10-13): Broadcom / VMware, VMware End Of Availability of Perpetual Licensing and SaaS Services (22 January 2024; subscription-only offers, the portfolio change, what existing contracts keep); Broadcom, End of General Support for vSphere 6.5/6.7/7.0 (EoGS dates); VMware, Reminder: vSphere 7 to reach End of Service on Oct 2, 2025 (31 March 2025; the post-EoGS position, the technical-guidance footnote); Broadcom, Upcoming End of Service for vSphere 8, vSAN 8, Aria 8, NSX 4 and VCF 5 product suite (11 October 2027); Broadcom, Product lifecycle and end of life information (where the per-product lifecycle is published; it sits behind the support-portal login); Regulation (EU) 2022/2554 (Digital Operational Resilience Act), Article 28(8) and the application date, Official Journal L 333 of 27.12.2022, read from the EU Publications Office (the EUR-Lex page returned an empty response); my earlier post Resilience is now a regulated number.