Managing Oracle Licenses During Mergers, Acquisitions & Divestitures

Managing Oracle Licenses During Mergers, Acquisitions & Divestitures

Mergers, acquisitions, and divestitures create complex challenges for Oracle software licensing. Oracle’s licensing agreements are famously strict, and an organizational change can easily put a company out of compliance if not managed carefully.

This advisory article explains how Software Asset Management (SAM) managers and Oracle licensing professionals can navigate these scenarios.

We’ll cover Oracle’s standard policies on license transfers, common contractual pitfalls, typical Oracle behavior when companies merge or split, real-world case examples, and best practices for pre-deal diligence through post-deal integration.

The goal is to help you protect your organization’s interests and avoid costly surprises with a customer-advocating tone that alerts you to risks and offers independent advice.

Oracle’s Policies on License Transferability in M&A

Oracle’s standard contracts include clauses that strictly regulate who can use the software. In Oracle license agreements (such as the Oracle Master Agreement or Ordering Documents), licenses are generally non-transferable without Oracle’s consent.

Unless certain conditions are met, you cannot assign or “hand off” Oracle licenses to another company in an acquisition or divestiture.

Key policy points include:

• Customer Definition: Oracle defines the contract’s licensed customer as your company and its subsidiaries. Typically, only the entities listed or defined as “Majority Owned” (over 50% ownership) by the main licensee can use the software. If a new entity joins via acquisition, it is not automatically covered unless the contract is updated to include it. If an entity leaves (divestiture), it usually loses the rights to use the parent company’s licenses once it is no longer majority-owned.
• Assignment Clauses: Oracle contracts often have an assignment or transfer clause. Commonly, they prohibit transferring licenses to another entity without Oracle’s prior written approval. Some contracts allow assignment in the event of a full merger or acquisition of your company’s assets, but even then, you must notify Oracle formally. Partial transfers (like carving out a subset of licenses to a spun-off company) are usually not permitted unless Oracle agrees in writing.
• Divestiture (Split) Policy: When you divest a business unit or sell a subsidiary, Oracle does not automatically “novate” (transfer) the licenses to the new owner. Standard Oracle terms mandate that the divested entity can continue using Oracle programs for only a short transition period (often 90 days) under the seller’s license agreement, after which the divested entity must purchase its licenses. In other words, unless the licenses were originally contracted in the name of that entity, they cannot move over permanently. After the grace period, if the new company hasn’t made arrangements, it would be using Oracle software without a valid license.
• Acquisition (Merger) Policy: If you acquire a company, that acquired entity and its users are not entitled to use your Oracle licenses until Oracle approves and your agreements are updated. Oracle expects the acquiring company to formally add the new subsidiary or business to the list of entities under its Oracle agreements. This typically involves contacting Oracle to amend the contract. During the interim, the acquired company should ideally continue using its own pre-existing Oracle licenses (if any) until consolidation is addressed. If the acquired company had its own Oracle licenses and support contracts, those remain in effect. Still, they might only cover that entity’s prior use and not use by the new parent or other affiliates.
• Geographic and Usage Restrictions: Some Oracle licenses are tied to specific regions or use cases. For example, a license might be for “North America only” usage. If a merger extends operations globally, those licenses might not cover new geographies, requiring contract changes. Similarly, if licenses were based on metrics like number of employees, revenue, or other business metrics, a merger will change those metrics (often upward) and potentially require a license expansion.

Why this matters: Oracle’s policies mean that after an M&A event, you can’t assume the new combined entity or a separate entity can freely use all software. Even if, technically, all the systems are under common IT control post-merger, the legal right to use Oracle programs is defined by the contracts. Violating those terms (even inadvertently) can leave the company out of compliance.

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. If Company A deploys its Oracle licenses across Company B’s infrastructure without contract updates, those deployments could be deemed unlicensed. Conversely, if Company B was using Oracle software, those licenses were only for Company B’s use; Company A’s broader organization can’t start using B’s licenses without Oracle’s consent. In a divestiture scenario, 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 using Company A’s licenses and acquire its own.

Understanding these ground rules is the first step in planning an M&A or divestiture involving Oracle assets. Next, we’ll look at common contractual pitfalls that can complicate matters.

Common Contractual Restrictions and Pitfalls

Oracle contracts contain several restrictions that can trip up companies during M&A. Failing to spot these in advance can lead to expensive consequences. Below are common pitfalls and clauses to be aware of:

• Non-Transferability Clauses: Almost all Oracle license agreements explicitly state that licenses are non-transferable. You cannot transfer the license to another legal entity or “assign” the contract without Oracle’s approval. If an unapproved transfer occurs (for example, merging entities start sharing licenses without formal consent), it is considered a contract breach. The pitfall here is assuming that a merger is “internal” and doesn’t count as a transfer. In contrast, Oracle often does treat it as a transfer if the entities weren’t originally included in the contract.
• “Full Repurchase” Liability: Because of non-transferability, a company that wants to use Oracle software post-merger may effectively have to repurchase licenses 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. This can feel like being forced to buy the software twice. In practical terms, if you can’t transfer a license, the only legal remedy is to buy a new license for the new entity or additional usage. For example, a divested unit that still needs an Oracle Database must budget to buy its own Oracle DB licenses at current prices (and possibly at worse discount rates). Oracle’s contracts don’t obligate it to honor a new entity’s original pricing or discounts. Non-compliance could result in having to pay list price plus back support for licenses you already technically owned, simply because they weren’t transferable. This is why careful planning is crucial – to avoid redundant spending.
• Assignment and Change of Control Conditions: Some Oracle agreements contain a “change of control” or assignment clause that might allow transfer if specific conditions are met. For instance, Oracle might allow an assignment of licenses to a successor company in the event of a merger of the licensee itself (where another company essentially absorbs the original customer). However, even in these cases, the contract typically requires notifying Oracle and sometimes Oracle’s consent. A common restriction is that the new entity cannot be a competitor of Oracle or that the assignment cannot expand the usage beyond what was originally licensed. Pitfall: Companies sometimes overlook the need to formally notify Oracle of a change of control within the timeframe specified in the contract, risking non-compliance. Always check if your contract has an assignment clause and follow its requirements strictly.
• Contractual “Full Use” vs “Limited Use” Licenses: Be aware if any licenses are limited to a particular subsidiary or purpose. Oracle sometimes sells limited-use licenses (e.g., licenses tied to a specific application or demo licenses). If those exist, using them outside their scope post-merger (like a license only for Subsidiary X now being used by the merged company) would violate the terms. Similarly, licenses obtained through special programs or bundles (like an ISV partner arrangement) might not be transferable to a new parent company in an acquisition.
• Legacy Agreements & Inconsistent Terms: If the 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. Or they might have different metrics (one license is by processor, the other by Named User Plus). These inconsistencies can create gray areas post-merger. Pitfall: Not reconciling these differences can lead to unintentional over-deployment. For instance, Company A’s contract allowed usage by any global affiliate, but Company B’s did not; if you assume Company B’s licenses can similarly be used everywhere, you could be in breach. To avoid confusion, it’s important to align on a single set of terms going forward (through contract consolidation or renegotiation).
• “Full Use” of Acquired Company’s Licenses by Acquirer: A common misunderstanding is thinking if you buy a company, you automatically “inherit” their licenses to use as you please. In reality, you inherit the contract obligations as well. The acquired company’s licenses usually remain restricted to that entity’s use (and its majority-owned subsidiaries, if any, under its contract). The acquiring company (parent) is not automatically an authorized user of those licenses just by owning the company. Unless Oracle consents, you cannot deploy software licensed to Company B for Company A’s broader operations. The acquired licenses may become shelfware if you consolidate systems unless Oracle agrees to repurpose them in a unified contract. This is a pitfall where companies think they have more licenses available than they legally do.
• Support and Maintenance Fees Surprises: Oracle’s support fees (typically ~22% of license cost annually) follow the licenses. The new company might have to start a new support contract at potentially higher rates if licenses are not transferable. Another scenario is if you combine two support contracts, Oracle might reprice the support on a merged contract to align with current pricing or remove any grandfathered discounts. There is a risk of support costs increasing after a merger if not carefully negotiated. Conversely, in a divestiture, if some licenses are left unused by the parent after carving out a business, the parent might want to drop those licenses to save support costs – but Oracle’s policies may not allow dropping support easily (they often require keeping support on all licenses you still use, and terminating licenses can have restrictions).
• ULA (Unlimited License Agreement) Pitfalls: If your company operates under an Oracle ULA, special conditions apply (we discuss ULA scenarios later). However, a ULA usually has strict rules about acquisitions and divestitures: small acquisitions may be allowed to join the ULA, but larger ones might not, and any divested entity typically loses the unlimited usage rights after a short grace period. If not handled, a ULA can instantly become a compliance headache if an entity isn’t included.

