An acquisition announcement is a free option on your exit plan

The week

Deep inside most large banks, hospitals and government agencies sits a layer of software that almost no executive ever sees, but that nearly everything else depends on. In the last week of May 2022, that layer got a new prospective owner.

On May 26, 2022, Broadcom announced an agreement to acquire VMware in a cash-and-stock deal valued at about 61 billion dollars, based on Broadcom’s share price the day before. Broadcom would also take on about 8 billion dollars of VMware’s net debt. VMware shareholders could choose cash or Broadcom stock, with elections prorated so that about half of the shares were paid each way.

The announcement carried two signals for customers. First, Broadcom said its existing software group would be rebranded and operate as VMware after closing, with Broadcom’s infrastructure and security software folded into a larger VMware portfolio. Second, it told investors the deal was expected to add about 8.5 billion dollars of pro forma EBITDA, a common measure of operating profit, within three years of closing.

Investor documents are public, and customers could read that second figure as well as shareholders could. A buyer promising that kind of profit contribution would look for it in pricing, product focus and costs. Nobody outside Broadcom knew which levers it would pull, but the direction was written down on announcement day.

The agreement also included a 40-day go-shop period, ending on July 5, 2022, during which VMware could seek competing offers. The deal went ahead with Broadcom. VMware had only recently become fully independent: Dell, which had held a majority stake, completed the spin-off of VMware in November 2021. Within seven months of standing alone, it had agreed to a new owner.

Why that mattered to so many organizations comes down to what VMware actually did.

VMware’s best-known product is a hypervisor. A hypervisor is software that lets one physical server behave like many separate computers, called virtual machines. Instead of buying a separate physical machine for every application, an organization runs dozens of virtual machines on a single server. That saves space, power and money, and it makes systems easier to move and recover. VMware also sold the management software that lets IT teams run thousands of these virtual machines across a data center.

The portfolio reached further. VMware also sold software that virtualized storage and networking, virtual desktops, mobile device management and endpoint security. An organization that used several of these had exposure well past the hypervisor, often under a single enterprise agreement.

VMware’s hypervisor and management software ran a large share of on-premises data centers in banks, health systems and public agencies. On-premises means in facilities the organization owns or controls, as opposed to a public cloud. It often ran underneath core banking systems, the ledgers that record every account and transaction. It also ran under electronic health record systems that hold patient charts, and case management systems that agencies use to track benefits, permits and court matters.

The buyer had a track record customers could study. Broadcom had bought CA Technologies in 2018 and Symantec’s enterprise security business in 2019, and customers of those products had seen changes in focus, licensing and support afterward.

The calendar added pressure of its own. VMware’s vSphere 6.5 and 6.7 releases reached the end of general support in October 2022, so many customers already faced an upgrade decision during the months the deal was pending. An upgrade is a natural moment to ask whether to stay.

A deal this size does not close overnight. The VMware acquisition needed regulatory approval in several jurisdictions, with China’s regulator among the last to clear it, and it did not close until November 22, 2023. In the announcement week itself, nothing changed for customers except the outlook. That gap between announcement and closing turned out to be the most valuable thing the deal gave them.

Infrastructure teams usually react to a supplier acquisition in one of two ways: alarm that fades, or a decision to wait and see. For a platform as embedded as VMware, both were expensive.

The better frame comes from finance. An option, in financial terms, is the right but not the obligation to do something later at a price set today. You pay a small premium now for flexibility you may or may not use. Homebuyers do something similar when they pay a modest fee to lock a mortgage rate for a few months: if rates rise, the lock is valuable; if not, they have lost only the fee.

An announcement that precedes closing by many months hands every customer a cheap option. Nothing yet depends on the new owner’s decisions, contracts are still on known terms, and the cost of preparing an alternative is lowest when there is no deadline. Like any option, it has value only if someone pays the small premium to hold it.

Holding it takes three steps: buying the option by pricing a credible exit, keeping it alive with modest ongoing investment, and exercising it, or deciding not to, at the moment terms change.

