Top 15 Things CIOs Should Know About Oracle Licensing and Contracts in M&A

Top 15 Things CIOs Should Know About Oracle Licensing and Contracts in M&A

Executive Summary

Mergers, acquisitions, and divestitures can profoundly impact an enterprise’s Oracle licensing and contracts. CIOs must recognize that on-premises Oracle software licenses have strict terms defining where and how they can be used.

Without a clear Oracle licensing strategy in M&A, organizations risk compliance violations, unbudgeted costs, and legal disputes.

In short, treating Oracle licenses as a strategic asset during M&A is just as critical as any system integration or financial due diligence.

1. Oracle Licensing Scope is Limited to Named Entities

• Oracle’s Customer Definition – Oracle licenses are tied to a specific legal entity (the customer) and its majority-owned subsidiaries. Licenses do not automatically extend to newly acquired companies or merged entities unless the contract explicitly allows it. After an acquisition, the company’s Oracle licenses remain restricted to that original entity’s use, not the parent’s – the parent cannot simply “inherit” those licenses for broader use. CIOs must understand that each Oracle contract defines who is authorized to use the software (often only the entity named in the agreement).
• No Automatic License Sharing – A common M&A pitfall is assuming that once Company A acquires Company B, all Oracle licenses can be shared freely across the new combined organization. In reality, Company B is considered a separate customer in Oracle’s eyes unless Oracle’s consent is given or contracts are adjusted. For example, if Company A’s IT team starts deploying Oracle software using Company B’s licenses (or vice versa) without contract updates, it can constitute unlicensed use. CIOs should proactively plan how each entity’s licenses will be used post-merger to avoid inadvertent compliance breaches.

2. Licenses Are Non-Transferable Without Oracle’s Approval

• Anti-Assignment Clauses – Nearly all Oracle on-premise license agreements include a non-transferability or anti-assignment clause. You cannot transfer or assign Oracle licenses to a different legal entity without Oracle’s consent. Even mergers can be viewed as a transfer – Oracle often treats a merger as an assignment event if the entities weren’t originally covered under the same contract. Failure to get approval can put you in breach of contract. In one notable legal case (SQL Solutions vs. Oracle), a merger was deemed an unauthorized assignment of the software license, affirming that anti-assignment clauses can indeed block transfers in M&A.
• “Full Repurchase” Liability – If Oracle licenses can’t be transferred, the acquiring company may have to re-buy licenses for the new entity’s usage. Oracle is within its rights to insist that any use by an entity not originally named in the contract be newly licensed. In practical terms, this can force the buyer to purchase duplicate licenses for software it thought it already owned. For example, a large enterprise that merged IT environments discovered it needed 20 additional Oracle Database and Middleware processor licenses because the acquired firm’s licenses couldn’t simply be moved over. Oracle would not “transfer” those licenses, forcing the purchase of 20 new processor licenses – roughly $950,000 in new license fees (plus $209,000 in annual support). This unplanned cost hit the IT budget hard. The lesson: always factor in license transfer restrictions – if Oracle doesn’t approve a transfer, you must budget for new licenses or risk running unlicensed software.
• Oracle’s Consent (Get It in Writing) – If a transfer of licenses or contract assignment is needed, engage Oracle early and obtain written consent from Oracle’s contracts/legal department. Oracle may allow a license assignment to a successor entity in a merger if specific conditions are met (e.g., the new owner isn’t an Oracle competitor, and usage doesn’t expand). Even then, contracts usually require you to notify Oracle within a set timeframe and obtain Oracle’s agreement on a transfer. Missing a notice deadline or relying on informal assurances can be risky. Always get explicit written permission (a formal transfer letter) for license assignments; verbal promises from sales reps won’t hold up.

3. Check Change-of-Control Clauses and Entity Changes

