Oracle Java SE Licensing Changes (2019–2023): What CIOs & CFOs Need to Know

Oracle Java SE Licensing Changes (2019–2023)

Legacy Java SE Licensing (2019–2023): Named User Plus and Processor
From 2019 up to early 2023, Oracle sold Java SE subscriptions under two legacy metrics familiar from its database licensing: Named User Plus (NUP) and Processor.

These models allowed organizations to pay only for actual Java usage rather than a blanket fee for every employee:

• Named User Plus (NUP): A per-user license. Each named user authorized to use Java (or each device that accesses Java) requires a license. This metric was often used for desktop Java deployments or developer workstations. In practice, if 50 people in your company ran Java-based applications, you needed 50 NUP licenses (minimums applied on servers, e.g., Oracle often required a minimum number of NUPs per processor in server environments)​.
• Processor License: A per-processor license for Java on servers. Instead of counting users, you licensed each physical processor (CPU) where Java was installed. Oracle’s standard core factor calculations applied – multi-core chips counted as multiple, based on Oracle’s core factor table. A Processor license allowed unlimited Java users on that server, but charged per CPU core. This model suited back-end systems or applications where Java was running on servers accessed by many users.

Cost of Legacy Metrics:

These Java SE subscription fees were relatively modest by enterprise standards. Oracle’s public price list pegged Java SE at about $2.50 per named user per month and $25 per processor per month (list price).

In other words, ~$30 per user per year, or ~$300 per server processor per year for Java support. For example, licensing 100 users for Java under NUP might cost around $3,000 annually, and licensing a server with four CPUs would be around $1,200 per year.

Under this legacy model, organizations only paid for the specific Java users or systems they needed to support, not for every employee in the company.

Oracle’s Switch to an Employee-Based Subscription Model (2023)

In January 2023, Oracle abruptly eliminated the NUP and Processor licensing options and introduced a new metric called “Employee for Java SE Universal Subscription.”

This employee-based model fundamentally changed how Java is licensed:

• All Employees Count: The new subscription requires licensing based on the total number of employees, not the number of Java users. Oracle defines “employee” broadly to include all full-time, part-time, temporary employees, as well as contractors or outsourcers supporting the business. Every person in the organization counts toward the license total, even if only a fraction of them use Java. If your company has 5,000 employees worldwide, a Java SE Universal Subscription must cover all 5,000, regardless of whether only 50 or 500 of them actively run Java applications. Partial coverage is not allowed; it’s an all-or-nothing enterprise-wide subscription.
• Virtually Unlimited Use: In exchange, the subscription allows unlimited Java use across the enterprise, with a very high cap of 50,000 processors, which few companies will likely exceed. You no longer have to count specific installations or users. In theory, any use of Java within the company is covered as long as you maintain an active subscription for your total employee count. This simplifies compliance on paper, but dramatically raises costs for organizations that previously only paid for a subset of users or servers.
• New Pricing Structure: Oracle sets tiered pricing per employee, which decreases with larger headcounts. For a small or mid-sized firm, the list price is $15 per employee per month (if you have fewer than 1,000 employees). The rate scales down for larger enterprises (e.g., around $5–$10 per employee for tens of thousands of employees). Even with volume discounts, this often results in far higher annual fees than the old model. For example, a company with 500 employees would pay roughly $15 × 500 × 12 = $90,000 per year under the new scheme – even if only a handful of those employees use Java. Under the legacy model, that same company might have paid only for, say, 50 Java users ($30 per user × 50 = $1,500 per year) or a few server licenses. The new model is effectively an enterprise-wide license – simple but costly, as it charges for a lot of “shelfware” (people who never use Java).

Oracle removed the old NUP and Processor SKUs from its price list entirely in 2023. New Java SE subscriptions must use the employee metric.

Existing customers with legacy Java subscriptions were initially told they would be “grandfathered” – i.e., they could continue renewing under the old metrics for the time being​.

However, as we discuss next, renewing on those legacy terms has proven to be challenging and fraught with risk.

Legacy Subscription Renewal Challenges

If your organization purchased Java SE subscriptions before 2023 (using NUP and Processor licenses), you face a tricky situation at renewal. Oracle’s public messaging in early 2023 suggested that existing customers could renew under the same terms and metrics​.