Option pricing also explains why this particular window was so valuable. An option is worth more when the future is uncertain, when there is more time before it expires, and when the cost of using it is known. All three applied in 2022. The new owner’s terms were unknown but had a stated profit target behind them. The time to closing, plus the remaining run of existing contracts, was long. And the cost of using the option, migration, could be estimated.

The premium, by contrast, was small: staff time for an inventory, rough estimates, a few letters to application vendors and a modest pilot. Even an organization that never used the option got something for that premium, because a clean inventory and a credible alternative improve any renewal.

This article is written knowing how the story turned out, which invites hindsight bias. The argument has to hold even in a world where the new owner had changed nothing. It does, for that reason: the premium bought negotiating evidence and housekeeping that pay off at any renewal, whether or not the terms change.

Why a platform like this is so hard to leave

Executives sometimes ask why an organization cannot simply switch infrastructure suppliers the way it might switch office supply vendors. The answer is that everything else in the data center gets built around a virtualization platform.

Over years, an IT team builds a great deal on top of it. Backup systems are configured to copy virtual machines in a particular format. Disaster recovery plans, the arrangements that let an organization restart critical systems at a second site after a fire, flood or outage, rely on specific replication products to keep the second site in sync. Monitoring tools, automation scripts and security controls are all tuned to the platform. Staff build their skills and their daily routines around it.

Then there are the applications on top. Many large software vendors, particularly in banking and healthcare, test and certify their products on specific platforms. Suppose a hospital’s electronic health record vendor supports its product on only one hypervisor. Running it anywhere else may void support, which no hospital will risk for a system that clinicians depend on every minute.

Finally, there is the paperwork regulators expect. Regulated organizations must show auditors and examiners that their systems are configured securely, that access is controlled and that recovery has been tested. Moving to a new platform means producing that evidence again from scratch.

These obstacles do not make leaving impossible. They make it slow, and slowness is exactly what an option is meant to address. The time to prepare an alternative is before you need it.

Lock-in, layer by layer

The dependence builds in layers, and each layer has its own exit cost. At the bottom is hardware. Servers, storage arrays and network cards are certified for particular hypervisors, and an older fleet may not be certified for an alternative at all. A platform change can therefore force a hardware refresh that nobody budgeted.

The next layer is virtualized storage and networking. Organizations that adopted those products moved functions that once lived in separate hardware into the platform itself. Firewall rules that isolate one group of servers from another, a technique called micro-segmentation, may be written in the platform’s own policy language. Leaving means rebuilding those controls elsewhere, and proving to auditors that the new ones are equivalent.

Above that sit the operational tools. Automation scripts call the platform’s own interfaces. Backup products store copies in formats tied to it. Monitoring dashboards and capacity reports read its data. Each can be replaced, but each replacement is a project with its own testing.

The commercial layer binds the others together. Enterprise agreements often priced the whole portfolio as one deal, with discounts tied to volume. A partial exit could raise the price of what remained, which made the economics of moving one workload class depend on what happened to all the others.

Different organizations, different exposure

Exposure looked different depending on the kind of institution. A large bank running its own data centers held the risk directly. A credit union or community bank whose core system is hosted by a service provider held much of it indirectly. Its exposure ran through the provider’s contract and the provider’s own renewal with the platform owner.

Broker-dealers and wealth managers had their own twist. Trading and recordkeeping systems often carry tight performance requirements and records obligations, which make migrations slower to test. A large health system running its electronic health record on its own infrastructure faced a vendor-certification question. An ambulatory network on a vendor-hosted record system faced mostly an indirect cost passed through by its supplier.

For a federal agency, a platform change can trigger a reassessment of the security authorization of every system that runs on it, the formal approval known as an authority to operate. Moving to a commercial cloud brings its own authorization requirements under FedRAMP. State and local agencies often rely on a state data center or shared service, so their option may sit with the state CIO rather than with them.

Buying the option: price the exit

An exit that has not been priced is not an option. It is a hope. The first step is to know what the organization actually owns and what leaving would cost.