• Review Merger/Acquisition Clauses – Some Oracle license agreements contain a change-of-control clause or specific merger provisions. These clauses might allow license assignment to a new owner if certain criteria are met (for instance, a merger where another company absorbs the original licensee). However, such clauses are not standard in every contract and often come with caveats (e.g., the new entity cannot be an Oracle competitor, or usage can’t expand beyond the original scope). CIOs should have legal counsel review all Oracle contracts for any change-of-control or assignment language before an M&A deal closes. If a contract permits transfer upon merger, follow any notice requirements strictly (e.g., notify Oracle within 30 days of the change).
• Entity Name Changes and Corporate Restructuring – A simple legal entity name change or internal reorganization can trigger Oracle’s assignment rules. Oracle contracts define the “Customer” by name; if that name or ownership structure changes, you may need to update the contract. For example, if your company merges into a new holding company or you carve out a subsidiary, the original agreements may not cover those “new” entities. Always inform Oracle of such changes to keep support valid and licenses in good standing. Oracle has, on occasion, denied support service to an acquired subsidiary that wasn’t on record in the support contract until the paperwork was sorted (though outright suspension is rare). The key point: Don’t assume Oracle licenses travel seamlessly with a business entity – verify and secure Oracle’s acknowledgment of any corporate changes.

4. Perform Thorough Oracle License Due Diligence Pre-M&A

• License Audit Before the Deal – Conduct a comprehensive audit of all Oracle licenses owned by acquiring and target organizations before merging or acquiring. Inventory every Oracle product, edition, and license metric, including quantities, CPU counts, Named User Plus counts, etc., and gather the contracts to review terms. This due diligence should identify any overlapping licenses, gaps, and compliance issues well in advance. Understanding each company’s Oracle license position helps avoid surprises – for instance, discovering post-merger that both firms were under-licensed for certain software, compounding the shortfall. During this review, it’s equally important to note any unique or special licensing agreements (e.g., legacy contracts or embedded software licenses tied to OEM systems).
• Align and Negotiate License Terms Early – Use the due diligence phase to engage with Oracle and negotiate any needed adjustments before the merger closes. If you identify that licenses need to be transferred or consolidated, approach Oracle to discuss terms. In some cases, Oracle may agree to recognize the combined entity under one set of licenses or allow a transfer, but these terms should be explicitly negotiated and documented. For example, you might negotiate a contract rider that extends Company A’s licenses to cover Company B’s usage from Day 1 of the merged entity. Proactively securing Oracle’s written confirmation of the new “customer” definition and license scope can prevent later audit disputes. By addressing licensing in the M&A negotiation (alongside assets and liabilities), CIOs can ensure a smoother IT integration with fewer compliance risks.

5. Over-Licensing After M&A – Duplicate Licenses Inflate Costs

• License Duplication Waste – When two companies merge, they often discover overlapping Oracle licenses for the same products. Both entities may have purchased licenses for Oracle Database or WebLogic Server, and the combined company now has more licenses than it needs. This over-licensing leads to unnecessary support and maintenance costs on the surplus licenses. For example, suppose each company had 50 processor licenses for Oracle Database and post-merger. In that case, the consolidated systems only require 60, and the merged firm is paying support on 40 extra licenses that provide no value. Such duplication is common in M&A and directly hits the IT budget.
• Rationalize and Consolidate – CIOs should identify these overlaps quickly and look for ways to eliminate waste. Oracle typically won’t give refunds for unused licenses. Still, you can terminate unused licenses to cut support costs. However, Oracle’s policies make it hard to drop support on licenses you still own without terminating them entirely. Another approach is negotiating with Oracle to apply credit from redundant licenses toward new products or expanded use of other licenses as part of a contract consolidation. The key is to avoid blindly renewing all support contracts post-merger. Instead, analyze which Oracle licenses are needed in the new environment and budget for the possibility that some support contracts should be retired (per Oracle’s rules) if licenses are not used. Proper planning can turn over-licensing into an opportunity for cost optimization rather than a sunk cost.

6. Under-Licensing Risks – Compliance Gaps After a Merger