In practice, however, renewing a legacy Java subscription is neither automatic nor guaranteed. CIOs and CFOs should be aware of the following challenges when trying to extend legacy Java agreements:

• No Contractual Guarantee: Legacy Java subscriptions were sold as yearly (or multi-year) term agreements with no perpetual rights. No clause in your contract guarantees you can renew on the same terms. Once your term expires, Oracle is not legally obligated to offer the same pricing or metrics again​. The promise that you “may renew under existing terms” came from an FAQ and Oracle sales reps, not from a binding contract. In other words, Oracle reserves the right to change the deal at renewal time.
• Oracle’s Approval Required: Oracle has made it clear that renewing a legacy subscription is at their discretion. Even customers who are fully compliant and willing to pay the renewal fee have been told that renewals on old metrics must be approved by Oracle management​. Oracle can choose to deny a renewal and force the customer to switch to the new employee-based model. This creates uncertainty – your ability to stay on the cheaper model rests on Oracle’s willingness to allow it. Reports in 2023 indicated that Oracle sales reps sometimes outright refused to renew legacy Java subscriptions, insisting that customers migrate to the new model instead. Others were granted a one-year renewal, but with a catch: Oracle inserted contract language stating that it would be the final renewal on legacy terms (i.e., the next renewal would switch to the employee model).
• No Expansion of Legacy Terms: Oracle will not allow you to increase your usage under the old model at renewal. The most you can do is renew the existing license counts you already had – no additional NUP or Processor licenses can be purchased. If your Java usage exceeds the original licensed quantities, Oracle’s stance is that you cannot simply “true up” by purchasing more NUP/Processor licenses, as those SKUs are discontinued. This means if you need to cover new Java deployments, Oracle will push you to the employee model for any expanded scope. At best, you can renew what you had and cover only that same footprint as we advance (and even that isn’t guaranteed beyond the current renewal).
• Mandatory Audit/Validation: Perhaps the biggest hurdle is that Oracle is tying legacy renewals to a strict usage audit. Oracle’s updated FAQ (as of July 2023) explicitly conditions any legacy renewal on “confirmation that current usage is reflective of license counts in [the] existing order”. In plain terms, Oracle will audit your Java deployment to ensure you’re not using more than you originally licensed before letting you renew. Many customers have experienced this as a “soft audit” during renewal: Oracle will request detailed deployment data (such as servers, CPUs, the number of Java installations, and versions in use) and compare it to their licensed NUP/Processor counts. If you don’t comply and share this data, Oracle will not grant the renewal​. This effectively forces customers into an audit process to continue their subscription. Oracle’s Java renewals team has been known to demand an exhaustive accounting. In some cases, ask for an inventory of all systems, even those not running Java, to verify that nothing is running without a license. Failing to “prove” full compliance means no renewal offer.
• Zero Tolerance for Non-Compliance: If Oracle’s forced audit finds you even slightly out of compliance (e.g., you deployed Java on a few more processors or users than you paid for), the legacy renewal is off the table. Oracle will not sell you additional legacy licenses to cover the shortfall. Instead, they will demand that you purchase an employee-based subscription to cover your entire organization as the remedy. In many cases, Oracle also threatens retroactive fees – for example, making you pay for backdated subscription costs for unlicensed usage (often up to 2-3 years’ worth) as a penalty for the period you were out of compliance. Even a minor overage (say, 5 extra users beyond your NUP license count) could result in Oracle refusing the renewal and insisting on a global license deal. This creates a “Catch-22”: you must be 100% compliant to renew, but if you’re not, your only option is the new, expensive model (and possibly hefty back-pay fees). Many organizations, especially those with widespread Java installations, find it challenging to track every installation and user perfectly; any oversight gives Oracle an advantage.

In short, renewing under the old Java SE terms has become a gauntlet. Oracle is using the renewal process to audit customers and to accelerate migration to the higher-cost model. CIOs and CFOs must approach a Java renewal expecting scrutiny and possibly pushback from Oracle.

Do not assume it will be a simple paperwork exercise – Oracle may use your renewal as an opportunity to identify compliance gaps or upsell a new subscription.

Risk of Forced Migration and Cost Exposure

The biggest concern in this transition is the financial shock organizations face if they are forced onto Oracle’s new model. Under legacy pricing, Java was a manageable expense in most IT budgets. Under the new scheme, it can become a significantly higher cost burden with little relation to actual usage.