Start with entitlements, the formal record of what software the organization is licensed to use and on what terms. Many institutions held a mix of perpetual licenses with annual support, enterprise agreements, and products bought through resellers or bundled with hardware, with support renewals scattered across the year. A perpetual license is the right to use a version of the software indefinitely, typically paired with a yearly fee for updates and help. A clean entitlement inventory lists each product, edition, quantity, support end date and the clusters and workloads it supports. That inventory alone often reveals unused licenses and add-ons renewed out of habit.

What the inventory should capture

The useful inventory records more than product names. It notes the license metric for each product and the physical facts that metric depends on. VMware had already changed its per-processor licensing in 2020, so that one license covered a processor with up to 32 cores. Any change of metric reprices an estate overnight, so the inventory should record cores per host as well as processors.

It should also record how each item was bought. Licenses bought directly, through a reseller or bundled with server hardware can carry different terms and different renewal dates. The inventory should note who holds the paperwork and who has access to the supplier’s licensing portal, since that knowledge often lives with one person.

Contract terms belong in it too. The questions are which agreements have price protection or caps on increases, how long each runs, what happens at a change of control, and whether the customer has any right to end early. Change-of-control clauses rarely give the customer a right to walk away. Knowing that early avoids false hope.

Federal agencies have had a head start on part of this. The MEGABYTE Act of 2016 required agencies to inventory their software licenses and manage them centrally. An agency that had done that work could move straight to the cost estimates.

Estimating the cost

Then estimate migration cost by workload class. A workload is simply an application or service and the computing it needs. A typical estate splits into three groups. Some workloads are already candidates for public cloud or a managed platform. Some can move to another hypervisor with moderate effort. Some are pinned in place by a software vendor that certifies its product only on one stack, or by disaster recovery designs built on a specific replication product.

For each group, a rough cost covers engineering effort, parallel running, retraining and the audit evidence that must be produced again: recovery tests, configuration baselines and access reviews. Parallel running means operating old and new systems side by side for a period to make sure nothing breaks, which temporarily doubles some costs.

Honest estimates include the costs teams prefer to leave out. Those include double licensing during parallel running, consultant fees for platforms the staff do not know, and hardware that is not certified for the alternative. They also include recovery testing on the new platform and the projects that will be delayed while engineers do the migration. Migrations of core infrastructure tend to run longer than planned, so a range with a contingency is more credible than a single figure.

The estimate should also cover the cost of staying. That means the current run rate plus a range for plausible new terms, including a move from perpetual licenses to subscriptions. The comparison that matters later is between those two ranges, not between a migration budget and today’s support bill.

The pinned group needs a conversation outside IT. Clinical system vendors, core banking providers and case management suppliers decide which platforms they support. Asking them in 2022 for their certification roadmap, and recording the answer, turned an unknown into a dated dependency.

The letter to each pinned vendor can be short. It asks which hypervisors and cloud platforms the vendor supports today, which it plans to support and when, and whether it offers a hosted version of its product. It also asks how it treats customers who run on a platform it has not certified. The reply goes into the risk file with its date. A vendor that will not answer in writing has, in effect, answered.

Consider a regional bank with a few hundred virtual machines. Its inventory shows that a third run internal tools and reporting that could move to a public cloud with modest effort. Another third, including the website and employee systems, could move to a different hypervisor. The last third, including the core banking system and its disaster recovery copy, is pinned because the core provider certifies only one platform. Suddenly the bank knows something it did not before: two thirds of its estate has a priced exit, and the other third depends on a single, identifiable conversation with one vendor.

Keeping the option alive

Options decay if nothing is spent on them. An exit plan written in 2022 and filed away would be stale by the time terms changed. Keeping it alive takes a few deliberate, modest investments.

The most valuable is a small production pilot on an alternative platform. Running a handful of non-critical workloads elsewhere builds skills, runbooks and monitoring, and it tests the assumptions in the cost estimate. Runbooks are the step-by-step operating instructions teams follow for routine tasks and emergencies; having them written and used is what turns a theoretical alternative into a working one. Without a pilot, the alternative exists on paper and the team’s estimate of migration effort is a guess.