• License Shortfalls in New Environment – The flip side of duplication is under-licensing, which occurs when the merged entity’s usage of Oracle software exceeds the combined entitlements. A classic mistake is assuming one company’s licenses cover the other’s usage. For instance, Company A acquires Company B and thinks Company A’s Oracle licenses now magically cover Company B’s deployments – they do not. Later, an Oracle audit might reveal that certain databases or users in Company B’s environment are not licensed under Company A’s agreements. Under-licensing often comes to light when systems are integrated. Suddenly, more processors are running Oracle, and more employees have access to an Oracle application than either company had licensed individually.
• Assess and Remedy Immediately – Performing a post-merger license compliance assessment is critical. Count the actual Oracle usage across the combined entity (e.g., total CPUs running Oracle Database, total user counts for Oracle E-Business modules, etc.) and compare against all available licenses. If any shortfall is identified, address it proactively, purchasing additional licenses or reallocating deployments, before Oracle’s auditors knock. Oracle’s audit teams actively look for these post-M&A compliance gaps. It is far better for a CIO to budget and true-up licenses voluntarily than to face a formal audit finding, which could include back-support fees and penalties. You maintain compliance by immediately right-sizing the Oracle licenses to the new organization’s needs (even if it means an unplanned purchase). You can often negotiate better pricing than after an audit has begun.

7. Conflicting License Metrics and Contract Terms

• Incompatible Licensing Models – Merging companies may have fundamentally different Oracle licensing metrics and terms, which don’t easily mesh. One company might license Oracle Database using processor cores. At the same time, the other used the Named User Plus (NUP) metric, or one had an Unlimited License Agreement (ULA) while the other had standard perpetual licenses. These differences can’t be combined straightforwardly. For example, 100 NUP licenses from one contract can’t be converted to cover processors in a unified environment without renegotiation. Similarly, metrics for middleware or applications might differ (one company licenses WebLogic per core, the other per JVM, etc.). This creates complexity in ensuring the merged usage stays compliant under two rules.
• Differing Contract Terms – Beyond metrics, the actual contract clauses may conflict. Company A’s Oracle contract might allow usage by any global affiliate, whereas Company B’s contract restricts use to the specific operating company. Or perhaps one contract has a favorable clause allowing a degree of outsourcing or virtualization, while the other forbids a certain virtualization technology. These inconsistent terms can create gray areas post-merger. If IT combines systems, assuming the more lenient terms apply, the company could inadvertently violate the stricter contract’s terms.
• Reconcile and Consolidate Agreements. To avoid confusion, CIOs should work towards consolidating Oracle contracts or reconciling their terms as soon as possible. This might involve negotiating a new master agreement with Oracle that covers the entire merged entity under one consistent set of definitions and metrics. Consolidation simplifies compliance and administration – you’ll have one “customer definition,” one pricing metric per product, and a clear understanding of usage rights. Until contracts are consolidated, be extremely cautious: enforce the most restrictive terms across the board to stay safe. It may also be wise to involve Oracle or a licensing expert to map out how to transition to a single contract without losing any prior negotiated benefits or discounts.

8. Consolidate Oracle Licensing Agreements Post-Merger

• Streamline Contracts – After an acquisition, companies often manage multiple Oracle license agreements (each with different metrics and terms, as noted above). Consolidating these into a single Oracle Master Agreement (OMA) or a unified set of licenses should be a priority. A consolidated agreement clarifies who the customer is (the newly merged entity) and the usage rights across all Oracle products. It also simplifies annual support renewals and reduces administrative overhead. Importantly, consolidation can eliminate ambiguities that Oracle might otherwise exploit during audits – if all licenses fall under one consistent contract, there’s less room for interpretation or conflict.
• Negotiating Consolidation – Work with Oracle account management to merge contracts at a natural point (for example, aligning with support renewal cycles or at the deal’s close). Oracle is typically open to consolidation because it often presents an opportunity to upsell or normalize pricing. CIOs, however, should approach this strategically: ensure the consolidated deal preserves any existing discounts and favorable terms. Also, clarify the new support fee baseline – merging contracts can trigger support re-pricing if not handled carefully (Oracle might remove grandfathered discounts when combining contracts). All of these factors should be negotiated. While consolidating, address any special legacy arrangements (like a limited-use license tied to a specific subsidiary or an ISV/OEM-provided license). Those may need separate treatment or new licenses, as they might not carry over to a new master contract. The end goal is one coherent contract covering the entire enterprise, greatly easing compliance management and Oracle’s understanding of your rights.

9. Acquired Company’s Licenses Can’t Be Freely Repurposed