Key points to consider:

• Massive Cost Increases: Many companies have calculated that moving from NUP/Processor licensing to employee-based licensing would multiply their Java costs several times. In Oracle’s example FAQ, they acknowledged the potential for 800%–1500 % increases for customers with large employee counts but modest Java use. Real-world cases have proven this out. For example: One mid-size firm (~250 employees) with a small Java footprint (20 desktop users and eight server processors running Java) was paying about $2,900 per year under the old model; if forced onto the new model, their cost would leap to $45,000 per year – a 1,452% increase​. Another organization with extensive Java on servers had an annual Java subscription of around $85,000 under legacy terms. The new employee-based quote for their 42,000 employees came to $2.646 million per year, over 30 times higher. These jumps can be budget-breakers, especially if they’re unplanned.
• Unbudgeted “Java Tax”: If you assume Oracle will renew your legacy agreement and you budget accordingly, you could be blindsided if they instead push you to the new model. A company expecting a $ 50,000 renewal might be given a $ 500,000 or $5 million quote. Oracle sales reps themselves have referred to the new model’s exorbitant cost as an internal “Java tax” or windfall. One client, who pays around $ 40,000 annually for Java, was presented with a $3 million annual bill under the new scheme. Such a scenario can have a material impact on IT budgets and even require CFO intervention for emergency funds. The risk here is not just theoretical – many Oracle customers have seen their renewal quotes balloon five times, ten times, or even twenty times. CIOs must prepare leadership for this possibility well before the renewal deadline.
• Limited Negotiation Leverage: When Oracle effectively says, “move to the new model or lose access and support,” customers often feel cornered. Oracle knows that if you’re running business-critical systems on Java, you can’t simply drop your subscription without exposing yourself to security and compliance risks. This leverage can make negotiation difficult – Oracle may offer only a token discount or a phased uplift at best. Some organizations have had success negotiating price breaks or one-time concessions, especially if they threaten to drop Java usage or switch providers. Still, you should not count on significant relief. Oracle’s stance is fundamentally that the pricing model has changed, and customers must adapt or find alternatives. The legacy metrics are being phased out, so any temporary renewal is just delaying the inevitable shift in cost structure.
• Operational Disruption: Beyond cost, being forced into a new licensing model can create operational complexity. Suddenly, having to count all employees and update contracts is a non-trivial procurement task. If budgets aren’t approved in time, organizations risk a lapse in Java support, which could halt access to critical security updates. In a worst-case scenario, a standoff in negotiations could result in your Java SE subscription expiring while you are still running Oracle JDK in production, putting you out of compliance and making you vulnerable. Oracle can then use an audit (or the threat of one) to apply even more pressure. In short, the migration isn’t just cutting a bigger check; it involves planning, coordination, and potentially scrambling to mitigate usage if costs are prohibitive.

Given these stakes, it’s clear that assuming a smooth legacy renewal is a high-risk gamble. The prudent approach is to anticipate Oracle pushing you to the new model either now or shortly, and to plan accordingly to avoid being caught off guard.

Oracle’s Java Audit Tactics and Triggers

Oracle’s aggressive stance on Java licensing is accompanied by equally aggressive compliance enforcement.

Since monetizing Java in 2019, Oracle has increased its audit activities, specifically targeting Java deployments. CIOs and CFOs should be aware of how Java audits are initiated and the tactics Oracle employs:

• Expiration = Audit Target: Oracle closely monitors which customers have Java subscriptions and when they expire. If you had a legacy Java SE subscription and let it lapse without renewal, Oracle is likely to come knocking. They know the date your support ended, and they assume that you may still be running Oracle Java without a license, which is now non-compliant. Often, organizations that don’t renew – or even those that renew but for fewer licenses than before – get flagged for an audit review. The logic is simple: if you drop your Java subscription (or cut the quantity), Oracle suspects you didn’t actually remove or reduce Java usage accordingly. It’s common to see Oracle initiate a “license review” shortly after a subscription expiration for this reason. In essence, a lapsed Java subscription is an open invitation for Oracle’s audit team.
• Soft Audits via Email: Oracle frequently begins Java compliance checks with a so-called “soft audit.” This might be a polite email from Oracle’s Java licensing team or your account manager saying something like, “We’d like to discuss your Java usage,” or an invitation to a Java licensing webinar. Oracle has also been known to send formal questionnaires asking you to self-report all Java installations. These inquiries often target companies that have never purchased Java licenses despite significant Java download activity, or customers whose subscriptions have expired. Ignoring these inquiries is dangerous – not responding typically escalates the situation​. Oracle treats silence as a red flag and may quickly move to a formal audit notice if a soft audit is rebuffed or unanswered.
• Download Tracking: Be aware that Oracle tracks downloads of Oracle JDK from its website. They have logs of which company domains or IP addresses download Java installers and updates. If your IT staff have been downloading Oracle Java binaries or updates (especially after public free updates ended for Java 8 and 11), and your company has no corresponding license, Oracle likely knows. Many firms that never paid Oracle for Java have received audit letters simply because Oracle’s logs show that they downloaded patches or new JDK versions. This is an easy way for Oracle to identify non-paying users of Java.
• Audit by Stealth or by Contract: Oracle may conduct what some call a “stealth audit” during the renewal process (as described earlier) or through the soft audit approach. However, Oracle can also formally invoke its contractual audit rights. If you have any Oracle Master Agreement or Oracle License Agreement in place (which you likely do if you ever bought Oracle products or the Java subscription itself), there’s usually a clause allowing Oracle to audit your usage. A formal audit involves an official notice and often the deployment of Oracle’s audit scripts or tools to scan for all Oracle Java installations in your environment. Oracle’s auditors will look not just at whether you have Java installed beyond licensed quantities, but also for any use of commercial features in older Java versions or deployments in virtualized environments that might expand your license requirements. They come well-prepared to find any compliance shortfall.
• Audit Leverage and Tactics: Oracle’s License Management Services (LMS) and Java sales teams use audits as a strategic tool. With Java, their goal is either to make non-compliant customers buy subscriptions (preferably the new universal subscription) or to upsell existing customers to the broader model. During audits, Oracle is known for hardball tactics such as tight deadlines, far-reaching data requests, and pressure to quickly “resolve” findings by purchasing licenses. In the Java context, that typically means Oracle will push a subscription deal (often the employee-based model) as the settlement for any compliance issues. They may even calculate a theoretical liability (e.g., “You used Java on X more processors than licensed, so you owe $Y in back fees”) to scare up a large number, then offer to waive it if you sign a pricey new subscription. The audit scenario can quickly turn adversarial, and without proper preparation, customers may feel coerced into signing new agreements under duress​. The key point is that Oracle is actively using the threat of audits, especially around Java, to drive revenue. Java has become one of Oracle’s audit hotspots since the licensing change, as many companies are either unaware of the new rules or hoping to avoid the steep fees.
• Audit Triggers to Watch: Beyond non-renewal or download activity, Oracle tends to focus its Java compliance efforts on organizations that heavily use Java but are not officially licensed. Industries with a high number of Java-based applications, such as finance, retail, and telecommunications, are prime targets. Also, companies that have little or no other Oracle spend (no database or apps contracts) can be seen as low-hanging fruit – Oracle can audit them for Java without jeopardizing a larger account relationship. On the other hand, Oracle might handle its large database customers more gently with Java at first (a soft audit) to avoid souring the account. Still, ultimately, everyone is being pushed to pay for Java one way or another.

Pricing Examples: Legacy vs. New Model Impact

To illustrate the financial impact of these changes, below are a few scenarios comparing the legacy Java SE subscription costs to the new employee-based subscription costs:

(Note: Volume-discounted rate of $5.25 per employee/month was applied in this large enterprise example​.)