The trade-off is real: a pilot costs licenses, staff time and some operational complexity. It is still far cheaper than discovering at renewal that no one on staff can run anything else.

Choosing the pilot

The pilot should be small but representative. Good candidates are production workloads that carry real backup, monitoring and recovery requirements but would not hurt customers, patients or residents if they failed for an afternoon. Internal reporting tools, a departmental application or a set of file servers often fit. Test and development systems are a weaker choice, because they do not expose the operational problems that production does.

The pilot should measure what the cost estimate assumed. Useful measures include staff hours to move each virtual machine, incidents in the first months, time to restore from backup, and the time a recovery test takes on the new platform. If those figures differ from the estimate, the estimate changes. That feedback is what keeps the option priced rather than imagined.

The choice of platform for the pilot should follow the organization’s strategy rather than fashion. An organization heading toward public cloud should pilot there. One that expects to stay largely on-premises should pilot an alternative hypervisor, such as a KVM-based platform or Microsoft’s Hyper-V. One building new applications in containers might test running virtual machines on its container platform.

Skills are the part of the option that decays fastest. A few engineers trained on the alternative, and given real work on it through the pilot, keep the option usable. Without them, the organization would have to hire or buy that knowledge at exactly the moment every other customer of the platform was trying to do the same.

Contracts and design rules

A second investment is contract hygiene. Aligning support renewal dates, where that can be done on acceptable terms, creates a single decision point instead of a dozen small ones. Some organizations chose to renew early on known terms for workloads they were sure would stay. That is a legitimate use of the window, as long as it is a choice based on the priced exit rather than a reflex.

Term length is the main trade-off in contract hygiene. A longer renewal locks in known prices, which protects against increases but shortens the option’s life. A shorter renewal keeps the option open at the risk of facing new terms sooner. Organizations with a priced exit could make that choice deliberately, workload class by workload class, rather than renewing everything on the same terms.

The third is architecture discipline for new work. Every new system built on hypervisor-specific features deepens the lock-in. Asking design reviews to justify platform-specific dependencies, and to prefer portable tooling for backup, automation and monitoring where the cost is similar, keeps the exit price from rising while the deal is pending.

Portability has a price as well. Platform-specific features often exist because they work better, and refusing them can mean weaker capability or more engineering effort. The design review’s job is to make that trade-off visible, not to forbid every proprietary feature. A reasonable rule is to accept platform-specific features when they deliver clear value and to record them as part of the exit cost when they do.

Backup is the most valuable place to insist on portability. A backup product that can restore virtual machines to more than one platform doubles as a migration tool and as evidence that recovery does not depend on one supplier.

Exercising the option

An option is exercised when the payoff exceeds the cost. For an infrastructure platform, the trigger is a concrete change in terms: a new price at renewal, a product retired, a support model altered. At that moment the organization compares the new cost of staying with the priced cost of leaving, workload class by workload class.

The answer is rarely all or nothing. A common outcome is a partial exercise. The organization moves the workloads that were already easy to move and renegotiates for the pinned ones, using the credible threat of the first to improve the terms of the second. Suppliers respond to evidence that a customer can leave. A pilot in production and a dated migration plan are that evidence. A slide that says the organization is evaluating alternatives is not.

Return to the regional bank. When its renewal quote arrives with new terms, it can show the supplier that one group of workloads is already running elsewhere in a pilot. It can also show a costed plan to move the rest of the movable estate within a set period. For the pinned core banking group, its negotiating position is now very different. A bank whose only answer is that it is “looking at options” has no comparable evidence.

Reading the trigger

When new terms arrive, the comparison should run over several years, not one. For each workload class, it sets the cost of staying under the new terms against the one-time cost of moving plus the run cost of the alternative. Organizations that agreed a decision rule in advance, such as a threshold at which a class moves, avoided relitigating the whole question under deadline pressure.