• No Automatic “License Inheritance” – It’s worth emphasizing: when you buy a company, you acquire its Oracle contracts (as legal assets) but not a carte blanche to use its licenses however you want. The acquired licenses remain subject to their original terms, which usually restrict use to the initially licensed entity. The acquiring organization (new parent) is not automatically an authorized user just because it owns the company. Suppose you consolidate IT environments (for example, moving an acquired business’s databases onto the parent’s data center or merging user populations). In that case, those acquired licenses may become shelfware unless Oracle approves their use in the new context. Many companies have been caught off-guard here: they think they have plenty of licenses via the acquisition, only to learn those licenses can’t legally be used for the merged environment.
• Example – Integration Pitfall: Imagine Company A (the acquirer) running its ERP on Oracle Database, and so does Company B (the acquired firm). Post-merger, Company A migrates Company B’s ERP databases into Company A’s data center. Suppose Company A’s staff/users are now accessing those databases. In that case, technically, Company B’s Oracle DB licenses are being used by an entity (Company A) that is not covered by Company B’s contract – a compliance violation. Oracle would likely insist that Company A procure new licenses or properly assign B’s licenses to A (with Oracle’s consent). If that doesn’t happen, the acquired licenses sit idle (since Company B’s systems were absorbed). The costly example above shows that new licenses must be purchased for the consolidated system. CIO takeaway: Plan how each Oracle-installed system will be handled before integration. Keeping certain systems running separately under the acquired entity may be safer until licenses are sorted out or a transition can be negotiated with Oracle. Never assume you can combine environments and “figure out the licenses later”; it may be too late or expensive by then.

10. Beware of Limited-Use and Specialty Licenses

• License Scope Restrictions – Not all Oracle licenses are “full use.” Some may be limited-use licenses tied to a specific application or a particular project or obtained through special programs (like an Oracle ISV/OEM partner). Examples include Application Specific Full Use (ASFU) licenses that allow using Oracle Database only with a particular application or demo/development licenses that aren’t for production. In an M&A scenario, these constraints carry over – you cannot suddenly repurpose an ASFU Oracle Database license from the acquired company for general use in the parent company. Suppose Company B’s Oracle licenses were purchased under a limited agreement (say, discounted for use only with a certain software package or for a particular subsidiary’s internal use). In that case, those restrictions remain in force after acquisition.
• Non-Transferability of Special Programs – Often, licenses obtained via unique programs (such as a merger-specific transition license Oracle might grant or licenses bundled through an acquisition of another software vendor) are explicitly non-transferable outside the original context. During due diligence, flag any licenses described as “limited,” “internal use only,” or tied to an affiliate/third party. Oracle may require those to be re-licensed if the usage context changes. For example, suppose a target company has Oracle licenses that were part of an enterprise package deal or a heavily discounted migration offer. In that case, Oracle might not allow the acquiring company to inherit those terms. The acquirer might have to renegotiate or purchase standard licenses to cover the functionality. In summary, CIOs should treat specialty Oracle licenses cautiously, assuming they cannot be extended post-merger without Oracle’s agreement. Budgeting to replace them with full-use licenses may be necessary to meet the combined company’s needs.

11. Support and Maintenance Fee Implications