In summary, the fine print matters immensely. License agreements should be reviewed for Customer Definition, Assignment, Merger, or Divestiture clauses to understand what is allowed. Missing a single notification or assuming a right not explicitly granted can trigger a compliance failure.

Costly Consequence Example: A large enterprise learned during post-merger integration that the licenses of its acquired company could not be transferred. The new, combined IT environment needed Oracle Database and Middleware licenses for 20 additional processors that were previously licensed under the acquired firm’s contracts. Oracle would not simply “move” those licenses over, so the acquirer had to purchase 20 new processor licenses for its environment. With Oracle Database Enterprise Edition list price around $47,500 per processor, that’s roughly $950,000 in license fees (plus about $209,000 yearly in support). This unbudgeted spend could have been anticipated and perhaps mitigated with early contract negotiations or by structuring the deal differently. It illustrates how overlooking transfer restrictions can hit the bottom line.

SAM managers can take preventative steps by understanding these pitfalls before and during a merger or divestiture. Next, let’s look at what Oracle typically does when these corporate changes occur—knowing Oracle’s likely response will help you prepare.

Oracle’s Typical Response During Mergers & Divestitures

Oracle often takes action when a merger or divestiture is announced or completed. It is vested in these events because they often lead to upsell opportunities or reveal compliance gaps.

Here’s what you can usually expect from Oracle during such transitions:

• Increased Audit Attention: M&A activity is one of the top triggers for an Oracle license audit or review. Oracle’s License Management Services (LMS) – now often called GLAS (Global Licensing and Advisory Services) – keeps an eye on news of acquisitions and corporate changes. It’s common for Oracle to initiate a “license review” shortly after a major acquisition is public or after a company informs Oracle of a merger per contract requirements. Oracle will seek to ensure the new entity’s usage aligns with the pre-existing agreements. They know that companies might consolidate systems or inadvertently extend software to new users during post-merger integration, which is fertile ground for compliance issues. Put plainly: Oracle frequently audits newly merged companies. Industry observers have noted that Oracle audits tend to be “particularly rigorous” after mergers, aiming to uncover discrepancies between what was licensed and the new reality.
• Audit Scope Across All Products: Oracle’s response isn’t limited to databases. If an audit or review is triggered, it will likely cover all Oracle products in use – databases, middleware (like WebLogic or Oracle Fusion Middleware), enterprise applications (E-Business Suite, PeopleSoft, Hyperion, etc.), and even Oracle Java or Cloud services. This comprehensive approach can catch organizations off guard. For example, you might be focused on database licenses in a merger. Still, Oracle’s team may simultaneously check if the combined entity’s use of Oracle WebLogic Server exceeds entitlements or if more employees use Oracle’s HR software than are licensed. Be prepared for a full spectrum review.
• Questions About Customer Definition: Oracle account reps or auditors will pay close attention to the customer definition clauses in your contracts. Suppose Company B (acquired) was not listed as an authorized user under Company A’s contract. In that case, Oracle will flag any use of Company A’s licenses by Company B’s resources as non-compliant. They may insist that until contracts are updated, those uses are “unlicensed deployments.” On the flip side, if Company B had a separate contract, Oracle would question whether Company A’s folks now access software under Company B’s licenses (which they likely shouldn’t). Oracle may push for consolidation under one contract, usually in a way that benefits Oracle (like selling more licenses or migrating to a newer agreement).
• Immediate Sales Pressure: Often, Oracle’s approach to a merger announcement is to send in the sales team. You might receive offers for an Unlimited License Agreement (ULA) or other enterprise deals to “simplify” the licensing across the new organization. While a ULA or bulk deal can be helpful in some cases, remember it’s being offered because Oracle sees an opportunity to lock in a large sale. They may position it as a solution to avoid compliance issues. This can be beneficial if you truly need more licenses, but it can also be a costly commitment if your growth is uncertain. Always evaluate such proposals carefully (ideally with third-party advice) rather than jumping in out of fear of compliance.
• Enforcement of Deadlines for Divestitures: In a divestiture scenario, Oracle will likely remind the parent company of the contractual timeline. If your contract says the spun-off entity can use the software for 90 days, expect Oracle to reach out around that timeframe to ensure that either the usage has ceased or the new entity has acquired licenses. Sometimes, Oracle will engage directly with the new standalone companies to convert them into direct customers. Typical response: Oracle might offer the divested entity a new license contract to purchase whatever they need, possibly at less favorable terms than the original. Oracle knows the new company has little leverage if it urgently requires the continuity of Oracle’s systems post-separation.
• Consent Process (or Lack Thereof): If you proactively request Oracle’s consent to transfer licenses or allow new entities’ usage, Oracle’s response can vary. Often, Oracle will evaluate how it can benefit. For example, they might consent to an assignment of licenses if you bring the support up to current pricing or if you buy some expansion. Oracle might also flatly refuse a transfer if the contract doesn’t compel them, simply to force a purchase. In some cases, Oracle has provided a “license transfer letter” (a formal document granting permission for a specific transfer or use by a new entity), but this usually comes with conditions. Always get any special permissions in writing from Oracle’s contracts/legal department – verbal assurances from a sales rep are insufficient.
• Suspension of Support (Potential): While not common, there have been scenarios where if a customer does not clarify who is entitled to support after a merger, Oracle could raise issues when a support request comes from an entity not on record. For example, if a newly acquired subsidiary calls Oracle Support for help, Oracle might check if that subsidiary is covered under the support agreement. If not, they might deny service until the paperwork is sorted. It’s rare for Oracle to suspend support outright during an ongoing audit or negotiation (especially if support is paid up), but delays and complications can occur. It underscores the importance of updating Oracle on legal entity changes promptly.

Oracle’s overall stance can be summarized as “trust but verify – and monetize.” They will verify compliance stringently and use the situation to potentially monetize any shortfall. As a customer, you should anticipate this stance and not assume leniency. Even if you’ve had a friendly relationship with Oracle, when an acquisition is in play, different teams (like LMS/audit) might get involved, and they will stick closely to contractual terms.

Next, we’ll discuss real-world examples and cases illustrating how Oracle licenses have posed challenges during M&A and the resulting financial impacts. Seeing how others fared can help underline why careful license management is critical.

Real-World Examples of Oracle Licensing Challenges in M&A

Many companies have learned the hard way that Oracle licensing can become a flashpoint during M&A. Here are a few notable examples and scenarios:

• Mars, Inc. vs Oracle (2015): One high-profile case involved candy manufacturer Mars, Inc. following its acquisition of Wrigley. Oracle initiated a license audit/review of Mars 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 took a very aggressive stance, allegedly threatening to terminate Mars’s licenses 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, but it highlighted how an Oracle audit can become a serious conflict. Impact: While financial details weren’t public, the case shows that even a large, sophisticated customer like Mars had to expend significant resources (legal and otherwise) to deal with Oracle’s licensing claims post-acquisition. The potential risk was reported to be material to Mars’s business. This example sends a clear message: don’t underestimate Oracle’s willingness to pursue revenue through compliance enforcement in an M&A scenario.
• Multi-Acquisition Manufacturer Case: A global manufacturing company (documented in a Palisade Compliance case study) that pursued frequent acquisitions was continuously challenged by Oracle licensing. Each acquired business came with its own Oracle footprint, and the parent company allowed them to continue running their existing Oracle-based ERP systems to avoid disrupting operations. However, this resulted in a complex web of Oracle contracts and deployments that the central IT/SAM team had to manage. Oracle had audited the parent in the past, so they were very cautious, but “surprises” still occurred when an acquired company had unexpected Oracle usage or lacked certain licenses. The company ended up in almost perpetual negotiations with Oracle to true up licenses or to fold the new acquisitions into their Oracle agreement. Impact: While the case study didn’t disclose dollar figures, it indicated the company was juggling multiple Oracle compliance engagements at any time. This suggests significant effort and potential financial exposure with each acquisition. The lesson here was the importance of a strong internal process to assess Oracle licensing before an acquisition is finalized so that the parent could demand the target address any shortfall or include it in the deal valuation.
• Divestiture Gone Wrong (Generic Scenario): Consider a scenario where a large enterprise spins off a division that heavily relies on Oracle technology (for instance, an e-commerce subsidiary using Oracle Database and WebLogic). The parent company did not secure any agreement with Oracle for transfer, assuming the division could “use what it has always used.” After the spin-off, that new company continued operating the same Oracle-based systems. After noticing the change, Oracle informs them that the parent’s license agreement no longer covers them. The new company had 500 employees using an Oracle E-Business Suite module and several Oracle databases. Practically overnight, that new firm is told it has no valid license for those systems and must license them anew. Suppose 500 users of EBS (say ERP modules) need licensing at, for example, ~$800 per user (just as a ballpark) and databases for their servers at a few hundred thousand dollars. In that case, the new entity faces a multi-million dollar spend it hadn’t budgeted. Oracle could terminate support or seek legal remedies if it fails to comply. This hypothetical is based on real patterns observed in the industry — divested units often scramble to strike a deal with Oracle under duress. Impact: Either the spin-off pays a hefty sum for new licenses (affecting its initial financial health), or in some cases, the parent might have to step in and cover some costs if it had contractual obligations in the separation agreement to provide licensed software for a transition period. It’s a lose-lose if not planned: the new company either pays big or risks operating illegally.
• Oracle ULA Trap during M&A: Company X entered an Oracle Unlimited License Agreement (ULA) to cover 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 (likely seeing an opportunity to charge more due to the increased scope). When the ULA ended and it came time for certification, Company X could only certify licenses for its original footprint — the acquired company’s deployments were outside the ULA. Suddenly, those deployments (databases, etc., running at the acquired sites) were not licensed under the ULA and must be paid for separately. This turned a “unlimited” deal into a limited one, creating an unexpected compliance bill in the millions. Impact: The company had to negotiate a separate purchase or another ULA extension costing millions to cover the gap. The real-world takeaway: ULAs can be dangerous in M&A if you don’t negotiate terms for acquisitions and divestitures up front (Oracle often provides a 6-month grace for divested businesses and might allow small acquisitions up to a threshold, but anything beyond that can blow up your compliance position).

These examples illustrate a range of outcomes – from legal battles to financial hits to ongoing operational headaches. The common thread is that proactive management could have lessened the pain. In Mars’s case, they took a strong stance to defend against Oracle’s claims, but smaller companies might not have that leverage. The manufacturer case shows the importance of integrating license management into the M&A playbook for every deal. The divestiture scenario reinforces that you must involve Oracle (or have a clear plan to replace Oracle systems) before a spin-off is cut loose.

Next, we will transition from problems to best practices. What steps can you take before, during, and after a merger or divestiture to handle Oracle licensing smoothly? This includes diligence tips, negotiation strategies, and combining or splitting contracts with minimal risk.

Best Practices for Oracle Licensing Through the M&A Lifecycle

Managing Oracle licenses in a merger, acquisition, or divestiture requires a structured approach. Below are best practices divided by phase: pre-deal diligence, mid-deal negotiation (including engaging Oracle), and post-deal integration or separation.

Following these can significantly reduce risk:

Pre-Deal Diligence and Planning

1. Inventory All Oracle Assets: Before an acquisition or divestiture is finalized, thoroughly inventory all Oracle products and deployments in scope. This means identifying every Oracle database, application server, enterprise application, Java installation, etc., in the environment of the company you are acquiring or the business unit you are selling. Also, inventory your environment if merging – understand the full picture of the combined usage. This inventory should capture details like version, edition (Standard vs Enterprise for database, for example), number of users, number of processors/cores, and any options or packs in use (Oracle Database options and management packs are often licensed separately and commonly over-deployed unknowingly).
2. Gather and Review All Oracle Contracts: Obtain the Oracle license agreements, ordering documents, ULAs, support renewal documents – every contract the target company (or affected division) has with Oracle. Similarly, have your contracts handy. Review these contracts in detail, focusing on clauses about License Ownership/Customer Definition, Assignment, Acquisition, Divestiture, and Territory or Use Restrictions. Look for language like “The customer may not assign this agreement without Oracle’s consent…” or specific instructions for what happens if the customer acquires a company or divests one. Pay attention to who is named as the licensee (sometimes, licenses are held by a specific subsidiary). If the contract has an attached list of “Affiliates” or “Subsidiaries” allowed to use the software, note whether that list will need updating. Doing this homework will tell you what flexibility or hurdles exist.
3. Identify Compliance Gaps or Surpluses: Spot potential gaps with the inventory and contract in hand. For example, does the target use more processor cores on Oracle DB than they have licensed? Are they using Oracle in ways not covered (maybe using virtualization like VMware in a way that Oracle doesn’t permit under their contract, a common audit issue)? On the flip side, maybe the target has licenses they’re not fully using (surplus) – which could potentially cover some of your combined needs if transferable. The goal is to develop a license compliance report for due diligence. If you find the target is under-licensed or mis-licensed, that liability should be factored into the deal. If selling a unit, identify what Oracle software they rely on so you can plan how they will continue to operate (will they need a license grant or new purchase?).
4. Assess Value and Cost Implications: Quantify what it would cost to address any issues. If the target company would need $2 million in Oracle licenses to become compliant post-acquisition, you want to know before you finalize the purchase price. Buyers can negotiate such costs off the price or require the seller to remediate them before closing. Sellers should know if Oracle licenses will be an issue for the unit they are divesting – perhaps they need to budget for transitional licenses or inform the buyer to avoid later disputes. This step turns license info into actionable financial terms, which is what executives understand. It’s analogous to discovering a legal liability or debt – it affects the deal’s valuation.
5. Consult Experts Early: Involve your SAM team or a third-party Oracle licensing expert early in the M&A planning. Oracle’s licensing rules are intricate (full of product-specific gotchas and evolving policies), so having someone who knows the terrain is invaluable. They can help analyze the contracts, point out hidden issues (like Java licensing changes or specific rules for certain products), and strategize the best approach to Oracle. This could be an internal licensing specialist, external consultant, or law firm experienced in Oracle contracts. The cost of expert advice is minor compared to a licensing mistake in a merger.
6. Formulate a License Transition Plan: Before the deal closes, plan how to integrate or separate Oracle usage. For an acquisition, decide: Will the acquired company continue to operate separately (with their existing licenses) for a while, or will you immediately integrate systems? If integration is immediate, you’ll need to fast-track contract updates with Oracle. If separate, you might keep two sets of contracts for some time (which is okay, be mindful not to intermingle usage). For a divestiture, plan how the new entity will get its Oracle software: Will the parent provide services for a period (via a Transition Services Agreement), and will Oracle allow that? Or will the new company have to set up its systems on Day 1 with new licenses? Map this out and include it as part of the overall IT transition planning.

Engaging Oracle and Negotiating During the Deal