The trigger can also be a product change rather than a price. A product the organization relies on may be retired, bundled into a larger package it does not need, or supported only on new terms. Each of these changes the cost of staying in ways a price list alone does not show, and the inventory makes them quick to assess.

The cost of a partial exit

Running two platforms is not free. It means two sets of skills, two security configuration baselines, two patch cycles and two sets of audit evidence. For a period, that is a reasonable price for flexibility. Left indefinitely, it becomes a new form of complexity. A partial exit should come with a view on whether the split is a stable end state or a step toward consolidation.

A supplier’s improved offer is also a legitimate outcome. If evidence of a credible exit produces better terms for the pinned group, accepting them is exercising the option, not abandoning it. The value of the premium shows up in the renewal price as much as in workloads moved.

The public-sector calendar

Public agencies need one more element. Procurement vehicles, competition rules and fiscal-year budgets set their own timelines, often longer than the commercial ones. Starting the procurement groundwork for an alternative, such as market research and draft requirements, during the window kept the option exercisable on the agency’s calendar.

The budget calendar matters as much as the procurement one. A large mid-year increase in a platform’s cost may need a supplemental appropriation or cuts elsewhere, which takes months in a county or a state. An agency that had flagged the risk in its budget request had room that one learning of the increase at renewal did not.

Competition rules cut both ways. Staying with an incumbent supplier on new terms may itself need a justification under procurement rules, and a documented market analysis supports that justification. The work that keeps the option alive also produces the record that procurement officers and auditors expect.

Three phases and a one-page summary

Inside an organization, the work runs best as a short, cross-functional project with a clear owner, rather than an open-ended technology review.

The owner is usually the head of infrastructure or the chief information officer, but the team also needs four other groups. Procurement or vendor management holds the contracts and knows the renewal dates. Finance can turn rough engineering estimates into figures that compare cleanly with a renewal quote. Application owners, who run the core banking, clinical or case management systems, know which outside vendors pin those systems in place and can open the roadmap conversations. Risk and compliance staff know which audit evidence would need to be produced again after a move, and can say how a migration would be viewed by examiners.

A practical sequence runs in three phases. In the first few weeks, the team builds the entitlement inventory and maps each license to the systems it supports. This is mostly detective work through contracts, invoices, reseller records and the platform’s own management console, and it often takes longer than expected because purchases were made by different teams over many years.

In the next phase, the team sorts workloads into the easy, moderate and pinned groups, attaches a rough cost to each, and sends written questions to the vendors behind the pinned group. Precision is not the goal. A range that is roughly right is far more useful than a precise figure that arrives after the renewal.

In the third phase, the team selects a handful of low-risk workloads for the pilot and sets it up on an alternative platform. It runs the pilot in production long enough to learn how the backups, monitoring and recovery steps actually behave. At the same time, it agrees with procurement how renewal dates will be handled and briefs the design review board on the new expectations for portability.

The output is short: a one-page summary for the executive committee. It shows what the organization owns, what leaving would cost by group, what the pinned vendors have said, and what the pilot has shown so far. Updated each quarter until the renewal, that page is the option, written down.

The page should also show what the option costs to hold. A line for the premium, covering staff hours, pilot licenses and any consulting, lets the executive committee decide whether to keep paying for it. If the exposure is small, a lighter version may do. If it is large, the premium may deserve its own budget line.

For regulated organizations, the same material serves as evidence. Bank examiners reviewing third-party risk, auditors testing contingency plans and public-sector auditors reviewing procurement all ask versions of the same question. A dated inventory, cost ranges, vendor replies and pilot results answer it without new work.

Costs that reach past the data center

Supplier concentration sounds like a technical topic. Its consequences land in places every executive cares about.

Budget. A large, unplanned increase in the cost of a foundational platform has to be paid from somewhere, usually other projects. Without a priced exit, the organization has no way to judge whether the increase is worth paying.