These examples underscore how drastic the cost difference can be. Under the legacy model, costs scaled with actual usage (# of Java users or CPUs). Under the new model, costs scale with organization size, which will be a much larger number for most.

Even organizations that heavily used Java are seeing higher bills, and those that used it sparingly are seeing astronomical percentage increases.

The financial risk of being forced onto the new model cannot be overstated – it can mean millions in new annual spending that wasn’t in the budget.

Specific Risks of Assuming a Legacy Renewal

It’s worth calling out the dangers of a false sense of security. Some organizations, hearing Oracle’s early assurances about legacy renewals, may assume they can renew “as-is” and avoid the new model costs.

This is a risky assumption for several reasons:

• Oracle Can Change Its Mind: Oracle’s policies (and FAQ statements) are subject to change at any time. Oracle revised its Java FAQ in mid-2023 to toughen its stance on renewals, adding a usage audit requirement​. A promise today doesn’t guarantee a similar offer tomorrow. By the time your renewal comes up, Oracle may say legacy renewals are no longer offered (or only offered under prohibitive conditions). There is no guarantee the “grandfathering” courtesy will continue.
• Verbal Assurances Are Not Binding: Your Oracle account manager might informally say, “Don’t worry, we should be able to renew your Java subscription on the old terms.” Such assurances should be viewed with skepticism unless they are formally documented. Oracle representatives do not have the final say – approvals are higher up, and Oracle’s written quote or contract will dictate the actual terms. Always get any renewal terms in writing. Many customers have been told one thing, only to receive a quote that contradicts it (e.g., a quote that only includes the new model). Until you see an official offer, don’t count on a legacy renewal.
• Assuming Budget Stability: If a CIO or CFO assumes the Java line item will remain, say, $ 100,000 per year, they might allocate accordingly and spend the budget elsewhere. If the renewal then comes in at $ 1 M+, the organization could be caught financially unprepared. This could lead to emergency budget requests, dipping into reserves, or forced cuts in other projects to pay the “Java tax.” It’s far safer to assume the worst-case (i.e., plan for a big increase) and be pleasantly surprised if you can renew cheaply than the reverse.
• Compliance Drift: Assuming an easy renewal might also lead some teams to be less vigilant about tracking Java usage. If everyone believes they’ll renew what they have, they might not notice that usage has grown. Then the renewal audit finds more installations than licenses, and the renewal is denied. In other words, complacency can breed a compliance gap, which in turn triggers the very outcome (forced new licenses) you hoped to avoid.
• Last-Minute Scramble: If you walk into renewal negotiations naively expecting a simple renewal and Oracle throws a curveball (like a new model quote or an audit demand), you will have little time to react. You might scramble to evaluate alternatives, try to negotiate, or urgently assess your true Java usage. That process ideally takes months of planning, not a few weeks under Oracle’s pressure. Thus, assuming a legacy renewal can put you behind the 8-ball with a ticking clock. Oracle might deliberately time things to squeeze you, knowing you’re backed against the wall.

In summary, never assume Oracle will behave leniently when a high-revenue alternative is on the table. Hope is not a strategy; concrete preparation is needed for the end of your Java subscription term.

Recommendations

For CIOs and CFOs navigating Oracle Java SE licensing, here are direct steps to manage renewals and minimize audit exposure:

• 1. Start Planning Early: Treat your Java subscription renewal as a major event – begin preparations 6-12 months before the term expires. This lead time is crucial to assess your position and consider options before Oracle engages. Last-minute negotiations benefit Oracle, not you. Make Java a line item in IT strategy discussions well ahead of renewal.
• 2. Inventory Your Java Usage: Conduct a thorough internal audit of all Oracle Java deployments in your environment. Identify where Java is installed (on servers, VMs, or desktops) and who uses it. Verify your usage against your current licenses. This includes versions and patch levels (ensure you know if you’re using Oracle-only builds). The goal is to uncover any gaps yourself before Oracle does. If you find that you’ve exceeded your licensed counts, you have time to either reduce your usage or plan how to address the issue. Having a complete inventory also enables scenario planning – e.g., “What if we had to cover all these installations under the new model? What would it cost?” This data is powerful when dealing with Oracle.
• 3. Avoid Letting Your Subscription Lapse: If you intend to continue using Oracle Java, do not let the support expire without a new agreement in place. A lapsed (expired) Java subscription with continued use of Oracle Java is a compliance violation waiting to be exploited. Oracle’s audit teams are likely to pounce the moment your contract ends​. Even if you’re unsure about signing the new model, try to negotiate an extension or short-term bridge rather than risking an expiration. The period after a lapse is when you’re most vulnerable to a formal audit and heavy-handed tactics.
• 4. Engage Oracle (Carefully) on Renewal Terms: Open a dialogue with Oracle well before the renewal date to understand their stance. Ask direct questions: Will Oracle offer a renewal quote under the existing NUP/Processor metrics? For how long? If Oracle indicates that only the new model is available, you should know this as soon as possible. However, be cautious about what information you volunteer. Do not hand over detailed deployment data at the first ask. If Oracle requests a “Java usage review” meeting, consider involving your contracts or legal team, or a licensing advisor, before sharing any information. Remember, any data you provide will be used in negotiations (or audits). It’s often wise to respond to Oracle’s inquiries with high-level info or even push back until you have a clear strategy.
• 5. Get Any Promises in Writing: If Oracle (or a representative) agrees verbally to allow a legacy renewal, ask for that commitment in a formal quote or an email. Without a written record, you have no recourse later if they change course. If you receive a quote, scrutinize it for any special clauses or changed terms. For example, if a renewal quote says “no further renewals on this SKU,” you need to flag that for management – it means you have one year before being forced to the new model. Elevate the visibility of such terms internally so they’re not missed.
• 6. Model the Costs and Budget for the Worst-Case Scenario: Perform a cost analysis of the new employee-based model compared to your current situation. Calculate the potential spend if you had to license all employees. This might be a shocking figure, but it’s better to be aware of it. Present a comparison to the CFO and budget committee: e.g., “Today we pay $X; under the new model we’d pay $Y (~Z% increase).” Having this in your back pocket ensures the organization isn’t blindsided financially. You might even allocate a contingency budget or set aside funds in case the new model becomes inevitable. Being financially prepared reduces the chance you’ll be forced into a bad deal under duress.
• 7. Consider Alternative Licensing Strategies: While this article doesn’t focus on non-Oracle solutions, it’s worth exploring all options internally. Oracle Java SE is not the only JDK distribution – there are open-source builds and third-party supported JDKs. Moving to those comes with its challenges and must be managed carefully to avoid Oracle compliance issues (e.g., ensure no Oracle JDK usage remains). Some organizations also consider Oracle ULA (Unlimited License Agreements) if Java is one piece of a larger Oracle negotiation. The point is to evaluate your leverage. If Oracle senses you have no choice but to accept their terms, your negotiating power is low. If you have a credible plan to minimize Oracle Java usage or other Oracle deals in play, you may be able to negotiate a more favorable outcome. Do not present Oracle with a captive customer scenario – make it clear you have strategies to avoid a massive fee, whether that’s optimizing usage, migrating certain applications, or even walking away from Oracle Java in the long term.
• 8. Leverage Expert Help if Needed: Oracle’s Java licensing changes have spawned a niche industry of licensing consultants and law firms (some of which are cited above) that specialize in Oracle compliance. If the stakes are high (e.g., a seven-figure exposure), consider engaging experts who have dealt with Oracle Java audits and renewals. They can help you navigate Oracle’s tactics, craft negotiation strategies, and ensure you don’t inadvertently concede something you shouldn’t. While it’s an added cost, it can pale in comparison to the potential fees at risk. At a minimum, ensure your procurement and legal teams are fully up to speed on Oracle’s Java policies – this is not a standard software renewal so that it may require specialized knowledge.
• 9. Be Prepared for an Audit: Given Oracle’s track record, prepare as if an audit is coming. This means having your deployment data well-documented, cleaning up any unnecessary Oracle JDK installations (e.g., uninstalling Java from servers or PCs that don’t need it to shrink your footprint), and understanding your rights. If audited, know that you can insist on a formal process (instead of an open-ended fishing expedition). During a formal audit, you’ll have certain timeframes and can negotiate scope – use that to your advantage. The main goal is not to be caught by surprise. By anticipating an audit, you can respond calmly and confidently, rather than scrambling.
• 10. Keep Leadership Informed: Finally, communicate the risks to your C-suite and board, if applicable. Non-compliance penalties or multi-million dollar contract increases are the stuff of CFO nightmares. It’s better to brief leadership now that Oracle has changed Java licensing rules, and there’s a scenario where costs skyrocket, than to only bring it up when the issue arises. Early transparency ensures you’ll have support if tough decisions or funding adjustments need to be made. It also turns Java from an “IT-only issue” into a business issue, which is exactly where it belongs, given the potential impact.

In conclusion, Oracle’s Java SE licensing changes from 2019 to 2023 have transformed Java from a minor line-item into a significant compliance and budget concern. CIOs and CFOs must be proactive and hard-nosed in addressing this change.

The tone from Oracle has been blunt – pay up or risk exposure to compliance issues – so your response should be equally direct. By understanding the legacy vs. new metrics, recognizing Oracle’s tactics, and planning carefully, you can avoid the worst outcomes and make strategic decisions in your organization’s best interest.