• Combining Support Contracts – Oracle’s annual support fees (typically ~22% of the license price) follow the licenses and are tied to specific customer accounts. After a merger, if you attempt to combine two support contracts into one, Oracle may seize the opportunity to reprice the support costs. They will often align the support fees with current list prices or unify discount rates, which can eliminate any historical discounts one company enjoyed. As a result, the merged support invoice can jump unexpectedly. For instance, if Company A had a deep discount on support for its database licenses, and Company B paid closer to the list price, Oracle might average out or remove the discount when consolidating, leading to higher costs for Company A’s portion. Always ask Oracle for a support fee impact analysis when considering merging support agreements. In some cases, it might make financial sense to keep support contracts separate (if allowed) to preserve a discount structure rather than rush to consolidation.
• Non-Transferable Support Contracts – Support contracts are tied to the license owner. If licenses aren’t transferred to the new entity, the support can’t be switched over either. The new company might have to start a fresh support agreement for the acquired licenses at the prevailing support rates (which could be higher). Conversely, in a divestiture, the spun-off entity typically must establish its support contract – the parent can’t continue covering them once they’re a separate company. Plan for these support contract transitions.
• Minimum Support Requirements – Oracle has strict policies on dropping support. If the merged entity has excess licenses, you can’t drop support on some licenses while keeping others without potentially violating Oracle’s repricing rules. Oracle often requires that if you maintain support on a license set, you maintain it on all of them, or if you terminate licenses to reduce support, you may have to pay a penalty or lose rights to updates on those licenses. CIOs should carefully review Oracle’s technical support policies regarding mergers. Suppose you decide not to use certain licenses post-merger. In that case, it might be better to formally terminate those licenses (with Oracle’s agreement) and stop paying support. However, note that Oracle typically doesn’t allow partial termination of a license set without a fight. It’s a delicate dance: you must maintain compliance (no using software without support if required by policy for updates/fixes) while trying not to overpay on unneeded licenses. Early engagement with Oracle on support terminations or transfers and getting any agreements in writing is crucial.

12. Oracle Audits Are Likely After M&A

• M&A = Audit Trigger – It is well known in the enterprise software world that a major merger or acquisition is one of the top triggers for a software license audit, and Oracle is no exception. Oracle’s License Management Services (LMS, now part of GLAS – Global Licensing and Advisory Services) closely monitors M&A news. It’s common for Oracle to initiate a formal license review or audit soon after a significant acquisition is announced or finalized. From Oracle’s perspective, corporate changes present revenue opportunities: newly combined companies might unknowingly be out of compliance, and Oracle’s audit can uncover shortfalls that lead to additional license sales. CIOs should expect an Oracle audit after an M&A and prepare accordingly.
• Broad Scope Compliance Review – When Oracle audits a merged company, they typically examine the entire Oracle portfolio, not just databases. You should be prepared for Oracle to review database licenses, middleware (WebLogic, Fusion Middleware, etc.), enterprise applications (E-Business Suite, PeopleSoft, Hyperion), and even Oracle Java usage or any on-premises Oracle products across both former entities. An integration project might focus on one system (e.g., combining ERPs), but Oracle’s auditors will take a holistic approach, potentially catching you off guard in other areas. For example, you might be meticulously counting database CPUs. Still, Oracle could simultaneously scrutinize whether the combined HR department now exceeds the licensed headcount for PeopleSoft or if an acquired business’s use of WebLogic Server is properly licensed. The audit will likely be especially rigorous post-M&A – Oracle knows this is fertile ground for compliance issues.
• Audit Readiness – Given this high likelihood, doing an internal Oracle compliance check immediately after (or during) the integration is wise. Ensure all Oracle deployments in the new entity are accounted for and within entitlement. Keep meticulous documentation of license proofs (contracts, ordering documents, evidence of Oracle approvals) readily available. If Oracle sends an audit notice, involve your legal team and consider engaging a third-party Oracle licensing expert to manage the process. Oracle audits after M&A can become contentious – in one high-profile example, after Mars, Inc. acquired Wrigley, Oracle’s aggressive post-merger audit demands escalated into a legal battle. Oracle ultimately settled, but not before Mars had to devote extensive resources to defend its license position. The best defense is preparation and a documented license inventory to show Oracle (proactively or during an audit) that you’ve kept compliant through the transition.

13. Oracle Sales Pressure and Tactics Post-Merger