1. Engage Oracle – Carefully and Early: It may sound tempting to avoid alerting Oracle, but ultimately, you will likely need to engage with Oracle to make necessary contract changes or get approvals. The timing and manner are important. Ideally, once you have your internal picture and strategy (from the diligence phase), you or your legal team should notify Oracle of the upcoming change (if contractually required) and request discussions on handling the licenses. For example, if you’re the buyer, inform Oracle that you are acquiring Company B and ask about adding Company B to your agreements or transferring Company B’s Oracle agreements to your control. If you are the one divesting, notify Oracle that Subsidiary X will be divested as of a date and ask for their procedure for that scenario. It’s usually better that Oracle hears it from you than from the news or by surprise audit – demonstrating transparency can set a more cooperative tone. That said, do not reveal more than necessary. Frame it as “We want to remain compliant and work with you,” but avoid volunteering information about potential overuse or other issues until you understand Oracle’s stance or have expert counsel on the call.
2. Negotiate Transition Terms (Carve-Outs and Carve-Ins): A merger often requires negotiating how the acquired licenses will be handled (carve-in), and a divestiture requires negotiating carve-out terms. Some key negotiables:
   • For Acquisitions: Ask Oracle to recognize the acquired entity’s licenses and consolidate them into your agreement. Sometimes, Oracle will allow a form of “license assignment” as part of the merger. They might require you to sign an assumption agreement, issue new license keys under your name, and usually continue support without lapse. If the acquired company had a lower discount on their support, Oracle might try to align it with your pricing (could increase cost) or vice versa. Be prepared to push for maintaining any favorable terms the acquired company had (e.g., if they had a ULA that grants them broad usage, try to keep that in effect for its term). You can also negotiate to roll in the acquired company’s licenses into a single support stream – Oracle often does this by adding its support fees to yours (maintaining Oracle’s revenue). If additional licenses are needed due to growth, this is the time to negotiate a bulk purchase or an extension rather than waiting for an audit later. Essentially, leverage the situation to get a better deal (e.g., “We just grew in Oracle footprint, let’s negotiate a volume discount or an enterprise agreement to cover everything”).
   • For Divestitures: Negotiate a carve-out agreement for the divested entity. This could include an extended grace period beyond the standard 90 days – Oracle might grant 6 months or more, especially if the divestiture is complex and the new entity needs time to establish IT independence. If the divested business continues using Oracle, negotiate a deal for them to purchase licenses, effective at the time of separation. Sometimes, the parent company can pre-pay or arrange licenses on behalf of the newco as part of the deal (this can even be written into the separation agreement between buyer and seller: e.g., parent will ensure the new company has X Oracle licenses for Y users at transfer). Oracle might offer the newco a similar discount level to the parent’s if negotiated as part of the split. If not, the newco might face list prices. So the parent (as the existing Oracle customer) has some leverage to advocate for the newco before they become a separate, unknown customer to Oracle. The parent and Newco should coordinate this negotiation with Oracle to sort out the licenses with minimal service disruption. Additionally, if a Transition Services Agreement (TSA) is in place where the parent will continue to run systems for the new company for X months, inform Oracle of this arrangement and get their written consent that it’s permissible under the parent’s licenses. Oracle may treat the new company as a third party, which normally is disallowed to use your licenses, but they might permit it for a limited time under a TSA if asked.
3. Consolidation vs. New Contracts: Decide if you will combine or keep them separate. In a merger, you might end up with multiple Oracle agreements (yours and the acquired company’s). Oracle often prefers to merge them into one umbrella agreement for simplicity (and sales opportunity). This can be beneficial, but scrutinize the terms. The acquired company’s older contracts might have clauses you like (or dislike). For example, older contracts might have perpetual legacy rights that newer Oracle agreements don’t include. If you consolidate into a new agreement, ensure you aren’t giving up any advantageous terms. If in doubt, you can run both contracts in parallel: the acquired entity continues to use software under its existing contract, and your original company under yours, with no cross-use, until you have time to negotiate a unified deal properly. There’s no rush to combine if it could lose value – just ensure you keep usage separated operationally. If you do consolidate, negotiate it as part of a broader settlement to cover any shortfalls: e.g., you might say “Oracle, we’ll sign a new Master Agreement that covers both companies and purchase these additional licenses to true up, but in return we want a discount or a cap on support increases, etc.” Use the opportunity to improve terms where possible (like obtaining more flexible global usage rights or adding the new entities to the contract at no extra fee if usage isn’t increasing).
4. Put Everything in Writing: Get formal documentation when you reach any understanding with Oracle – an allowance for a grace period, a list of licenses that will transfer, or a new discount. This could be an amendment to the contract, a new ordering document, or at minimum a written email from Oracle’s contract department spelling out the agreed terms, to be followed by official paperwork. Do not rely on an Oracle sales representative’s verbal assurances that “it will be fine” or “we will work with you after the deal.” When push comes to shove, only the written contract terms count. A best practice is to have Oracle issue a “Consent Letter” or amendment for any license transfer or continued use permissions. For example, suppose Oracle agrees that a divested business can use the parent’s licenses for 6 months. In that case, the letter should explicitly state that you have proof of permission if an audit team changes personnel.
5. Leverage Negotiation Timing: You often have leverage during an M&A because Oracle knows you could choose to migrate away from Oracle products during a reorganization (in reality, that’s hard, but it’s an implied threat). If Oracle is too inflexible, some companies do consider accelerating a move to alternate systems as part of the integration (for example, migrating a newly acquired unit’s databases to open source rather than paying Oracle again). Oracle’s sales team, wanting to secure their revenue, might be more willing to negotiate better pricing or terms during M&A than later. Use that moment to negotiate multi-year caps on support increases, get cloud trial credits thrown in, or do whatever might align with your IT strategy. Once the deal dust settles, Oracle might be less motivated to give concessions. So, engage with a clear ask list.
6. Coordinate with Broader IT Planning: M&A is often when companies consider rationalizing applications (e.g., having two CRM systems and deciding to keep one). If you plan to retire some Oracle software as part of integration, factor that into negotiations. For instance, if Company B had an Oracle-based system you intend to decommission in a year, you might not want to pay full price to license it anew. Instead, negotiate a short-term extension or even a term license just for that interim period. If it means a sale, Oracle can be flexible in selling licenses (they have options for one-year licenses or cloud subscriptions). Perhaps the newco in a divestiture only needs Oracle for a transition year – maybe Oracle will sell them a 1-year term license instead of a perpetual license. These options should be explored.

Post-Deal Integration and License Reconciliation

After the merger or separation is executed, the work isn’t over. Now, it’s about operationalizing and monitoring the new license situation:

1. Execute Contract Updates: Ensure all the paperwork negotiated with Oracle is fully executed. Update your internal records: for a merger, add the newly acquired licenses to your license inventory system and note any new contract numbers or metrics. For a split, adjust your records to remove what the divested unit is now independently responsible for. Communicate to your IT teams what can and cannot be done under the new arrangements (e.g., “Division X is now completely separate – do not deploy our Oracle software in their environment and vice versa”).
2. Combine Support Contracts (if intended): Work with Oracle’s support renewals team to consolidate support contracts if that was part of the plan. Watch out for the first support renewal post-merger – double-check the quantities and fees. Oracle may merge the support streams; sometimes, errors happen (licenses counted twice, etc.). Also, if you dropped any Oracle products due to redundancy, ensure those were properly terminated so you’re not billed for support on them next cycle (Oracle requires 30-60 days’ notice before support renewal if you’re not renewing specific licenses).
3. Deploy Licenses Strategically: With the new combined pool of licenses (if you merged entitlements), allocate them most efficiently. Perhaps the acquired company’s licenses can cover usage in one region while your original licenses cover another to maximize coverage under each contract’s terms. If you negotiated any new unlimited or site licenses, start utilizing them as needed,but keep track of usage for later certification if required.
4. Monitor Usage Growth: Post-merger, companies often go through a growth or change spurt (new projects, expansions, or downsizing redundant systems). Continuously monitor Oracle software usage across the now-unified environment. User counts may swell when integrating systems (for instance, hooking more users into a central Oracle ERP). Make sure you adjust licenses accordingly before Oracle finds it in an audit. On the flip side, if you decommission duplicate systems (say both companies had a data warehouse and you retired one), track those license savings – you might reallocate those licenses elsewhere or potentially use that to negotiate support fee reductions (though Oracle usually resists reducing support, you could try to drop licenses you truly no longer use).
5. License Harmonization Project: In some cases, initiating an internal project to harmonize all licensing after a big merger is wise. This means simplifying and standardizing metrics if possible. For example, suppose one part of the company licenses Oracle Database by Named User Plus and another by Processor. In that case, you might want to standardize on one approach in the future to ease management. It could involve converting some licenses (Oracle allows converts in certain directions, from processor to NUP or vice versa, typically requiring additional purchases to meet minimums). Also, rationalize edition differences – if one entity used Standard Edition and another Enterprise Edition, decide what the combined strategy is (maybe you keep SE for smaller workloads to save cost). Harmonization ties into optimizing costs – it might reveal that you have excess licenses of one type that you could terminate (if truly not needed post-integration).
6. Ongoing Audit Readiness: Given that M&A is a high-risk audit period, maintain an audit-ready posture. Document all communications with Oracle (keep that consent letter safe!), and have your updated entitlements and usage evidence organized. It’s common for Oracle to come back 6-12 months after a merger with another audit to verify everything. If you’ve done your homework and negotiations, you should be able to show compliance. Still, run internal audits periodically. Verify user counts in applications, scan for any rogue Oracle installations that slipped through in the chaos of integration, and ensure any Oracle Cloud subscriptions are being used within their limits.
7. Educate Stakeholders: After a merger or split, educate all relevant stakeholders about the new licensing boundaries. This includes IT managers, procurement, project managers, and the acquired employees, if applicable. They should know, for instance, that “we can’t just spin up a new Oracle database on that acquired unit’s servers without checking with SAM,” or “the new spin-off company will only have access to our systems until date X, after which things change.” Clear communication prevents well-meaning IT staff from unintentionally breaking license rules because they assume everything is unified.
8. Combine or Split Data Centers Wisely: Often, after M&A, there’s data center consolidation. Be cautious with Oracle in virtualized or clustered environments. If you plan to move Oracle workloads from a separate company into a shared VMware cluster, ensure you have licenses for the entire cluster if required. Many companies have been caught up in Oracle’s stance on VMware (treating entire vSphere clusters or even data centers as licensable if Oracle is present). Align your architecture plans with your license entitlements to avoid inadvertently creating an exposure.

Following these best practices creates a controlled path through what could otherwise be a licensing minefield.

In the next sections, we’ll examine specific scenarios for combining and splitting Oracle contracts, special considerations for different Oracle product lines, and any regional differences in approach. These will add more context to the strategies discussed.

Combining Oracle Contracts and Licenses Post-Merger

When two companies become one (via merger or acquisition), they may end up with multiple Oracle license agreements.

Deciding how to combine these, if at all, is a strategic step:

• Keep Separate vs. Merge Agreements: Initially, it’s perfectly acceptable to keep the legacy agreements separate. Company B (now a subsidiary of A) can continue using Oracle under its original contract (with Company B as the licensee) while Company A uses its own. This avoids any immediate legal gaps as long as each entity sticks to its licenses. Over time, however, running multiple contracts can be cumbersome. It may make sense to merge them into one “umbrella” Oracle agreement covering the whole new entity. Oracle can typically consolidate contracts by having you sign a new master agreement that supersedes or absorbs the old ones. The benefit of merging is simplicity: one set of terms, one support bill, and the ability to use licenses interchangeably across the organization (assuming the new agreement’s customer definition covers all entities). The downside can be cost – Oracle might use the consolidation to eliminate duplicate discounts or enforce current pricing, possibly raising support costs. Tip: Analyze the financial impact of combining support streams. If, for example, Company B enjoyed a deep discount on some licenses’ support, try to preserve that in the new deal or at least be aware if Oracle plans to “reset” it.
• Unified Customer Definition: If you merge contracts, ensure the new contract’s customer definition clause explicitly names all major entities or uses a broad definition (“ABC Corp and its majority-owned subsidiaries worldwide,” for instance). Push for a future-proof definition – so you don’t have to amend it again for small org changes. Also include any key geographies (if previous contracts had specific territory restrictions, negotiate for a unified global usage right if possible).
• License Pooling: After merging, you might have a larger license pool for each Oracle product. Determine if you can pool them. For example, Company A had 50 Processor licenses of Oracle DB, Company B had 30; combined 80. If all 80 can be used anywhere in the new enterprise. But ensure there’s no contractual barrier (like one set was limited to a certain subsidiary or environment). Post-consolidation, Oracle should reissue or confirm entitlements to clarify that you have X total licenses. Track these carefully in your records.
• Eliminate Redundancies: Merging companies might have overlapping Oracle products. Perhaps both had licenses for the same module or separate ULAs. You might not need all of them going forward. Work with Oracle to see if you can retire some licenses to save costs. Oracle normally doesn’t give refunds for licenses. Still, you might be able to drop unused support or negotiate a give-back of some licenses in exchange for credit toward other needed licenses (this is sometimes possible in a big deal if positioned as a swap or trade-up). For instance, if each company has a license for a legacy Oracle tool and only keeps one tool, you may terminate the duplicates. If direct termination isn’t allowed, another approach is to keep them but not renew support on the redundant ones (be careful: if they’re bundled in a support contract with others, Oracle’s “matching service levels” clause might force you to keep support on all or none for that license set – which is why negotiation for exception may be needed).
• Support Co-termination: If you consolidate support, you’ll want to align renewal dates. Company B’s support might often renew in March, and Company A’s in September. Oracle can make a one-time prorated adjustment so that everything renews on the same date. This simplifies future budgeting and renewal management. Just verify that the prorated charges are correct and that you aren’t double-charged.
• Harmonize Metrics and Terms: We touched on this earlier – if merging contracts reveals different licensing metrics for the same product, decide on one metric going forward. It might involve converting one type of license to another. Oracle has conversion formulas (e.g., Named User Plus licenses can be converted to an equivalent in Processor licenses if needed, though usually requiring a certain minimum). These conversions usually must be done through Oracle sales (you can’t just decide to count them differently). If it makes administration easier and covers your usage better, negotiating a conversion during consolidation might be wise. Aim for metrics that suit how you operate post-merger. If you suddenly have many more users, perhaps moving to a processor metric is easier than tracking each user.
• Beware of Contract Sunsetting: If one of the merged companies had an old Oracle Unlimited Deployment Agreement or some grandfathered terms, ensure that merging contracts don’t unintentionally forfeit those. For example, Oracle had older agreements with more favorable virtualization terms or usage rights. If you sign a completely new agreement, Oracle’s newer standard terms (which could be more restrictive) sometimes apply. To avoid losing an advantage, explicitly incorporate any needed legacy terms into the new agreement as negotiated exceptions. This is an area where involving legal counsel is important – to ensure the continuity of rights.
• Example – Combining Contracts: Company A and B merge. Company A has an Oracle agreement that covers “Company A and subsidiaries” with 100 Oracle DB licenses. Company B has its own Oracle agreement with 50 DB licenses. After the merger, they operated separately for a year, then decided to consolidate. Oracle drafts a new single “AB Corp” contract listing 150 Oracle DB licenses. They co-terminate support to one date. However, Oracle also notes that Company B’s licenses were previously limited to the EMEA region; AB Corp negotiates for those to be global in the new contract. Oracle agrees but increases the support slightly for that expanded right. AB Corp accepts it since it eases usage. Now, AB Corp can use all 150 licenses anywhere needed. They also noticed overlapping licenses for Oracle WebLogic – one set of 100 users and another set of 100 users – but they only need 150 after combining systems. Oracle, in good faith (and perhaps because AB Corp made a larger purchase of cloud credits simultaneously), allows them to terminate 50 user licenses from support, saving cost, as part of the negotiation. This outcome requires proactive negotiation but can streamline and even save money in the long term.