Operational resilience. Regulators in banking and healthcare increasingly expect organizations to understand their dependence on critical third parties and to have credible plans if a supplier changes course. An exit plan is part of that story.

Negotiating power. The single biggest factor in a renewal negotiation is whether the customer can credibly walk away. Evidence, not intent, creates that credibility.

Sector concentration. When many institutions in one sector depend on the same platform, one owner’s decisions affect the sector as a whole. Financial regulators in several jurisdictions have increasingly looked at concentration across the whole system as well as within each firm. A single bank cannot solve that, but it can make sure its own exposure is known and its own exit is priced.

People. Teams that have only ever run one platform carry a concentration risk of their own. A pilot broadens skills and reduces dependence on a few specialists.

Customers, patients and the public. The applications on top of the platform are the ones people use: online banking, patient records, benefits portals. A rushed migration forced by a sudden price change is far riskier for those services than a planned one.

Security. When a platform becomes expensive, some organizations delay upgrades or let support lapse. Unsupported infrastructure does not receive security fixes. Hypervisors are attractive targets, because one compromised host exposes every virtual machine on it. In February 2023, a widespread ransomware campaign known as ESXiArgs hit unpatched VMware ESXi servers exposed to the internet. Cost pressure that leads to stale infrastructure is a security problem as well as a budget one.

Regulatory standing. Banking regulators expect institutions to manage critical third parties through their whole life cycle, including exit. Health systems must maintain contingency plans for systems that hold patient data under the HIPAA Security Rule. Public agencies answer to auditors and legislators for spending. In each case, the organization has to explain its choices, and a priced exit makes that explanation simpler.

What the prepared organizations did in 2022

A well-prepared organization in mid-2022 would have done a handful of things within a few months of the announcement. It assembled an entitlement inventory and found licenses it no longer needed. It grouped its workloads into easy, moderate and pinned, with rough costs for each. It wrote to its pinned application vendors, asked for their platform roadmaps and filed the dated replies. It stood up a small pilot on an alternative and ran real, if minor, workloads there. And it told its design reviewers to question any new dependency on platform-specific features.

Less prepared organizations tended to make the same errors:

• Waiting to see. Treating the long gap before closing as a reason to delay, rather than the cheapest time to prepare.
• Alarm without action. Holding meetings about the risk and producing no inventory, no cost estimate and no pilot.
• An exit on paper only. A migration plan that has never been tested, staffed by people who have never run the alternative.
• Ignoring the pinned workloads. Assuming the core application vendor will support whatever the organization chooses, without asking.
• Reflexive renewal. Renewing everything early out of anxiety, rather than renewing selectively based on the priced exit.
• Deepening the lock-in. Continuing to build new systems on platform-specific features while the supplier’s future is uncertain.

The same discipline applies beyond virtualization. Every regulated organization has a handful of suppliers whose products sit under nearly everything else: identity, productivity, core platforms and databases. Each deserves a standing, priced exit assessment, refreshed every year or two, so that the next ownership change starts from known numbers.

The strongest objection

The case against all this is real. The premium is not free. Staff time spent on inventories, estimates and pilots comes from other projects, and most supplier acquisitions do not produce changes as sharp as this one did. An organization that bought an option on every supplier after every deal would spend a great deal on options it never used.

A pilot can also create its own problems. A small second platform that never grows can become an orphan, maintained by a few people and understood by fewer. Some suppliers may treat a visible pilot as a sign of a lost customer and offer less, not more.

These objections argue for scaling the premium to the exposure, not for skipping it. The cheapest parts of the work, the inventory and the letters to application vendors, are worth doing for any supplier that sits under critical systems. The pilot is worth its cost where the platform is foundational and the terms are genuinely uncertain, as they were here.

The argument is weakest for small organizations whose infrastructure is already hosted by someone else. A credit union whose core provider runs everything has no hypervisor of its own to move. Its option lies in its provider’s contract and in the provider’s own plans, and the useful step is to ask the provider, in writing, what those plans are.

Option or hope: five questions