• Push for a ULA or Cloud Deal – As soon as an acquisition is public, Oracle’s sales team will often approach the company with proposals to “simplify” licensing across the new organization. CIOs frequently report getting offers for an Oracle Unlimited License Agreement (ULA) or other large enterprise agreements right after M&A news breaks. Oracle will frame this as a solution to your compliance worries: a ULA can give you unlimited use of certain products for a fixed period, ostensibly covering any growth from the merger. While this can sound attractive (no immediate need to count licenses during integration), remember that Oracle’s motive is to lock in a big sale and revenue commitment. These post-M&A ULAs or cloud subscription offers might come with pressure (“sign this, and we won’t audit you now”) – but they may not be the best financial decision long-term.
• Evaluate Critically – Do not rush into an Oracle ULA or mega-deal out of fear. ULAs can be double-edged: if your merged company’s Oracle usage indeed expands greatly, a ULA could be useful; however, if growth is uncertain or you might divest parts later, a ULA could mean overcommitting or facing challenges when it ends. Also, if Oracle offers a cloud transition deal (like moving to Oracle Cloud SaaS or PaaS), ensure it aligns with your IT strategy, not just Oracle’s sales quota. Always analyze these proposals clearly, and involve your software asset management team or an independent advisor. It’s perfectly acceptable to take Oracle’s offer under advisement, make an internal cost comparison (what if we true-up the few licenses we need vs. signing a multi-million dollar ULA?), and even negotiate the terms. Oracle’s first offer is rarely their best, and you may not need an unlimited deal if your diligence shows you’re largely compliant. The key is not to let the fear of an audit push you into a hasty contract. Use Oracle’s eagerness to your advantage – for example, you might negotiate a more flexible ULA that includes a merger clause or better divestiture rights if you decide a ULA is necessary.

14. Unlimited License Agreements (ULAs) – Special M&A Pitfalls

• ULA Basics – An Oracle ULA is a time-bound contract (typically 3-5 years) allowing unlimited deployment of specific Oracle products, after which you must certify usage. ULAs have very particular rules regarding mergers and acquisitions. Small acquisitions by a ULA customer are often allowed (e.g., add a newly acquired small subsidiary’s usage into the ULA). Still, larger acquisitions are usually excluded, meaning your ULA does not cover their Oracle usage if you acquire a company above a certain size or outside a defined threshold. Oracle ULAs include a customer definition exhibit listing the legal entities covered. By definition, any entity not listed is NOT allowed to use the ULA’s unlimited deployment rights. If your organization, operating under a ULA, acquires another company, that new entity’s Oracle deployments will require separate licensing unless you negotiate to add them.
• ULA Exit and Change of Control, ULAs also typically have a clause that if another company acquires the ULA customer, the ULA terminates or is not transferable. So, if you are in a ULA and your company is being merged or bought, the unlimited rights could cease unless the contract explicitly permits the successor to inherit the ULA (which is not standard). Similarly, if you divest a business unit during a ULA, that divested entity loses unlimited usage rights, often after a short grace period, like 30-90 days. After that, the spun-off business must stop using Oracle or purchase its licenses. This is why, during ULA negotiations, some companies try to insert clauses to accommodate M&A, for example, allowing the inclusion of acquisitions below a certain employee count or giving a divested entity the right to continue using Oracle for a limited time. CIOs with ULAs must be especially vigilant in M&A: talk to Oracle before any deal, if possible, to clarify how the ULA will be handled. If not, be prepared that an acquisition may trigger a ULA certification or termination event. The bottom line is that ULAs can instantly become a compliance headache in M&A if their conditions aren’t managed. Always review the specific ULA terms around mergers and acquisitions – they might dictate immediate actions (or purchases) needed to remain compliant.

15. Divestitures Require License Carve-Out Planning

