Executive summary

In a merger, acquisition or divestiture, software licenses do not move with the assets unless the contract and the vendor say they do, and that single fact decides whether the deal carries a hidden eight-figure liability. Most enterprise agreements block transfer without written consent, and the consent request is the exact moment a vendor reprices the relationship. This guide works through pre-deal diligence, the transfer and anti-assignment clauses that govern every transaction, Transition Service Agreement scope, divestiture carve-out math, the vendor-specific mechanics for Oracle, Microsoft, SAP and VMware, and the audit risk that a change of ownership reliably triggers.

Our advisors work the buyer side and the sell side of these transactions only. Across more than 500 enterprise engagements, the buyers and sellers we advise have negotiated over $2.4 billion in software and cloud contracts at an average saving near 38 percent, and our audit defence work averages a 72 percent reduction against the initial claim. The figures below frame the licensing exposure that sits inside a deal and the public contract mechanics that decide who pays for it.

1. Why mergers and acquisitions break software licensing

A transaction changes three things at once that every software contract cares about: who owns the entity, how many people use the software, and where it runs. Each of those is a licensing event on its own. Together they create the single largest source of unplanned software cost inside a deal, and it almost never appears in the financial model until a vendor sends an invoice.

The reason is structural. Software is licensed to a named legal entity for a defined scope of use. When ownership of that entity changes, or when a business unit leaves it, the right to use the software does not automatically follow the people who were using it yesterday. The contract decides, and most enterprise contracts were written to give the vendor a say in any change of control or assignment.

The three deal structures and what each one does to licenses

Deal structure drives the licensing outcome more than any other factor. A stock or share purchase, where the buyer acquires the legal entity intact, often preserves agreements because the contracting party has not changed, though a change of control clause can still grant the vendor rights. An asset purchase, where the buyer takes assets out of the selling entity, almost always requires fresh consent because the licenses are assets that must be assigned. A merger that dissolves one entity into another sits in between and depends on the assignment and successor language in each agreement.

The practical lesson is that the same target carries a different licensing cost depending on how the deal is papered. A buyer who models that cost during structuring can sometimes choose a structure that preserves more agreements, or can price the consent risk into the offer. A buyer who ignores it inherits whatever the vendor decides to charge.

2. Pre-deal diligence: surfacing the license liability before signing

The cheapest time to find a software liability is before the purchase agreement is signed, because at that point it is a deal term that can be priced, indemnified, or walked away from. After close it is a cost the buyer owns alone. Licensing diligence is the discipline of turning an unknown into a number while the number can still change hands.

Most data rooms describe software badly. They list spend, not entitlement, and spend tells you what was paid, not what is owed. A target running ten thousand seats of an application against six thousand purchased licenses looks healthy on the invoice and carries a four thousand seat liability that surfaces the moment a vendor counts. Diligence has to reconcile deployment against entitlement, contract by contract, for every material vendor.

What a license diligence review actually checks

• The contracting entity on each agreement, and whether the deal structure preserves or breaks it.
• Change of control, assignment, and anti-assignment language in every material contract.
• Deployment counts against purchased entitlement for each metric, not against spend.
• Any active or recent audit, true-up, or vendor compliance review.
• ULAs, enterprise agreements, and any time-bound commitment that a transaction can void.
• Co-termination and renewal dates that fall inside the integration window.

The output of a good diligence review is a single schedule of license risk with a dollar range against each line and a named owner for the fix. That schedule feeds two things: the price the buyer is willing to pay, and the representations and warranties the seller is asked to stand behind. Both are far harder to obtain after the ink is dry.

3. Transfer and anti-assignment clauses: the trap at the centre of every deal

The anti-assignment clause is the single most important sentence in a software contract during a transaction. It typically states that the agreement, and the licenses it grants, may not be assigned or transferred without the vendor's prior written consent, and that any attempt to do so is void. That one sentence converts a transfer the buyer assumed was automatic into a negotiation the vendor controls.

Vendors do not grant consent for free. The consent request is treated as a commercial event, and the standard vendor response is to use it to reset the relationship: re-meter the deployment, remove legacy discounts, require an edition upgrade, or attach a fresh multi-year commitment. The buyer who needs the transfer to close on a fixed date has handed the vendor timing power at the worst possible moment, which is precisely why the terms are settled early.

Reading the clause before you need it

