Licence transferability, contractual pitfalls, Oracle's typical response, real-world cases, and best practices from pre-deal diligence through post-deal integration. Strategic advisory for SAM managers, CIOs, and Oracle licensing professionals navigating M&A.
Part of the Oracle Licensing Knowledge Hub. See also: Oracle Licensing M&A — Audit Risk · Oracle Licensing in M&A — Compliance & Cost Efficiency · Oracle ULA & M&A.
Oracle's standard contracts include clauses that strictly regulate who can use the software. In Oracle licence agreements (such as the Oracle Master Agreement or Ordering Documents), licences are generally non-transferable without Oracle's consent. Unless certain conditions are met, you cannot assign or hand off Oracle licences to another company in an acquisition or divestiture.
Oracle defines the contract's licensed customer as your company and its majority-owned (>50% ownership) subsidiaries. A new entity joining via acquisition is not automatically covered. A departing entity loses rights once no longer majority-owned.
Oracle contracts commonly prohibit transferring licences to another entity without prior written approval. Some allow assignment in the event of a full merger, but you must notify Oracle formally. Partial transfers (carving out licences to a spun-off company) are rarely permitted.
Oracle does not automatically "novate" (transfer) licences to a new owner. Standard terms mandate the divested entity can continue using Oracle programmes for only a short transition period (often 90 days), after which it must purchase its own licences.
An acquired entity's users are not entitled to use your Oracle licences until Oracle approves and your agreements are updated. The acquired company should continue using its own pre-existing licences (if any) until consolidation is addressed.
Geographic & Usage Restrictions: Some Oracle licences are tied to specific regions or use cases. If a merger extends operations globally, those licences might not cover new geographies. Similarly, licences based on metrics like employee count or revenue will change after a merger, potentially requiring licence expansion.
Example: Company A acquires Company B, and both run Oracle Database. Unless Company B is added to Company A's Oracle agreement, Company B's employees and servers are not legally licensed to use Company A's Oracle software. In a divestiture, if Company A spins off Division X, Division X might be allowed a brief period (e.g., 90 days) to keep using Oracle under Company A's agreement, but after that it must stop and acquire its own licences.
Oracle contracts contain several restrictions that can trip up companies during M&A. Failing to spot these in advance can lead to expensive consequences.
Almost all Oracle licence agreements explicitly state that licences are non-transferable. You cannot transfer the licence to another legal entity or assign the contract without Oracle's approval. If an unapproved transfer occurs, it is considered a contract breach.
Pitfall: Assuming a merger is "internal" and doesn't count as a transfer. Oracle often does treat it as a transfer if the entities weren't originally included in the contract.
Because of non-transferability, a company that wants to use Oracle software post-merger may effectively have to repurchase licences for the new usage. Oracle is within its rights to demand that any usage by an entity not covered under the original agreement be licensed anew, potentially at list price plus back support.
Pitfall: A divested unit that still needs Oracle Database must budget to buy its own licences at current prices, possibly at worse discount rates. Oracle's contracts don't obligate it to honour a new entity's original pricing.
Some Oracle agreements contain a "change of control" clause that might allow transfer if specific conditions are met, for instance, in the event of a full merger of the licensee. However, the contract typically requires notifying Oracle and sometimes Oracle's consent. A common restriction is that the new entity cannot be an Oracle competitor.
Pitfall: Companies sometimes overlook the need to formally notify Oracle of a change of control within the timeframe specified in the contract. Always check for assignment clauses and follow their requirements strictly.
If merging entities have different Oracle contracts, their terms might conflict. One company's contract might have a more lenient clause on subsidiaries, while the other's is stricter. They might have different metrics (one by Processor, the other by Named User Plus). These inconsistencies create grey areas post-merger.
Pitfall: Not reconciling differences can lead to unintentional over-deployment. If Company A's contract allowed global affiliate usage but Company B's did not, assuming B's licences work similarly puts you in breach.
A common misunderstanding: if you buy a company, you automatically "inherit" their licences to use as you please. In reality, the acquired company's licences remain restricted to that entity's use. The parent is not automatically an authorised user just by owning the company.
Pitfall: Companies think they have more licences available than they legally do. Unless Oracle consents, you cannot deploy software licensed to Company B for Company A's broader operations.
Oracle's support fees (~22% of licence cost annually) follow the licences. The new company might have to start a new support contract at higher rates if licences aren't transferable. If you combine two support contracts, Oracle might reprice support to align with current pricing or remove grandfathered discounts.
Pitfall: In a divestiture, the parent might want to drop unused licences to save support costs, but Oracle's policies may not allow dropping support easily, requiring continued payment on all licences still in use.
If your company operates under an Oracle ULA, special conditions apply. A ULA usually has strict rules about acquisitions and divestitures: small acquisitions may be allowed to join the ULA, but larger ones might not. Any divested entity typically loses unlimited usage rights after a short grace period.
Pitfall: If not handled, a ULA can instantly become a compliance headache if a new entity isn't included. Acquisitions above a certain threshold (often 10% of your revenue or workforce) may require renegotiation or be excluded entirely.
A large enterprise learned during post-merger integration that the acquired company's licences could not be transferred. The combined IT environment needed Oracle Database and Middleware licences for 20 additional processors previously licensed under the acquired firm's contracts. Oracle would not "move" those licences over.
Result: The acquirer had to purchase 20 new processor licences, roughly $950,000 in licence fees plus ~$209,000 annually in support. This unbudgeted spend could have been anticipated and mitigated with early contract negotiations.
Oracle often takes action when a merger or divestiture is announced or completed. It is invested in these events because they often lead to upsell opportunities or reveal compliance gaps. Oracle's overall stance can be summarised as "trust but verify, and monetise."
M&A activity is one of the top triggers for an Oracle licence audit. Oracle's LMS/GLAS team monitors news of acquisitions and corporate changes, often initiating a "licence review" shortly after a major acquisition is public. Audits tend to be particularly rigorous after mergers.
Oracle's response covers all products: databases, middleware (WebLogic), enterprise applications (E-Business Suite, PeopleSoft, Hyperion), Java, and cloud services. You might focus on database licences, but Oracle will simultaneously check every product line.
Oracle auditors will pay close attention to customer definition clauses. If the acquired company wasn't listed as an authorised user, any use of the acquirer's licences by its resources will be flagged as non-compliant "unlicensed deployments."
Oracle's approach to a merger announcement is often to send in the sales team with offers for a ULA or other enterprise deals to "simplify" licensing. These are being offered because Oracle sees an opportunity to lock in a large sale. Evaluate carefully.
Oracle will remind the parent company of the contractual timeline (e.g., 90-day grace period). They may engage directly with newly standalone companies to convert them into direct customers, often at less favourable terms than the original.
If you request Oracle's consent to transfer licences, they'll evaluate how they can benefit. They might consent if you bring support up to current pricing or buy expansion. Or they may flatly refuse simply to force a purchase. Always get permissions in writing.
Critical: Do not rely on verbal assurances from Oracle sales representatives. When push comes to shove, only the written contract terms count. Get a formal "Consent Letter" or amendment from Oracle's contracts/legal department for any licence transfer or continued use permissions.
Many companies have learned the hard way that Oracle licensing can become a flashpoint during M&A. Here are notable examples and scenarios.
Following Mars's acquisition of Wrigley, Oracle initiated a licence audit that escalated into a legal dispute. Oracle's audit demands were extensive. Court documents revealed Mars had to disclose hundreds of thousands of documents to Oracle's auditors. Oracle allegedly threatened to terminate Mars's licences if compliance issues weren't resolved.
Mars preemptively sued for declaratory judgment to constrain Oracle's audit practices. The dispute was eventually settled out of court.
Impact: Even a large, sophisticated customer like Mars had to expend significant legal and operational resources to deal with Oracle's licensing claims post-acquisition. The potential risk was material to Mars's business. Don't underestimate Oracle's willingness to pursue revenue through compliance enforcement in an M&A scenario.
A global manufacturing company that pursued frequent acquisitions was continuously challenged by Oracle licensing. Each acquired business came with its own Oracle footprint, and the parent allowed them to continue running existing Oracle-based ERP systems to avoid disrupting operations.
This resulted in a complex web of Oracle contracts and deployments. "Surprises" occurred when acquired companies had unexpected Oracle usage or lacked certain licences. The company ended up in almost perpetual negotiations with Oracle to true up licences or fold new acquisitions into their agreement.
Lesson: The importance of a strong internal process to assess Oracle licensing before an acquisition is finalised, so the parent can demand the target address any shortfall or include it in the deal valuation.
A large enterprise spun off a division that heavily relied on Oracle technology (Oracle Database, WebLogic, E-Business Suite). The parent did not secure any agreement with Oracle for transfer, assuming the division could "use what it has always used."
After the spin-off, Oracle informed the new company that the parent's licence agreement no longer covered them. The new company had 500 employees using an Oracle EBS module and several databases. Practically overnight, it was told it had no valid licence and must licence anew.
Impact: With ~500 users needing licensing at ~$800/user plus database licences, the new entity faced a multi-million dollar spend it hadn't budgeted. Divested units often scramble to strike a deal with Oracle under duress.
Company X entered an Oracle ULA covering its enterprise software needs. During the ULA period, they acquired another firm, doubling their employee count. However, the ULA contract said new acquisitions above a certain size required Oracle's approval to be included.
Oracle did not approve adding this large acquisition into the ULA. When the ULA ended, Company X could only certify licences for its original footprint. The acquired company's deployments were outside the ULA. Those deployments were suddenly unlicensed.
Impact: The company had to negotiate a separate purchase costing millions. ULAs can be dangerous in M&A if you don't negotiate terms for acquisitions and divestitures up front.
Managing Oracle licences in a merger, acquisition, or divestiture requires a structured approach across three phases.
Identify every Oracle database, application server, enterprise application, Java installation in the target. Capture version, edition, user counts, processors/cores, options, and packs in use.
Obtain every Oracle licence agreement, ordering document, ULA, and support renewal. Focus on clauses about Customer Definition, Assignment, Acquisition, Divestiture, and Territory restrictions.
Develop a licence compliance report for due diligence. Is the target under-licensed? Over-licensed? Using virtualisation in ways Oracle doesn't permit? Factor any liability into the deal.
Quantify what it would cost to address any issues. If the target needs $2M in Oracle licences to become compliant, that affects the purchase price. Sellers should know if Oracle licences will be an issue for the unit being divested.
Involve your SAM team or a third-party Oracle licensing expert during M&A planning. The cost of expert advice is minor compared to a licensing mistake in a merger.
Decide: Will the acquired company operate separately with existing licences, or immediately integrate? For divestitures, plan how the new entity will get its Oracle software.
Notify Oracle of the upcoming change and request discussions on handling licences. Frame as "We want to remain compliant." Don't reveal more than necessary. Don't volunteer information about potential overuse.
For acquisitions: ask Oracle to recognise the acquired entity's licences and consolidate into your agreement. For divestitures: negotiate a carve-out agreement with an extended grace period (6+ months).
Running both contracts in parallel is safe initially. If consolidating, ensure you aren't giving up advantageous terms from older contracts.
Get formal documentation: amendment, new ordering document, or at minimum written confirmation from Oracle's contracts/legal department. Verbal assurances from sales reps are insufficient.
Oracle knows you could migrate away during a reorganisation. Use that implied threat to negotiate better pricing, multi-year support caps, or cloud credits.
If you plan to retire some Oracle software during integration, negotiate short-term extensions or term licences rather than full perpetual licences for interim use.
Ensure all paperwork is fully executed. Update internal records and communicate to IT teams what can and cannot be done under the new arrangements.
Work with Oracle's support renewals team. Watch out for the first support renewal post-merger. Double-check quantities and fees for errors.
Allocate the combined pool of licences efficiently. Track usage for later certification if required.
User counts often swell during integration. Adjust licences before Oracle finds discrepancies in an audit. Track decommissioned systems for potential savings.
Standardise metrics if possible (Processor vs. NUP), rationalise edition differences (Standard vs. Enterprise), and identify excess licences.
M&A is a high-risk audit period. Document all Oracle communications, keep consent letters safe, run internal audits periodically. Oracle commonly returns 6–12 months after a merger.
IT managers, procurement, project managers, and acquired employees all need to know the new licensing boundaries.
Be cautious with Oracle in virtualised environments. Moving Oracle workloads into shared VMware clusters may require licensing the entire cluster.
When two companies become one via merger or acquisition, they may end up with multiple Oracle licence agreements. Deciding how to combine these, if at all, is a strategic step.
Initially, it's perfectly acceptable to keep legacy agreements separate. Company B (now a subsidiary of A) continues using Oracle under its original contract while Company A uses its own. Over time, running multiple contracts can be cumbersome, but scrutinise the terms carefully before consolidating. Older contracts might have clauses you value (like perpetual legacy rights) that newer Oracle agreements don't include.
Oracle often prefers to merge contracts into one umbrella agreement for simplicity (and sales opportunity). If you consolidate, negotiate as part of a broader settlement: sign a new Master Agreement covering both companies and purchase additional licences to true up, but in return secure a discount or a cap on support increases. Use the opportunity to improve terms such as obtaining more flexible global usage rights.
Work with Oracle's support renewals team to consolidate support contracts. Oracle often merges support streams by adding the acquired company's fees to yours. If the acquired company had a lower discount on support, Oracle might try to align it with your (potentially higher) pricing. Push back on any attempt to remove grandfathered discounts.
Best Practice: Run separate contracts temporarily while negotiating a unified deal. There's no rush to combine if it could lose value. Before the first post-merger support renewal, verify quantities and fees. Errors happen during consolidation: licences counted twice, wrong pricing applied, etc.
Divestitures present the opposite challenge: a single set of Oracle contracts must be divided between the parent and the separated entity.
A Transition Services Agreement is common in divestitures. The parent continues running systems for the new company for a period (typically 6–12 months). However, Oracle may treat the new company as a third party. Inform Oracle of the TSA arrangement and get written consent that it's permissible under the parent's licences. Negotiate the duration and scope.
Negotiate a carve-out agreement for the divested entity. The parent (as the existing Oracle customer) has leverage to advocate for the newco before they become a separate, unknown customer. Key elements: extended grace period beyond 90 days (target 6–12 months), licence purchase for the newco at similar discount levels, right to assign specific licences from the parent's pool, and support continuity to prevent list-price support rates.
After the divestiture, the parent may have excess licences no longer needed. Either negotiate to transfer those licences to the newco as part of the deal (if Oracle consents), repurpose them elsewhere in your organisation, or negotiate with Oracle to drop them from your support stream at renewal time.
Key Risk: Once the newco is a separate entity, Oracle knows it has little leverage if it urgently needs Oracle system continuity. Negotiate everything before the separation closes. Include divestiture licence cleanup in your separation agreement.
Each Oracle product may have its own twist during M&A. Treat each major Oracle-based system as its own line item in your M&A checklist.
| Product Line | Key M&A Consideration | Common Pitfall |
|---|---|---|
| Oracle Database | Licence by Processor or Named User Plus (NUP). Merging environments may require relicensing for new hardware/combined user counts. Check for activated options and packs (Partitioning, Diagnostics Pack, etc.). | Consolidating databases into shared VMware clusters without licensing the full cluster. Options auto-enabled during migration. |
| Oracle Middleware | WebLogic Server, Fusion Middleware have separate licensing. New application deployments post-merger may require additional middleware licences. | Assuming middleware is covered by database licences. Each product is licensed independently. |
| Enterprise Applications | EBS, PeopleSoft, Hyperion application user licences typically based on Named User Plus counts. Merging headcounts increases licensed user requirements significantly. | Not accounting for increased headcount post-merger. 500 new employees accessing PeopleSoft may require 500 additional licences. |
| Oracle Java | Java licensing changed to an Employee Metric model. A merger may double your employee count and thus your Java licensing obligation. | Overlooking Java SE installations on acquired company's servers. Java is often "invisible" but licences are required. |
| Oracle Cloud (OCI / SaaS) | Cloud subscriptions may be tied to the original customer entity. Reassigning cloud services to a new corporate structure may require Oracle approval. | Assuming cloud subscriptions automatically transfer. Cloud contracts have their own assignment and change-of-control clauses. |
| Oracle ULA / PULA | ULAs have strict M&A clauses. Acquisitions above thresholds may be excluded. Divestitures typically end coverage for the spun-off entity. | Not negotiating M&A flexibility clauses in the ULA upfront. Certifying a ULA mid-acquisition without understanding implications. |
Oracle's sales teams for each product line might be different, so you may negotiate with multiple groups (tech vs. applications vs. Java vs. cloud reps). Ensure consistency in what you tell each and, if possible, coordinate via your main Oracle account manager.
Oracle's policies are largely global, but the legal and practical enforcement can vary by region.
Some Oracle contracts limit usage to specific countries or regions. A cross-border merger may require renegotiating territory clauses to cover the combined entity's global footprint.
If Oracle cloud services are part of the deal, ensure data sovereignty rules are met. Merging Oracle Cloud deployments across countries may have regulatory implications beyond licensing.
Multi-country deals may have different pricing. When consolidating contracts, Oracle may try to align to the highest-priced region. Negotiate currency protections for multi-year commitments.
Oracle's audit approach can vary by region. Some offices may be more aggressive than others. EU data protection laws (GDPR) may affect what data you're required to share during an audit. Know your rights.
Oracle requires written consent for any transfer, assignment, or change of control. Never assume licences move automatically in a deal.
Oracle routinely audits newly merged companies. Expect comprehensive reviews across all product lines 6–12 months after a deal closes.
Acquired entities aren't covered under your Oracle agreement until formally added. Divested entities lose coverage once no longer majority-owned.
Treat Oracle licence compliance as a line item in M&A valuation. Quantify gaps and factor them into pricing.
Notify Oracle per contract requirements. Get every permission, grace period, and transfer approval documented formally.
Demand extended grace periods, assignment rights, support cost caps, and rate protections. Use the M&A moment as leverage.
Database, middleware, applications, Java, cloud, and ULAs each have their own M&A implications. Check each independently.
Get TSA approvals, negotiate carve-out terms, and ensure the newco has licences before separation day, not after.
Generally, no. Not without Oracle's prior written consent. Oracle's standard contracts explicitly state that licences are non-transferable. Some contracts allow assignment in the event of a full merger of the licensee, but you must notify Oracle formally and often obtain consent. Partial transfers (carving out a subset to a spun-off company) are rarely permitted without Oracle's written agreement. Always review your specific contract's assignment and change-of-control clauses.
Oracle does not automatically transfer licences to the new owner. Standard terms typically allow the divested entity to continue using Oracle software for a short transition period (often 90 days) under the seller's agreement. After that, the divested entity must purchase its own licences. Without a negotiated carve-out agreement or transition services arrangement (with Oracle's written consent), the new company would be using Oracle software without a valid licence.
Yes. M&A activity is one of the top triggers for an Oracle licence audit. Oracle's LMS/GLAS team monitors news of acquisitions and corporate changes. It's common for Oracle to initiate a "licence review" shortly after a major acquisition becomes public. These audits tend to be comprehensive, covering all Oracle products in use (databases, middleware, applications, Java, cloud). Expect heightened scrutiny for 6–12 months following the deal.
ULAs have strict M&A clauses. Small acquisitions may be allowed to join the ULA, but larger ones (often above a 10% threshold of your revenue or workforce) typically require Oracle's approval, which may not be granted. Immediately review your ULA's language on acquisitions. You may need to negotiate an amendment, certify early, or exclude the acquired entity and licence them separately. If you're being acquired, consider maximising deployments while you still have unlimited rights.
Your Oracle licensing due diligence should include: (1) Complete inventory of all Oracle products deployed by the target, (2) Collection and review of all Oracle contracts and ordering documents, (3) Compliance gap analysis comparing entitlements to actual usage, (4) Cost assessment for remediation of any gaps, (5) Review of special agreements like ULAs, PoF, or cloud subscriptions, (6) Assessment of support obligations and renewal timelines, and (7) Identification of any pending or recent Oracle audits. Factor any compliance liability into the acquisition price.
Yes, and you should. The parent company (as the existing Oracle customer with an established relationship and spend) has far more leverage than a newly independent entity. Before the divestiture closes, negotiate on behalf of the newco: secure extended grace periods (6–12 months), arrange licence purchases at similar discount levels to the parent's, and get Oracle's written consent for transition services. Once the newco is on its own, Oracle knows it has little leverage and may face list-price terms.