• Spinoff and Carve-Out Licenses – On the flip side of acquisitions, Oracle licensing considerations are critical when your company divests a business or spins off a subsidiary. Oracle licenses cannot be split up and given to the new standalone company unless Oracle agrees. Most Oracle contracts treat a divestiture as an unlicensed scenario for the new entity, except for possibly a short transition window. For example, an Oracle contract might allow a divested entity to continue using the parent’s Oracle software for 30, 60, or 90 days post-separation. After that, the new entity must cease using the software or purchase its licenses. Oracle will enforce these timelines, often reaching out as the deadline approaches to ensure compliance. CIOs should plan from Day 1 of a carve-out: which Oracle systems does the new company rely on, and how will it operate once it’s no longer part of the parent’s Oracle agreements?
• Negotiating Transition – Negotiating a transition services agreement (TSA) or specific license deal with Oracle for the divestiture is wise. Sometimes, the parent company can secure a deal for the spin-off to buy needed licenses at a predefined discount as part of the separation (Oracle’s involvement is needed). Otherwise, the new entity may be at Oracle’s mercy after the grace period – Oracle knows a separated business can’t afford downtime, giving Oracle strong leverage to sell licenses at less favorable terms. In practice, Oracle often approaches the divested company directly to convert it into a new customer. To avoid chaos, include IT and licensing in your divestiture planning checklist: determine if you will keep certain Oracle systems running for the new entity under a TSA (and for how long), and ensure the new entity understands they must budget for their own Oracle licenses and support very quickly. By planning, the departing unit can smoothly transition to its contract without jeopardizing operations.
• Adjusting the Parent’s Licenses – After divestiture, the parent company might have surplus licenses that the carved-out unit used. The parent will want to reduce costs by terminating those licenses or support. However, as mentioned, Oracle doesn’t easily allow dropping licenses from support unless you fully terminate them (and even then, there may be restrictions). One strategy is to negotiate an amendment with Oracle at the time of divestiture: perhaps Oracle will let you terminate licenses used by the spin-off if that spin-off buys its own. Alternatively, if possible, the parent might repurpose those licenses internally (assuming they stay compliant). The key is to communicate with Oracle. They will be involved anyway, and strike a deal that addresses the new company’s needs and the parent’s desire not to pay for licenses it no longer uses. Ignoring Oracle licensing in a divestiture can lead to the parent unknowingly paying for software support now running in someone else’s data center or the new company scrambling under an Oracle audit after the grace period. Both scenarios are preventable with foresight and open dialogue with Oracle.

Recommendations

• Integrate Licensing into M&A Planning – Treat Oracle licenses as a critical component of due diligence. Inventory and review all Oracle contracts and deployments for the buyer and target before the deal closes.
• Engage Oracle (or Experts) Early – Proactively communicate with Oracle about the impending merger or acquisition to discuss license transfers or needed contract adjustments. Engage experienced Oracle licensing consultants or legal advisors to help negotiate terms that protect your interests.
• Document Everything – Keep meticulous records of Oracle license entitlements, contracts, and any correspondence with Oracle regarding M&A. If Oracle grants special permissions (e.g., a transfer or extended usage), get it in writing. This documentation will be invaluable in an audit or dispute.
• Avoid Assumptions – Never assume that licenses will “just transfer” or that Oracle will be lenient because of the business change. Always verify contract terms and get Oracle’s consent where required. Assume Oracle will enforce the exact letter of the agreement.
• Plan for Extra Costs – Budget for potential increases in Oracle licensing costs during M&A. This may include purchasing additional licenses if needed, higher support fees after contract consolidation, or even a one-time spend to resolve compliance gaps. It’s better to anticipate these costs than be caught off guard.
• Audit Readiness – Operate under the expectation that Oracle will audit you post-M&A. Perform internal audits, reconcile entitlements vs. usage, and address any compliance issues proactively. Being prepared can turn an Oracle audit from a threat into a manageable process.
• ULA and Special Contracts Caution – If you have an Oracle ULA or any special licensing agreements, review the exact language on mergers, acquisitions, and divestitures. Consider renegotiating these clauses if an M&A event is likely. Ensure any new ULA you sign includes flexibility for foreseeable corporate changes.

FAQ (Oracle Licensing in M&A)

• Q: Do we need Oracle’s permission to transfer licenses in a merger or acquisition?
  A: Nearly all Oracle on-prem licenses are non-transferable without Oracle’s consent. A merger or acquisition does not automatically transfer Oracle licenses to the buyer. You should seek Oracle’s written approval for any license assignment as part of the transaction. Without approval, the acquirer’s use of the target’s licenses would be unlicensed and in breach of contract.
• Q: Can the acquiring company use the acquired company’s Oracle software licenses immediately after closing?
  A: Only within strict limits. Oracle licenses are typically restricted to the entity that purchased them and its named affiliate. After closing, the acquired company’s licenses only cover that entity (now a subsidiary, presumably). The parent/acquiring company itself is not automatically covered. To use those licenses enterprise-wide, you’d need to negotiate with Oracle to consolidate or transfer them. Without that, the acquired licenses should be used only for the acquired entity’s pre-existing deployments – until you get Oracle’s consent for broader use.