Not all assignment clauses are equal, and the differences decide the cost. Some permit assignment to an affiliate or a successor without consent. Some carve out a change of control as a non-assignment event, which protects a stock deal. Some require consent that, by the contract's own words, cannot be unreasonably withheld, which gives the buyer a lever the vendor would rather you forget. Reading the exact language, contract by contract, is the difference between a known cost and a surprise.

The action is the same in every case. Inventory the assignment and change of control language across the material agreements during diligence, sort the contracts into those that transfer cleanly and those that need consent, and price the consent contracts as a line item. Then approach the vendors that matter on your timeline, with your entitlement reconciled, rather than waiting for the consent request to become urgent.

4. Transition Service Agreements and the third-party use problem

When a business unit is carved out and sold, the buyer rarely has the systems to run it on day one. The Transition Service Agreement, or TSA, bridges that gap by letting the seller keep operating shared systems for the buyer for a defined period, often six to twenty four months. The TSA is essential to most carve-outs, and it carries a licensing exposure that both sides routinely miss.

The exposure is third-party use. Almost every enterprise software agreement restricts use of the software to the licensed entity and its affiliates. A TSA, by definition, has the seller running software to benefit a company that is no longer an affiliate, which is third-party use that most agreements do not permit. Without a written third-party use right or a hosting provision, the seller is using its licenses for an unlicensed beneficiary, and the buyer is receiving a service built on an entitlement it does not hold.

Closing the TSA licensing gap

• Identify every system inside the TSA scope and the license that underpins it.
• Check each underlying agreement for a third-party use, hosting, or service provider right.
• Where the right is absent, secure it from the vendor before the TSA goes live, not after.
• Define a hard exit date and a migration plan, because a TSA that overruns becomes a permanent unlicensed deployment.
• Allocate the cost of any required vendor consent between buyer and seller in the purchase agreement.

The TSA period is also the buyer's window to stand up its own agreements. A buyer that treats the TSA as breathing room rather than a countdown often reaches the exit date without standalone licenses in place, which forces a rushed purchase at the vendor's list price. The disciplined approach runs the new-agreement negotiation in parallel with the TSA, so the exit is a planned cutover and not an emergency.

5. Divestiture: splitting one entitlement base into two

A divestiture is an acquisition run in reverse, and it is harder, because one entitlement base has to become two. The parent holds agreements sized for the whole company. The divested unit was using a share of those licenses, but it almost never has a standalone right to them once it leaves. Someone has to decide how the entitlement splits, and the contracts rarely divide on their own.

The three options for the divested unit are assignment, repurchase, or a TSA bridge. A formal partial assignment moves a defined quantity of licenses to the new entity with vendor consent. A repurchase has the divested unit buying fresh licenses, which is the vendor's preferred and most expensive outcome. A TSA bridge keeps the unit running under the parent's agreements temporarily while it builds its own. Most divestitures use a combination, and the mix is a negotiation with the vendor as much as with the counterparty.

The carve-out entitlement model

The seller protects value by knowing, before the data room opens, exactly how much entitlement the divested unit consumes and how much the remaining business needs. That split is modeled, not guessed. A parent that hands over too much entitlement strands paid-for licenses with a unit it no longer owns. A parent that hands over too little leaves the buyer of the unit exposed and invites a price chip late in the deal. The illustrative index below shows how a 100 unit parent entitlement might be claimed by the retained business under three separation approaches. It is an illustrative index, not a market benchmark.

The point the chart makes is commercial. A divestiture is a rare moment when a vendor agreement is open and both quantity and metric are genuinely in play. A seller that has modeled its true post-divestiture need can take the chance to right-size the retained agreement downward, rather than carrying entitlement for a business that has left. That saving is real money that a default separation leaves on the table.

6. Vendor-by-vendor mechanics: Oracle, Microsoft, SAP and VMware

Every major vendor handles a transaction differently, and the differences are large enough to change the deal model. The four below cover the agreements most likely to carry transaction risk in an enterprise portfolio. The mechanics are public, set out in each vendor's standard terms, and knowing them ahead of the consent conversation is what keeps the cost predictable.

Oracle

