Vendor Relationships End. Audit Rights Often Don’t.

Audit rights don’t expire when a vendor relationship does. Most infrastructure teams don’t find that out until a contract clause outlives the migration project that was supposed to close the book on it.

That’s the architectural question sitting underneath a federal lawsuit that has nothing to do with server racks. Broadcom-owned VMware is suing Allstate Insurance Company, accusing it of obstructing a software licensing audit — after Allstate had already told the vendor it had removed VMware from its environment. Strip away the parties and the docket number, and what’s left is a sequencing problem every virtualization architecture team eventually runs into: the day you consider a migration finished and the day your obligations to the platform actually end are not the same day, and nothing in most exit planning tracks the second one — least of all the audit rights that were written to survive it.

Where This Fits: An Existing Framework, Extended, Not Replaced

Framework #143 — Dependency Visibility Boundary — asks whether you actually understand what you depend on before you attempt to leave a platform. It’s built on an implicit lifecycle: adoption, expansion, dependency, exit. The Allstate case exposes a stage that lifecycle never named: verification.

Adoption → Expansion → Dependency → Exit → Verification.

The framework wasn’t wrong. It was incomplete. #143 governs whether you can see what you’re dependent on well enough to leave safely. This post covers what happens after you’ve left — whether you can prove you left, to a vendor whose contract may not agree the relationship is over on your schedule. Same doctrine family, next stage in the sequence, not a new boundary. If Framework #143 is “you cannot safely leave what you cannot fully inventory,” this is its downstream corollary: you cannot safely exit what you cannot fully prove you exited.

The Sequence, Not the Motive

The public record here supports a sequence, not a motive, and it’s worth being precise about the difference. In September 2025, Allstate told Broadcom it had removed VMware from all devices. In December 2025, VMware filed suit in the Northern District of California, alleging Allstate obstructed a contractual audit and failed to maintain required usage records. Allstate’s own June 2026 filing counters that the audit intensified once its exit became visible.

Neither side’s account is provable from what’s public. Broadcom can argue the audit was routine entitlement verification. Allstate can argue the timing speaks for itself. This piece isn’t going to adjudicate that, and it doesn’t need to — because the architectural lesson doesn’t depend on why the audit happened. It only depends on three things that aren’t in dispute: audit rights existed, they were written to survive termination of active use, and the dispute arrived after the exit was already underway. That’s a much smaller evidentiary bar to clear than “the vendor retaliated,” and it’s the only bar this post is going to lean on.

The Audit Rights Clause That Outlives the Migration

Here’s the mechanism. VMware’s licensing framework with Allstate — a Master End User License Agreement dating to 2008, later Enterprise License Agreements — includes standard audit-rights language: the customer must maintain accurate usage records for a fixed period after support and subscription services expire, and the vendor retains the right to inspect records and devices to verify compliance during that window. In this case, that window runs two years past the point services ended — not two years past whenever the customer declares the platform gone.

That’s the sentence the whole architectural argument rests on: the migration ended when the infrastructure moved. The audit obligation ended when the contract said it ended. Those are two different events, set by two different clocks, and most infrastructure teams have only ever been responsible for the first one.

This isn’t a VMware-specific quirk. Audit-rights survival clauses, indemnification tails, SLA-credit windows, and data-retention obligations that outlive an active contract are standard instruments across enterprise software licensing generally. VMware’s just the one currently in federal court.

Migration Completion Is Not Exit Completion

Most VMware coverage — including two posts already living on this site — focuses on migration execution or the audit-exposure risk of an active dispute. Almost nothing addresses exit evidence: what it actually takes to prove, on the vendor’s terms, that a platform is gone.

The gap shows up cleanly when you put the two views side by side:

Infrastructure Team View	Contractual View
Workloads moved	Records retained
Platform removed	Audit rights active
Systems operational	Entitlements still reviewable
Migration complete	Exit still provable

The left column is what gets celebrated at the project retrospective. The right column is what a vendor’s legal team is still tracking eighteen months later. Both are accurate simultaneously. That’s the whole problem — nobody on the infrastructure side owns the right column, and nobody on the legal side is in the room when the left column gets declared done.

This is a different failure than the one covered in Audit Risk: Why VMware Licensing Disputes Are the New Exposure, which argues that any active dispute or in-progress decommission exposes an inventory gap organizations already have. That post is about audit exposure during a live dispute. This one is about audit rights that stay enforceable after the dispute — and the platform — should already be gone. It’s also a different pattern than Broadcom VMware Lawsuit: Why Enterprises Are Suing to Buy Migration Time tracks: that post’s cases run customer-against-vendor, litigating for continued access. Allstate runs the other direction — vendor against customer, after the customer already left.

Two Clocks, Two Owners

This is the reusable version of the lesson, stripped of Broadcom and VMware entirely: exiting a platform and proving you exited a platform are separate architectural activities, and they’re usually owned by different teams running different systems of record with no shared trigger between them.

It isn’t a VMware problem. The same clock mismatch shows up in SaaS offboarding, cloud migrations, database platform exits, security tooling replacement, backup platform replacement, identity provider migration, and managed service termination — anywhere a vendor relationship carries contractual obligations, audit rights, or record-retention duties that outlive the operational relationship. Infrastructure teams close the project when the technical work is done. Legal and procurement systems close the obligation when the contract says it’s closed. Those dates coincide often enough that the gap goes unnoticed — until a vendor with an aggressive audit posture and a contract you didn’t reread makes the gap very expensive, very fast.

The pattern generalizes past audit rights specifically, too. Your Cloud Isn’t Compromised. Your Vendor Is. Now What? documents Framework #169, Authority Persistence Boundary — the broader principle that authority can remain valid after the trust relationship that justified it has failed. Audit rights surviving a terminated license is one instance of that pattern. It won’t be the last one an architect runs into.

What Proof of Exit Actually Requires

If migration completion and exit completion are genuinely separate activities, exit needs its own evidence trail — not folded into the migration runbook and archived when the project closes.

That means: decommission records with timestamps, not just a ticket marked done. License de-provisioning logs from the vendor’s own management plane, not just your CMDB reflecting removal. Infrastructure-as-code diffs showing the platform’s footprint actually went to zero, not just that new workloads stopped landing on it. And retention of all of it for at least as long as the contract’s own audit rights and record-retention clause runs — which means someone has to know what that window actually is before the migration closes, not discover it eighteen months later in a legal filing.

That last part is the real gap. Most exit checklists end at “platform removed.” None of them end at “and here’s the evidence we could produce if asked, for as long as we’re contractually obligated to be able to produce it.” The contract doesn’t care that the project closed. It cares whether the audit rights it granted the vendor can still be exercised, and against what — which means the evidence has to outlive the project team that generated it, not just the platform they removed.

There’s a governance implication buried in that, too: whoever owns vendor contracts needs a standing line item — not a one-time checklist entry — for every audit-rights and record-retention clause still running against a decommissioned platform. That’s a small, boring, unglamorous artifact. It’s also the only thing standing between “we’re confident we exited cleanly” and “we’re currently discovering, under legal deadline, that we can’t prove it.”

Additional Resources