• Q: How does a merger affect our Oracle Unlimited License Agreement (ULA)?
  A: Oracle ULAs have specific clauses for mergers and acquisitions. Generally, if you acquire a company, its Oracle usage is not automatically included in your ULA unless the contract allows it (often, it doesn’t for large acquisitions). You may need to notify Oracle and pay an extra fee or true-up to include the new acquisition. If another acquires your company, most ULA contracts terminate, meaning the unlimited deployment rights end, and you’d have to certify your usage at that point. It’s crucial to check your ULA’s terms on M&A and involve Oracle immediately if a corporate change is coming.
• Q: Will Oracle audit us after a merger or acquisition?
  A: It’s very likely. M&A is a well-known trigger for Oracle audits. Oracle often initiates a license review or audit soon after deals are announced or closed. They will want to verify that the combined entity’s usage aligns with entitlements and will look for any gaps or non-compliance (which can lead to proposals for additional licenses). Preparing for an audit by conducting your internal compliance check is highly recommended.
• Q: What should we look for in Oracle contracts during M&A due diligence?
  A: Focus on clauses about assignment, change of control, customer definition, and usage restrictions. Check if the contract names specific affiliated entities or if it has territorial limits. Identify any clause that says licenses are non-transferable (most do). Also, the support policies related to those contracts should be reviewed. Essentially, find anything that dictates what happens if the licensee company changes or if assets are transferred – these will govern how you need to handle the licenses in the deal.
• Q: Can we consolidate Oracle license agreements after an acquisition?
  A: Yes, and it’s often a good idea. You can work with Oracle to consolidate multiple agreements into one master contract covering the newly merged entity. Doing so can simplify license management and eliminate conflicting terms. However, plan the timing to avoid negatively impacting support fee calculations. It might be done at renewal time or during a broader negotiation, during which you can also true-up licenses. Always preserve any advantageous terms from each contract during consolidation – don’t lose a favorable clause or discount if you can help it.
• Q: How does a merger impact Oracle support fees?
  A: Support fees can change. If you maintain separate support contracts for each legacy company, you’ll each continue paying your agreed rates. However, if you combine support contracts, Oracle might recalculate the support costs at current list prices or harmonize discounts, which can increase the total annual fee. Also, suppose you have excess licenses and want to drop support on them post-merger. In that case, Oracle’s policies might force you to terminate the licenses entirely or maintain a certain support level. It requires careful negotiation with Oracle to adjust support without incurring big increases.
• Q: We’re divesting a division – can that new company keep using our Oracle licenses?
  A: Only temporarily, if at all. Often, Oracle contracts allow a divested entity to use the software for a short grace period (e.g., 90 days). After that, the new company must stop using the parent’s licenses and obtain its own. You should notify Oracle of the divestiture and the timeline. In many cases, Oracle will approach the new entity to sell them a fresh license deal. Coordinating this is wise so the spin-off isn’t cut off or forced into a very expensive purchase under time pressure.
• Q: How can we minimize Oracle license compliance issues during M&A?
  A: Preparation and communication are key. Do a thorough license inventory and compliance check before the merger. Engage Oracle (under NDA if needed) to discuss how to handle the licenses – you might negotiate specific terms or get approvals in advance. After the merger, closely monitor Oracle software deployments during integration to ensure you don’t exceed what’s licensed or use licenses improperly. If possible, phase Oracle-related integrations until you sort out contract issues (e.g., keep using separate environments for a period). Always document everything – have a clear paper trail of what was agreed upon with Oracle.
• Q: Should we get third-party help for Oracle licensing in M&A?
  A: It’s often beneficial. Oracle licensing rules are complex, and M&A scenarios add extra layers of difficulty. Engaging a software licensing advisory firm or an Oracle licensing expert can provide an objective analysis of both companies’ entitlements and usage. They can identify risks and opportunities that IT teams might miss and assist in negotiations with Oracle to secure favorable terms or waivers. Similarly, involve your legal team – some issues cross into contract law (e.g., anti-assignment clauses). The cost of expert help is usually far less than the potential cost of an Oracle compliance problem or suboptimal contract.