Oracle agreements are assigned to a named entity and are not transferable without Oracle's written consent. A ULA is the sharpest issue, because the unlimited deployment right usually does not extend to an acquired entity, and a divestiture can force an early certification that locks the count before the deployment has settled. An acquired company brought under an existing Oracle estate also brings its own deployment, which Oracle expects to see licensed. Settle the ULA position and the certification timing as part of the deal, because Oracle will.

Microsoft

Microsoft Enterprise Agreements are sized to an organisation and its qualified affiliates, and a change of ownership tests that definition. An acquired entity may need to be added under the buyer's EA at the next true-up, and a divested unit usually loses its place under the parent's EA and needs its own agreement or a transfer. Microsoft 365, Windows, and the server estate each carry their own transfer mechanics, and a transaction is the moment to confirm that the affiliate definition still covers the post-deal structure.

SAP

SAP licenses are named-user and engine based, and SAP agreements restrict use to the licensed company group. A merger that brings new users onto an SAP system, or a divestiture that carries SAP usage out of the group, both change the licensed population, and SAP's indirect or digital access rules can attach value to the integration data flows that a deal creates. The SAP position is rarely simple, and the named-user reconciliation should run before any system is merged or split.

VMware

VMware licensing, now sold on a per-core subscription basis, sits underneath much of the infrastructure that a transaction moves, and the underlying host count is what is licensed. Moving virtual machines from a divested unit onto retained hosts, or absorbing an acquired estate, changes the core count that must be licensed. The per-core subscription model makes the host inventory the controlling number, so the consolidated core count after integration is the figure to model before the migration, not after.

7. The audit risk a change of ownership reliably triggers

A merger, acquisition or divestiture is one of the most reliable audit triggers in the software industry. The reasons are not mysterious. An ownership change is a public event that signals deployment, headcount, and entitlement are all moving, which is exactly the condition under which a vendor expects to find a gap. The consent request, the support transfer, and the new corporate name on the account all flag the relationship for review.

The timing is deliberate. Vendors send audit and compliance letters into the integration window because the buyer is busy, the entitlement record is rarely reconciled, and the pressure to keep systems running gives the buyer a reason to settle quickly. The defence is the same discipline that protects any audit, brought forward to before the deal closes rather than improvised after the letter arrives.

Building the pre-transaction audit defence

• Reconcile deployment against entitlement for every material vendor during diligence, not after close.
• Retain the entitlement evidence and the measurement methodology under your own control.
• Allocate audit and true-up liability between buyer and seller in the purchase agreement, with an indemnity for pre-close exposure.
• Route every vendor contact through a single owner during the integration window.
• Treat any finding as a claim to be tested against your own reconciled count, not an invoice to be paid.

The purchase agreement is the strongest defence available, because it can place pre-close compliance risk on the seller through representations, warranties, and a specific indemnity. A buyer that secures those terms turns a potential post-close surprise into the seller's problem. A buyer that does not inherits every gap the target was carrying, discovered at the vendor's pace. Our audit defence work averages a 72 percent reduction against the initial claim, and the reduction is largest when the entitlement position was reconciled before, not after, the ownership changed.

8. The integration and separation calendar

Transaction licensing rewards a calendar, not a scramble. The work that protects value happens on a sequence that starts in diligence and runs through the TSA exit, and each step depends on the one before it. A buyer or seller that maps the sequence early turns a series of vendor emergencies into a managed cutover.

The term sheet below collects the clauses to verify before any transaction closes. Each line is a place where a default outcome favours the vendor and a prepared position favours the buyer or seller. Verifying them in diligence, while the price is still open, is what keeps the licensing cost inside the deal model instead of arriving as a surprise after close.

Our recommendation: reconcile entitlement against deployment for every material vendor during diligence, read the assignment and change of control language contract by contract before signing, secure third-party use rights before any TSA goes live, model the divestiture split on actual usage and treat it as a renegotiation, and push pre-close compliance risk onto the seller in the purchase agreement. A transaction is a rare moment when vendor agreements are open and quantity and metric are both in play, so treat licensing as a deal term that is priced and negotiated, not an administrative chore handled after close.

Sources: Oracle, Microsoft, SAP and VMware standard agreement and transfer terms, as published and available at the time of review. Outcome ranges and the separation index are Atonement Licensing advisory figures, indicative and deal-specific, not a quote.

Related reading: Software Audit Defense hub, Software Licensing Advisory, Enterprise Software Contract Clauses Playbook, and Oracle Licensing Playbook.