Support costs in M&A surface fast because both sides carry support at roughly 22 percent a year and a merger is a known Oracle audit trigger, so duplicated bases and transfer limits become a bill unless they are reconciled early.
Why do support costs spike in M&A?
Support costs spike in a merger or acquisition because two organisations arrive with two full support bases, each running at roughly 22 percent of net license fees a year with annual escalation. Where both ran the same Oracle products, the combined entity pays for the same capability twice until the bases are reconciled. The matching service levels rule then makes it hard to trim one base without restructuring, so the duplication does not resolve itself and quietly compounds every renewal.
The hidden cost is the gap between deal day and reconciliation. Until the support bases are mapped against actual deployment in the combined entity, nobody can see which support is genuinely needed and which is paying for shelfware on both sides of the deal.
Why is a merger an audit trigger?
A merger is an audit trigger because a change of control can change what the licenses are entitled to cover, and Oracle reviews whether the new combined entity stays within its agreements. Mergers and acquisitions sit on the standard list of triggers alongside virtualization, Java downloads without subscription, declining support spend, and cloud migrations. The deal itself signals that usage and entitlement may no longer line up, which is exactly what an audit exists to test.
This matters for support because an audit and a support reconciliation pull in opposite directions if run carelessly. Cutting support fast right after a deal can read as the declining support spend trigger, so the timing of any reduction has to account for the heightened audit risk a merger already carries.
Where the support bill hides in a deal
| Hidden cost | Why it appears | Buyer response |
|---|---|---|
| Duplicated support | Both sides run the same products | Reconcile bases against real use |
| Transfer limits | Change of control language in the contract | Read assignment terms before combining |
| Audit exposure | The deal is a known trigger | Build the position before Oracle asks |
Can the licenses transfer with the deal?
Whether the licenses transfer with the deal is contract dependent and turns on the assignment and change of control language in the Oracle Master Agreement. Some structures move licenses cleanly, others restrict transfer or require Oracle consent, and an asset deal can be treated very differently from a share deal. The policy document is not the contract, so the signed agreements govern, and they must be read before either side assumes its licenses simply carry across.
The buyer move is to read the transfer terms during diligence, not after close. A transfer restriction discovered late can turn an assumed asset into an unexpected repurchase, so it belongs in the deal model rather than in a surprise at the first post merger renewal.
What is the buyer move?
The buyer move is to map both support bases against actual deployment, read the transfer and change of control terms before combining anything, and build the audit position in advance because the deal is already a trigger. Support at roughly 22 percent a year with escalation makes every month of duplication expensive, so the reconciliation pays for itself quickly when it is done in the right order. Any reduction should be documented and timed so it does not read as the declining support spend trigger on top of the merger.
We position as an independent buyer side advisory with deep Oracle licensing expertise. In M&A that expertise is about sequencing the reconciliation and the audit position together, because a merger combines two estates and two sets of risk at once.
Where to go next
This piece links up to the Oracle Negotiation Guide. Keep reading across the cluster:
Deal on the table? Get a quote and we will reconcile the Oracle position before close.