In summary, combining contracts is about creating one coherent licensing framework for the new company. It should simplify compliance, but be watchful of any cost increases or loss of legacy benefits. Properly done, it sets you up with a clean slate to manage Oracle licensing in the combined entity in the future.

Splitting Oracle Contracts and Licenses in Divestitures

When a company splits off part of its business, handling Oracle licenses is equally, if not more, challenging. The goal is to ensure the separated entity can operate legally without the parent incurring violations.

Key steps and considerations:

• Determine License Ownership: First, determine which Oracle licenses, if any, were dedicated to the divested business. Suppose the divested unit was a separate subsidiary with its own Oracle licenses (e.g., Oracle agreement and customer support identifier). In that case, the situation is simpler: that subsidiary will take its contracts with it (though Oracle still should be formally notified that the subsidiary is no longer part of the parent’s org). In many cases, however, the divested unit used licenses owned by the parent. For example, the parent company’s Oracle ERP system served that division, or databases supporting that business were under the parent’s license pool. These are the cases that need attention.
• Option 1: Full Carve-Out Transfer (Rare): In some instances, Oracle might allow a transfer of certain licenses to the new entity. This is uncommon, but suppose the divested business is large and was the primary user of 100 Oracle database licenses out of the parent’s 300. The parent might not need those 100 anymore after the split. Oracle could agree (again, via a formal contract novation or assignment) to transfer those 100 licenses into the new company’s name. This would let the new company continue using them and relieve the parent of their support cost. However, Oracle usually has no obligation to do this and might prefer to sell new licenses to the newco instead. The negotiation might involve fees or the newco picking up support fees from day 1 if pursued. Also, Oracle will insist that partial transfers don’t leave the parent under-licensed for what it keeps. In practice, full transfers happen more often when it’s an internal reorganization (like spinning off a wholly-owned subsidiary as a new independent – Oracle might have pre-approved language for that in some customer agreements). Always ask, but don’t bank on it.
• Option 2: New License Purchase for Newco: The more typical scenario is that the new company must procure its own Oracle licenses. Ideally, coordinate this so that on Day 1 of the divestiture, they have what they need. The parent can facilitate negotiations as mentioned in earlier sections. Often, this results in the newco signing a fresh Oracle license agreement and buying whatever products it had been using under the parent. If budget or timing is an issue, the newco might prioritize what’s needed immediately versus later (e.g., maybe they only absolutely need licenses for the database and can avoid using a certain Oracle middleware by switching to an alternative temporarily). The parent should assist by providing data on the newco’s usage. Hence, the newco buys sufficient licenses (for example, “Your HR system had 1000 named users, so you’ll need 1000 HR module licenses for Oracle EBS on your contract”).
• Transition Services and Interim Use: In almost all divestitures, there is a transitional period where the separated business still relies on the parent’s IT systems (email, ERP, databases, etc.) until it stands up its own. This is typically governed by a Transition Services Agreement (TSA) between the two companies. From an Oracle standpoint, this means the parent’s Oracle licenses are temporarily being used to support a third-party (the newco) – which normally violates the license (since only the legal entities under the parent’s contract can use them). Oracle’s standard clause giving 90 days is essentially a built-in TSA allowance. If more than 90 days is needed, that’s where negotiation comes in. Best practice: explicitly include in the TSA that the newco’s use of parent’s Oracle software will end by X date, and try to get Oracle to approve that TSA period. Some Oracle agreements state that during a divestiture TSA, the parent must notify Oracle, and Oracle will give written permission for up to the agreed period. Ensure the responsibilities of those who contact Oracle are clear – sometimes the contract says the customer (parent) must notify us within a certain timeframe of divestiture. Do that promptly to avoid breach.
• Splitting Data and Instances: Often, splitting a business means splitting databases or making copies of systems. Be mindful that duplicating an Oracle database for the new company to take with it may require extra licensing. Example: a parent clones an Oracle database and gives it to the newco to run independently. That clone is a new deployment needing a licensed server and users. The newco should have licenses for that environment. During the transition, maybe it’s running on the parent’s infrastructure (under TSA), but when ported over, the newco’s licenses must kick in. Coordinate timing – ideally, the newco’s licenses become effective when running their instance.
• Support Contract Split: If a license transfer is allowed or the newco is taking over some licenses, you’ll need to split the support contract. Oracle can spin off a portion of a CSI (Customer Support Identifier) to a new one for the new customer. Ensure there’s no gap in support coverage – Oracle will often allow continuous support for those licenses under the new owner. Still, the new owner might have to immediately pay a prorated support fee from the date of transfer through the next renewal date. Work that out so that the newco isn’t caught without the ability to get Oracle Support. Also, if the parent paid support annually up front, reimbursement may be needed if part of the year is “used” by the newco. Sometimes, companies handle this among themselves, and Oracle just reallocates the funds accordingly.
• Communication with the New Entity: If you are the parent company’s SAM manager, ensure the spun-off company’s IT knows the exact situation. It’s in your interest because if they erroneously keep using your licenses, Oracle might come after you as the original licensee. Provide them with documentation on what was agreed – e.g., “We have arranged with Oracle that you can use these systems under our license until June 30. By July 1, you must have your licenses or shut down those systems.” It may feel tough, but it protects both parties. The newco should ideally hire or designate their own SAM/licensing manager immediately to handle the stand-up of their license environment.
• Case Study – Divestiture Example: A large bank sold off a regional business unit that used Oracle databases heavily. The parent’s contract had a 60-day divestiture clause. The new company, being smaller and without SAM experience, didn’t secure licenses in time and continued running the databases after day 60. Oracle conducted an audit on day 90 and found that the newco had no licenses, which was a clear violation. Oracle then returned to the parent (because the parent was originally the license’s signatory) and held them accountable. The parent had to pressure the buyer to quickly purchase licenses, and Oracle, seeing leverage, offered the newco only a list-price deal with no discounts. It strained the relationship between the parent and the buyer as well. Moral: Don’t let this happen – both sides should proactively handle license separation to avoid scrambling and finger-pointing.
• Future Relationship with Oracle: After a divestiture, the new company becomes an independent Oracle customer, and the parent’s scope with Oracle is reduced. It’s worth reviewing the parent’s contracts for any volume-based commitments. If, for instance, the parent had an enterprise agreement assuming a certain size, which is now smaller, you may need to renegotiate your support or ULA at the next renewal accordingly (though Oracle might not automatically reduce costs, you could argue for it if a big chunk of usage is left). The parent should also update Oracle on the change so its account records (like the list of subsidiaries) are corrected – this avoids confusion later.

In essence, splitting licenses requires a delicate handoff. It’s about ensuring continuity for the new entity without breaking the old contract’s rules. It often feels like a race against the clock (the contractual grace period), so early planning is your friend.

The smoother the licensing handoff, the less risk of post-divestiture audits or surprise bills.

Oracle Product Line Scenarios in M&A

Oracle’s broad portfolio – databases, middleware, business applications, Java, and cloud services – each with its licensing nuances. Let’s discuss considerations for major product categories during M&A or divestiture:

• Database and Middleware Products: Oracle’s technological backbone (Oracle Database, Oracle WebLogic Server, Oracle middleware like ODI, etc.). They are typically licensed per processor or per named user. During M&A: Check for usage of database options (like Partitioning, Advanced Security, etc.) because those often require extra licenses that the target might not have fully licensed. When combining two companies’ IT, watch out for an environment where databases might be consolidated onto bigger servers – license needs could jump (Oracle licenses by core multiplied by core factors). You may need more licenses if the acquired company runs databases on small servers and you move them to your large enterprise server or cloud. Also, check if both had different versions or editions; an upgrade or unification might inadvertently turn on features that require licenses (Oracle Database has features that auto-enable in Enterprise Edition that Standard Edition didn’t have, for example). During Divestiture: Ensure the departing side has an appropriately sized database environment – they might have to downsize or right-size to what they can afford to license. Also, database and middleware support is critical; make sure support contracts transfer or new support is acquired to make security patches and help available post-split.
• Oracle E-Business Suite (EBS) and Other Applications: Oracle EBS (and similarly PeopleSoft, JD Edwards, Siebel CRM, Hyperion, etc.) are enterprise applications often licensed by named user or by application module metrics (some modules use “number of employees”, “revenue amount,” or other metrics). During M&A: If both companies use Oracle applications (say both use EBS or one uses EBS and the other uses PeopleSoft), decide which to keep or whether to run them separately. Combining user bases on one system will likely require increasing the licensed number of users. For example, Company A had 500 HR module users; Company B had 300; if you move B’s users into A’s EBS instance, now 800 users need to be licensed. Also, metrics like “employee count” will rise – if an EBS module was licensed for a maximum of 1000 employees and the merged org has 1500, that’s an issue. Renegotiate those licenses to cover the new metrics. Sometimes Oracle sells application licenses as bundles or unlimited within an entity – make sure the entity definition aligns with the new company. Suppose you consolidate two different Oracle ERP systems. In that case, you might drop one – consider the license implications (maybe unused licenses from the retired system can be repurposed for something else within that company, or see if Oracle will allow a credit trade-in toward expanding the surviving system’s licenses). During Divestiture: If the divested unit relied on the parent’s Oracle EBS or other application, they will need their own. Setting up a new ERP is often not trivial; the newco might choose an Oracle Cloud SaaS (Oracle Fusion Cloud ERP) or another solution instead of replicating the old EBS on-premises. However, if they need Oracle EBS, they’ll have to license modules and users anew, possibly at a smaller scale. Also, consider the data – the newco might take a data export but not the application itself. During the TSA, the parent might continue running payroll or financials for the newco on the parent’s EBS for a few months. That must be stopped by the agreed date due to licensing. Oracle may offer the newco a rapid implementation deal on Oracle Cloud as an alternative; evaluate that technically and financially vs on-prem licenses.
• Oracle Java SE: Oracle’s Java (the Standard Edition JDK) has recently become a licensing topic. Oracle now charges for Java SE subscriptions (unless using specific free versions), typically based on the number of employees or desktop counts. During M&A: Consider Java usage – if the target company uses Oracle Java across their PCs or servers, you must ensure you’re properly licensed. The new Java SE subscription as of 2023 is licensed per total employee count (regardless of how many use Java). So if two companies merge, and Oracle’s Java license agreement covers 500 employees at one company and 300 at another, Oracle will likely expect the combined company to license Java for 800 employees (if Java is being used broadly). This can be a stealth cost that many overlook. An acquisition can thus unintentionally violate Java licensing if not addressed since your employee count has changed. If one side had an older Java license agreement (like the older per-processor or Named User metric), check how that transfers or if it’s even transferable. Most likely, Oracle will push the merged entity to the newer Java subscription model. During Divestiture: Determine if the newco uses Oracle Java. If so, they must obtain their subscription. The parent’s Java subscription (if one exists) will typically only cover its employees. There’s no 90-day rule known for Java; it’s more straightforward – they just aren’t licensed once they’re not part of the company. The newco could also consider alternatives like OpenJDK or AdoptOpenJDK to avoid immediate licensing, but that’s an IT decision beyond licensing (and Oracle’s stance on support, etc., should be weighed). The main advice is not to ignore Java – treat it like any other Oracle product in your audit.
• Oracle Cloud Services (SaaS/PaaS/IaaS): If either company uses Oracle Cloud (like Oracle ERP Cloud, HCM Cloud, Oracle Cloud Infrastructure, etc.), these subscriptions have their contracts (usually term-based services agreements). During M&A: Check if those cloud subscriptions can be assigned or need to be re-signed. Often, cloud contracts have clauses about assignment, similar to licenses. If Company B has Oracle Cloud accounts, you might keep them separate until renewal, possibly consolidating under one master cloud agreement. Oracle cloud subscriptions typically have a set duration and are prepaid. You should notify Oracle if the subscriber’s name or ownership changes – they may simply update the account info. But if, for example, the target’s cloud services need to be used by the wider merged company, ensure the contract allows that (Oracle SaaS is usually priced per user – you may need to add more users for the new folks).In some cases, Oracle might require the contract to be reissued under the acquiring company’s name. Watch out for minimum-commit cloud contracts – if one company had a large commitment, you might have multiple commitments after the merger. You could negotiate to merge those commitments or at least not over-commit. During Divestiture: If a business unit using Oracle SaaS is spun off, determine if the newco can continue on that Oracle Cloud service. Oracle might allow the contract to be assigned to the new company (since it’s a service, they might be more flexible to keep a customer). If not, the newco may have to sign a new contract at different rates. Data migration from one tenancy to another could be needed. For Oracle Cloud Infrastructure (OCI) usage, if the newco had part of a tenancy, you might split resources or clone them to a new tenancy that the newco owns. Ensure this is planned to avoid losing data or access during separation. Essentially, the cloud is treated similarly
  to software in terms of needing new arrangements.
• Oracle Unlimited License Agreement (ULA): A special mention for ULAs across product lines (databases, middleware, etc.). During M&A: Check the terms if the acquiring or acquired company is in the middle of a ULA (an unlimited deployment period). As noted earlier, Oracle ULAs often exclude the right to unlimited deploy in acquired entities unless Oracle approves (commonly if the acquired entity increases your metrics by less than 10% they allow it, if more, they might not). If both companies have ULAs, that’s complicated – likely, you’ll have two separate ULAs running their course; you might later negotiate a combined one. Coordinate certification if they end around the same time. Do not assume an acquired company can be stuffed into an existing ULA’s final certification if it wasn’t allowed in the contract – Oracle can reject those deployments, leaving them unlicensed. During Divestiture: If the parent has a ULA and spins off a part, usually the ULA contract says the divested part can keep using it until the ULA ends or for a defined period (like 6 months) and then has to stop. If the ULA is nearing its certification, you might include the divested entity’s deployments in the certification counts. Hence, the parent gets licenses, but those licenses would stay with the parent. The newco would then have to license itself or find an arrangement. Maybe the newco gets a subset of those perpetual licenses after certification via a split negotiation (again, Oracle would need to bless that). ULAs and M&A are very tricky – they often require case-by-case negotiation with Oracle to avoid huge compliance gaps.

In summary, each Oracle product may have its own twist, but a general rule is to treat each major Oracle-based system as its own line item in your M&A checklist. Ensure databases are licensed for new hardware/combined users, applications cover new headcounts, Java usage is counted, and cloud services are reassigned appropriately.

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.

Global and Regional Considerations

Oracle’s policies are largely global, but the legal and practical enforcement can vary by region. Here’s a global perspective on what to watch for:

• United States & North America: In the U.S., software license agreements are generally enforced according to their terms. Most states’ contract laws typically uphold anti-assignment (non-transfer) clauses.
• . Thus, Oracle’s stance in the U.S. is very strict – you violate, you pay. U.S. companies have less legal recourse to challenge Oracle’s contract conditions, so negotiations and compliance are key. Oracle in North America is known for aggressive auditing and big compliance claims (the Mars case happened in California, for example). So if you’re in this region, assume Oracle will enforce every letter of the agreement if challenged.
• European Union: The EU has some unique legal precedents. Notably, the European Court of Justice (ECJ) in the “UsedSoft vs Oracle” case (2012) ruled that under certain conditions, an Oracle software license (for downloaded software) could be resold by the original buyer despite Oracle’s non-transfer clause. This established the “software exhaustion” principle – essentially treating software like a good that can be resold. However, this applies mainly to fully paid-up perpetual licenses and requires the seller to stop using them. How does this affect M&A? It means that in some EU jurisdictions, Oracle’s absolute bar on transfer might be challenged if, say, a company wanted to legally argue that their license should transfer as part of selling a business unit (as that is effectively selling that part of the business’s assets, including software). In practice, though, few companies want to fight Oracle in court on this, especially during an M&A when timing is critical. So, while EU law provides a bit more wiggle room, it’s not a get-out-of-jail-free card. Companies in Europe sometimes use this as leverage – Oracle knows if pushed, a customer might have a legal basis to claim a transfer is lawful. Thus, Oracle might be slightly more flexible in Europe to avoid setting unwanted precedents. Key point: If you’re in the EU or transferring licenses in Europe, consult legal counsel about local law rights. Don’t assume you can, but know your rights are stronger. For pan-European deals, consider that regulatory frameworks favor not overly restricting business asset transfers.
• UK and Other Regions: The UK, now outside the EU, might not strictly follow the ECJ precedent in the future, but historically, UK law was similar on exhaustion (though the UsedSoft case was EU-wide). In Asia-Pacific, enforcement varies. Oracle’s offices in APAC (like in India, Japan, etc.) also do audits, but sometimes, local business culture may make negotiations slightly different. Some countries have strict exchange control or IP laws. For instance, software license transfers in India might need RBI (central bank) approvals if payments are made abroad, etc. These don’t nullify Oracle contracts but add complexity. In Latin America, oftentimes, everything is just as per contract – no significant consumer-friendly laws for enterprise software transfers, so Oracle’s terms rule.
• Oracle’s Regional Sales Tactics: Another difference is how Oracle’s sales and LMS teams approach M&A in different regions. In Europe, Oracle LMS might offer a more consultative approach (sometimes they frame it as helping to review compliance proactively). The US might feel more adversarial from the get-go (a formal audit notice, etc.). In any case, be cautious about Oracle offering “free” help in analyzing your licenses around an M&A – they may be gathering info to use in a compliance case. Always treat Oracle personnel, regardless of region, as representatives of the vendor’s interest, not yours.
• Currency and Pricing: If a merger is cross-regional, note that Oracle license pricing can differ by country (they maintain price lists in different currencies, and discount levels can vary by local market conditions). Oracle might adjust prices to a single currency or harmonize discounts when consolidating. Be alert that a license bought cheaply in an emerging market might be revalued if moved under a U.S. agreement. Conversely, suppose you’re separating a division in a country where Oracle software is typically cheaper. In that case, the newco might be able to buy at that local rate rather than the parent’s higher rate – something to explore. Oracle should have a unified global price list (in USD), but local deals vary in practice. It’s worth involving local procurement teams to negotiate with Oracle’s local offices for newco deals, as they might secure better terms by leveraging local relationships.
• Legal Entity Specifics: Some countries have laws about the succession of contracts in mergers (for example, Germany has rules under which contracts transfer by law in asset vs share deals). If the merger is structured as an asset purchase vs a stock purchase, the distinction might affect whether contracts automatically assign. Usually, Oracle will still insist on controlling assignment, but if local law forces the contract to move, Oracle could find it hard to object. These nuances are very legal-heavy; involve your legal counsel to understand if your transaction structure in a given country triggers any automatic transfer of license rights.
• Data Privacy during Audits: Slightly tangential, but regionally, privacy laws (GDPR in Europe) might restrict what data can be given to Oracle in an audit (like employees’ personal data). In an M&A audit, just ensure that sharing data with Oracle (who might be in another region) doesn’t violate privacy regulations. Usually, it doesn’t, if limited to business info, but it’s something to keep in mind, especially for employee-count metrics.
• Government or Regulated Industries: In some countries, if the companies merging are under certain regulatory oversight (like a bank merger in the EU), regulators themselves might inquire about operational continuity, including software licenses. Rarely can authorities influence vendor behavior (though expecting help from a regulator against Oracle is optimistic unless Oracle’s stance threatens a critical service outage). But just know your sector and local regulatory expectations – sometimes you can use that as pressure (“We can’t have our core bank system unsupported, Oracle; we need a solution during this merger”).

In summary, while Oracle’s base contract and approach is global, the legal landscape and negotiation leverage can shift regionally. EU offers some legal avenues for license transferability, US less so; enforcement aggressiveness may vary, but assume Oracle will be tough everywhere.

Always ground your strategy in the contract, but keep an eye on local law for any additional rights, and adapt your negotiation style to the region’s norms (for example, in some cultures, a confrontation like Mars did might be unheard of; instead, a more relationship-driven negotiation might yield results).

Having covered all these aspects, let’s wrap up with a concise set of actionable recommendations that SAM managers and Oracle licensing professionals should follow when navigating mergers, acquisitions, or divestitures.

Recommendations:

• Embed Licensing in M&A Planning: Treat Oracle (and other software) licenses as critical assets/liabilities in every merger or divestiture. Always perform license due diligence alongside financial and legal considerations before the deal is finalized.
• Review Contracts for Transfer Clauses: Identify Customer Definition, Assignment, and Divestiture Clauses in Oracle agreements early. If needed, negotiate contract modifications or ensure compliance with those clauses (e.g., notifying Oracle within the required timeframes of a merger).
• Engage Oracle Proactively (But Prepare First): After you have a clear internal understanding and strategy, involve Oracle early to discuss the impending changes. When you engage, be ready to negotiate terms like transition periods, adding new entities, or transferring licenses. Always get Oracles’ commitments in writing.
• Leverage Expert Help: Use independent Oracle licensing experts or SAM consultants to guide you. They can identify hidden compliance issues, advise on negotiation tactics, and ensure you’re not overbuying. Their guidance can save you from multi-million dollar mistakes.
• Negotiate Transition & Carve-Out Agreements: If divesting, secure a written transition arrangement with Oracle for the outgoing entity (e.g., a 90-180-day usage extension). If acquiring, negotiate how the acquired licenses will be folded in or maintained. Don’t hesitate to ask for concessions—the M&A event is your best chance to get exceptions or discounts from Oracle.
• Avoid Assumptions – Get Approvals: Never assume licenses transfer automatically. If you want to transfer certain licenses to a spun-off company or allow a newly acquired team to use your licenses, explicitly ask Oracle for approval and document it. This avoids disputes when an audit team might not honor a verbal understanding later.
• Optimize Post-Merger Licensing: Consolidate and optimize your Oracle licenses after a merger. Eliminate redundancies, adjust license counts to actual usage, and consider consolidating contracts for easier management (while watching out for cost implications). Use the increased scale to negotiate better support terms or discounts going forward.
• Plan for Splits: When splitting a company, create a detailed plan for how each Oracle system will be handled – which ones will be replicated, which need new licenses, how long the old systems will support the newco, etc. Share this plan with all stakeholders and Oracle to prevent illegal use post-separation.
• Cover All Oracle Products: Include less obvious products like Java SE, Oracle VM, or even Oracle Linux in your assessment. These often slip through cracks and can carry significant costs. Ensure the new or combined entity has the rights for every Oracle product in use, not just the big databases or apps.
• Maintain Strict Compliance and Documentation: Keep meticulous records of license entitlements, usage, and all communications with Oracle around the M&A. If Oracle audits you, your thorough documentation of what was agreed and what is deployed will be your best defense. Continuously monitor compliance during the transition – M&A integration can be chaotic, so audit yourself frequently to catch any drift.
• Seek Legal Counsel on Regional Nuances: Consult legal experts about local laws on license transfers or assignments, especially for international deals. While you should aim to work within Oracle’s framework, knowing your legal footing (e.g., rights under EU law) can inform your negotiation stance or contingency plans.

By following these recommendations, organizations can better safeguard against Oracle license compliance risks during the turbulence of mergers and acquisitions.

The key is proactivity and informed management – tackling license issues early and head-on rather than reacting after the fact. With careful planning, clear communication, and negotiation savvy, you can turn Oracle licensing from a potential deal-spoiler into a manageable aspect of your M&A strategy.

Do you want to know more about our Oracle Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit