Mapping shared and group wide software agreements is the part of diligence that decides whether a target can stand on its own software estate after close. In a carve out or a deal where the target sits inside a larger group, much of the software it depends on is not bought by the target at all. It is bought by the parent under a group wide agreement, and the target rides on entitlements it does not own. When the deal completes, those entitlements may not come with it. The buyer that has not mapped the shared agreements inherits a business that loses access to core software on day one, or a standalone cost that nobody priced.
This guide sets out how to map shared and group wide software agreements so the buyer knows exactly what transfers, what stays, and what has to be replaced. It is part of the wider software due diligence method and is essential reading alongside carve out and transitional service agreement planning. For the cross border dimension, pair it with software due diligence for cross border deals.
Why mapping shared and group wide software agreements matters
A group wide agreement is signed once and used everywhere. The parent negotiates an enterprise deal with Microsoft, Oracle, SAP, or another major publisher, and every entity in the group draws on it, including the one being sold. The entitlement, the volume discount, and the support contract all sit with the parent. When the target leaves the group, three things can happen to each shared agreement. It can transfer with the target, it can stay with the parent and leave the target without cover, or it can be split, which usually means renegotiating both halves at worse rates because the volume that earned the discount has been broken.
The buyer needs to know which of those three outcomes applies to each agreement before signing, because each has a different cost. An agreement that stays with the parent means the target must buy its own license at standalone volume, almost always at a higher unit price than the group rate. That standalone cost is real, it is recurring, and it is invisible unless someone maps the shared agreements deliberately.
Build the map: from parent agreement to target dependency
The mapping work runs in two directions. First, list every group wide agreement the parent holds and identify which products the target actually uses under each one. Second, list every piece of software the target depends on and trace it back to the agreement that entitles it. Where the two lists meet, you have a shared dependency. Where the target uses something with no agreement traced to it, you have either a hidden direct contract or an unlicensed deployment, and both need resolving before close. The way a deal type changes which agreements transfer is covered in software due diligence for stock versus asset purchases.
The data comes from the same feeds that drive any estate reconstruction, applied across the group boundary. Request the parent contract register and the target deployment data, then reconcile them. The reconciliation exposes the agreements where the target is a heavy user of a parent entitlement, which are exactly the ones that will be most expensive to replace at standalone volume.
Key takeaways
- Much of a target software estate inside a group is bought by the parent under group wide agreements the target does not own.
- At separation each shared agreement either transfers, stays with the parent, or is split and renegotiated at a worse rate. Each outcome has a different cost.
- An agreement that stays with the parent forces the target to repurchase at standalone volume, almost always above the group rate. That cost is recurring and easy to miss.
- Shared SaaS tenants cannot be divided cleanly and usually need a transitional service agreement followed by a full migration to a new subscription.
Price the standalone estate the buyer will run
Once the map is built, the buyer can price the standalone estate. For every agreement that stays with the parent, model the cost of buying the same entitlement at the target own volume. For every split agreement, model the lost discount on the target half. For every shared SaaS tenant, model the transitional service agreement cost and the migration to a new subscription. The sum is the standalone software run rate, and it is frequently materially higher than the allocated cost the target carried inside the group. That difference belongs in the deal model as a permanent increase in operating cost, not a one off.
Change of control terms matter here too. Even the agreements that transfer cleanly can carry clauses that let a publisher reprice on the change of ownership. As of June 2026, publishers including SAP and Oracle have pursued inherited and disputed licensing into nine figures, with SAP reported to have pursued AB InBev for around 600 million dollars over inherited and indirect usage. Confirm current figures with primary sources. The lesson for shared agreements is that the parent rate is not the buyer rate, and assuming it is can understate the run rate by a wide margin.
Recommendations for buyers
- Map every group wide agreement against actual target usage, in both directions, before signing rather than after.
- For each shared agreement, decide whether it transfers, stays, or splits, and price the standalone cost of the outcome.
- Use transitional service agreements only as a bridge for shared tenants, with a dated plan to migrate to a standalone subscription.
- Carry the standalone software run rate into the deal model as a recurring cost, not a one off, and hand the migration plan to integration.
Confirm the deployment behind each shared entitlement
A map that lists agreements without testing usage is only half the work. For every shared entitlement, confirm how much of it the target actually consumes, because that figure decides the standalone cost. A target that uses a small slice of a large parent agreement can repurchase cheaply on its own, while a target that is the heaviest user in the group faces the full standalone price with none of the group leverage. Pull the deployment and usage data per shared product and rank the agreements by how much the target draws on each one. The agreements at the top of that ranking are where the separation cost concentrates, and they are the ones to settle first in negotiation.
This step also exposes the reverse risk: entitlements the parent holds that the target does not really use, which the buyer should not pay to replace at all. Stripping those out of the standalone model keeps the run rate honest. The same usage evidence then carries into reconciliation after close, where the combined entity decides what to keep, consolidate, or drop.
Hand the map to carve out and integration teams
The shared agreement map is not a diligence artefact that gets filed. It is the working plan for separation. The carve out team uses it to negotiate transitional service agreements that cover the shared tools for exactly as long as needed and no longer. The integration team uses it to sequence the migrations and the standalone purchases. Built by an independent, buyer side advisor with no affiliation to any publisher or reseller, the map gives the buyer a defensible standalone cost before signing and a ready plan the moment the deal closes, so the target never loses access to the software it runs on.