• Which three or four suppliers sit underneath most of our critical systems? What would happen if any of them changed owners, prices or products?
• If we had to leave our main infrastructure platform, which workloads could move easily, which with effort, and which are pinned? What is the rough cost of each group?
• Which application vendors pin us to a single platform, and what have they told us, in writing, about their plans?
• Are we running anything in production on an alternative platform today? If not, what would a small pilot cost?
• For public bodies: how long would procurement take if we needed an alternative, and have we started the groundwork?

Each question has a factual answer, and none requires technical depth to ask. Together they tell a leadership team whether it holds an option or merely a hope.

The questions are worth asking on a schedule rather than only after headlines. Natural triggers include an acquisition or private equity buyout of a critical supplier, a change of license metric, an end-of-support date for a major version, and the approach of a large renewal. Each starts a clock, and each is cheapest to prepare for at the start.

With hindsight

The deal closed on November 22, 2023, and the changes that followed were substantial. In December 2023, Broadcom ended the sale of perpetual licenses in favor of subscriptions. It consolidated a long product list into a few bundles led by VMware Cloud Foundation and reworked its partner and reseller programs. VMware said the move to subscriptions had been planned before the acquisition, which, if anything, shows the direction was visible to customers who looked.

A subscription means paying a recurring fee for the right to use the software, rather than owning a license outright. It turns a one-time purchase plus support into an ongoing cost that is reset at each renewal.

The portfolio also changed shape. Broadcom reorganized VMware into a small number of divisions and sold the end-user computing business, the virtual desktop and device management products, to KKR. Broadcom’s annual report put the cash consideration at about 3.5 billion dollars, and the business now operates as Omnissa. Customers of those products went through a second change of ownership within a year, and with it a second option window.

Many customers reported much higher costs at renewal. Some customers and industry groups took disputes over the new terms to courts and regulators. For organizations that had treated the eighteen-month window as a time to wait, the new terms arrived as a bill with few alternatives attached.

The market for alternatives moved as well. Hypervisor vendors, cloud providers and integrators courted VMware customers with migration tools and services, which lowered the cost of the easier moves. Organizations that had already sorted their workloads into groups could take advantage of those offers quickly. Those that had not had to do the sorting first, often against a renewal date.

Responses split along predictable lines. Some organizations accelerated moves to public cloud or other hypervisors, while many stayed and absorbed the increases because their exit had never been priced or tested. Staying was not necessarily the wrong choice. The problem was making it without knowing the alternative, which meant accepting whatever was offered.

The regulatory framing hardened over the same period, at least for banks. The U.S. federal banking agencies issued joint guidance on third-party risk management in June 2023 that covers contingency planning and termination. In the European Union, the Digital Operational Resilience Act has applied since January 2025 and requires financial entities to have exit strategies for technology services that support critical or important functions.

A priced exit for a foundational platform has therefore moved closer to an examination expectation than an optional discipline. Health systems and public agencies face no equivalent explicit rule. Their contingency planning obligations, and their budget processes, push in the same direction.

The argument has a limit worth stating. Nothing in a priced exit makes a pinned workload portable. For systems held in place by an application vendor’s certification, the option could improve terms but rarely offered a quick way out, because the vendor, not the customer, controlled that timeline. For those systems the option worked mainly as negotiating evidence, while the easier workload classes were the ones that could actually move.

By 2026 the episode is a standard case in vendor concentration planning. Customers with a pilot in production and a dated plan generally had more room to negotiate. Those that waited to see had one practical choice.

The same logic applies to every critical supplier. Ownership changes at critical suppliers are announced in public, usually long before anything changes in a contract. That gap is the cheapest moment an organization will ever have to learn what leaving would cost. Treating every such announcement as a prompt to price the exit, and to spend a little to keep that exit real, is an inexpensive habit with a demonstrated payoff.

It is also a habit boards can ask about directly. A simple standing question, “if this supplier changed tomorrow, what would leaving cost us, and how do we know?”, tells directors quickly whether management holds a real option or is relying on hope.