Oracle’s New Java SE Universal Subscription (2023): An Advisory for SAM Managers and Licensing Professionals

In January 2023, Oracle fundamentally changed how it licenses Java Standard Edition (Java SE). The Java SE Universal Subscription replaced the older per-user and per-processor Java SE subscriptions. This new model bases pricing on an organization’s total number of employees rather than the number of Java users or installations. Below, we explain what changed, how the new “per employee” subscription works, its cost implications, and how organizations can respond. The goal is to provide SAM managers and Oracle licensing professionals with a clear, customer-centric understanding of this model, avoiding vendor bias and focusing on practical guidance.

Previous Java SE Licensing (Before 2023)

Old Licensing Metrics: Historically, Oracle sold Java SE through traditional metrics like Named User Plus (NUP) and Processor licenses​. In 2018, for example, Oracle introduced Java SE Subscription offerings that used:

• Named User Plus (per user) – Primarily for desktop or individual usage. Every named user authorized to use Java on a device needed a license, whether or not they used it. (Oracle typically enforced minimums, e.g., a certain number of NUP licenses per processor in server environments.)
• Processor (per core): This was mainly used for servers or environments where counting individual users was impractical. You licensed each CPU/core on machines running Java, allowing unlimited users on that machine​.

Previous Subscription Products: Until 2023, Oracle offered separate subscription SKUs—e.g., Java SE Subscription (covering servers) and Java SE Desktop Subscription (for desktops)—each with its own pricing metric (processor-based or NUP-based)​. This meant organizations had to track where Java was deployed (desktop vs. server) and license accordingly, which could be complex.

Challenges: Under the old model, organizations often tried to minimize costs by limiting where Oracle’s Java was used or by strictly counting authorized users. Only those machines or users needing Oracle’s support/features would be licensed. On the other hand, Oracle incentivized moving to subscriptions by ending free public updates for older Java versions, nudging customers toward paid support.

2023 Change: Introduction of the Java SE Universal Subscription

In January 2023, Oracle replaced the legacy Java SE subscriptions with a unified model called the Java SE Universal Subscription​. The key change is a shift to an employee-based licensing metric:

• Licensed per “Employee”—Organizations must subscribe for all employees in the company, not just actual Java users or developers​. This is a fundamental shift from licensing only the users or systems running Java. Oracle’s contract metric, “Employee for Java SE Universal Subscription,” is defined broadly to cover essentially everyone in the organization who could indirectly use Java.
• Unified Usage Rights: The Universal Subscription covers all use cases (desktop, server, or cloud) under one subscription​. You no longer buy separate licenses for servers vs. PCs – one employee-based subscription permits Java usage anywhere in the environment. This simplifies compliance tracking (no need to count devices or processors) but greatly expands the license scope to your entire workforce.
• All-or-Nothing Scope: When purchasing the subscription, the minimum quantity you must buy equals the total number of employees in your organization on the order’s effective date. In other words, if your company has 2,000 employees, you must license 2,000 “employees” – even if perhaps only 100 actively use Oracle Java applications.

Why the Concern? This new metric is raising concerns because it can significantly increase customer costs. Oracle is effectively charging based on company size, which for large enterprises means paying for many people who don’t directly use Java. Industry analysts noted that most organizations expect the per-employee model to cost “two to five times” more than the old licensing model​. For smaller companies or those with Java widely deployed, the impact may be neutral or even a slight reduction, but costs can skyrocket for many others, especially large enterprises​.

Defining “Total Employee Count”

A critical detail is how Oracle defines an “Employee” for this subscription:

• All Staff and Contractors Count: Oracle’s definition includes all of your full-time, part-time, and temporary employees, plus all similar employees of your agents, contractors, outsourcers, and consultants that support your internal operations​. Simply put, any individual working for or on behalf of your company is counted. This means that even if you have 100 direct employees and 200 contractors (not on your payroll), Oracle considers the total of 300 employees for licensing.
• Group Companies: If your Oracle agreement covers multiple affiliated companies (e.g., your subsidiaries under a group license), those personnel would be included, too. Most enterprises must count the entire workforce under the subscribing entity. (For example, a subsidiary with 50 employees in the contract adds those 50 to the count.)
• Regardless of Java Usage: Importantly, it does not matter whether these employees use Java-based applications or not. A salesperson or HR staff member who never touches a Java application still counts toward the subscription if they are employees. Oracle’s FAQ emphasizes that the metric is based on total employees, not the number using Java.
• Timing of Count: Oracle measures the employee count when you place the order (effective subscription date). That number becomes the licensed quantity​. If your workforce grows later, you may need to true-up at renewal, but during the term, you’re covered as long as you licensed everyone at the start. (Similarly, if you downsize mid-term, you generally won’t get a refund – you’ve pre-paid for the initial count.)

Implication: This broad definition means organizations cannot reduce licensing costs by limiting Java to fewer users or machines—the only way to reduce the count is to reduce your total headcount or exclude certain groups from the scope of the agreement (which typically isn’t possible if they’re part of the company’s operations). Every person on the payroll (and supporting contractors) has become a cost factor for Java.

Universal Subscription Pricing Model

Pricing Structure: Oracle’s Java SE Universal Subscription uses a tiered, per-employee pricing model. The list price starts at $15 per employee per month (for small organizations) and decreases at higher employee counts​. The more employees you have, the lower the per-head rate, reflecting volume discounts. For example:

• 1–999 employees: $15 per employee per month (list price)​
• 1,000–2,999: $12 per employee/month​
• 3,000–9,999: $10.50 per employee/month
• 10,000–19,999: $8.25 per employee/month​
• 20,000–29,999: $6.75 per employee/month​
• 30,000–39,999: $5.70 per employee/month
• 40,000–49,999: $5.25 per employee/month
• 50,000+ employees: Contact Oracle for pricing (it may go even lower per head)​

Oracle quotes monthly prices, but subscriptions are generally sold as annual contracts (paid yearly). In practice, you multiply the monthly rate by 12 to get the annual cost per employee​.

Cost Calculation Example: If a company has 2,309 total employees (e.g., 1,543 full-time, 729 part-time, and 37 temp contractors – all counted)​, they fall in the 1,000–2,999 tier at $12 per employee/month. The cost would be calculated as:

• 2,309 employees × $12 × 12 months = $332,496 per year​.

Even a relatively small firm of 200 employees would pay about: 200 × $15 × 12 = $36,000 per year for Java SE support.

To illustrate how costs scale with organization size, the table below provides examples:

Table: Example Java SE Subscription costs at various organization sizes. Rates drop at higher volumes, but total costs still rise with employee count.

Even with volume discounts, large enterprises pay millions annually for Java SE if they subscribe for the whole company. Oracle provided an example of a company of 28,000 employees paying about $2.268 million per year, aligning with the $6.75 tier in our table.

Term and Renewal: The standard term is 12 months​, though Oracle sometimes offers 2-3 year terms for Java, which can lock in pricing longer. Upon renewal, the pricing and employee count can be reassessed each year. If your employee count has changed, expect Oracle to adjust the subscription quantity (and cost) accordingly at renewal.

Cost Impact on Different-Sized Organizations

The move to per-employee licensing has different implications depending on your size and Java usage pattern:

• Smaller Organizations: If a company already had many Java installations relative to its size, the new model might be cost-comparable or even cheaper. For example, under the old model, a small company with a few servers might have faced a minimum number of processor or NUP licenses that cost a certain amount; now, if they only have, say, 50 employees, the cost (50×$15×12 = $9,000/year) could be reasonable. In some cases, small firms that needed to license a server with multiple CPU cores might see a slight decrease by paying per employee instead of per processor. However, if only a few people or one team in a small firm used Java, that firm now must pay for all employees, likely increasing costs despite its small size.
• Mid-Sized Organizations: Mid-range companies (hundreds to a few thousand employees) will usually see higher costs than before, unless Java was ubiquitously used. Many midsize businesses might have only used Java in a handful of applications. Now, even a 500-employee company with a small IT team using Java must cover all 500 at $15 each. For 500 employees, $90,000/year could be a substantial spend, possibly more than they paid under a targeted licensing approach earlier.
• Large Enterprises: This is where the impact is most pronounced. Large enterprises with thousands of employees will likely pay significantly more under the new scheme​. If previously only certain departments (e.g., development teams or specific servers) required Java licenses, those costs were contained. Now, a company with 10,000 employees faces a bill of around $990k/year (10k×$8.25×12). Companies with 50k+ employees might negotiate a lower rate, but even at $5 per employee, that’s $3+ million annually. Gartner’s analysis found most organizations will pay 2–5× more with this model than before. The sticker shock drives many large Oracle customers to re-evaluate their Java strategy.
• Organizations with Minimal Java Use: A special case is companies that barely use Oracle Java (perhaps they only run open-source Java or have older versions still under free use). Such organizations previously paid Oracle $0 and stayed within free usage allowances. If Oracle audits and finds commercial Java usage, the new model could force them to license everyone, making a massive jump from $0 to a significant yearly expense. (Later, we will discuss alternatives to avoid this scenario.)

In summary, the broader the gap between “Java users” and “total employees,” the more your costs will increase with the new model. Companies that had tightly limited Java to a few systems will feel the biggest pinch. In contrast, those with Java everywhere might find the new flat-rate approach simpler (though not necessarily cheaper). The change essentially taxes organizational size rather than actual Java consumption.

Options and Considerations Under the New Model

Given this major change, what options do organizations have? Here are several considerations and strategies:

1. Staying on Legacy Java Licensing (Grandfathering): If you already had Oracle Java licenses or subscriptions before this change, you may be able to renew under the old metrics (NUP/processor) at least for now. Oracle has stated that existing customers can continue with their current terms and renew without forced migration to the employee model​. This is a form of grandfathering. However, there are caveats:

• You typically cannot expand your usage under the old model beyond what you originally licensed. The renewal can cover the same number of users or processors, but if you need more, Oracle will likely push the new model for the expansion.
• Oracle’s sales teams will apply pressure to switch to the new model over time​. They might, for example, offer incentives to move to the Universal Subscription or warn that legacy options will eventually end. It’s wise to plan for the possibility that legacy terms might not be offered forever.
• Do the math: If you have the choice at renewal, carefully compare costs. In some cases, sticking with an older per-processor deal might be cheaper than licensing every employee; in other cases, if you had a very high processor count licensed but fewer employees, the new model could save money. Evaluate both models’ costs for your situation before deciding.

2. Negotiating Volume Discounts and Terms: The list prices can often be negotiated, especially for larger enterprises. Oracle’s published tiers already provide discounts at scale, but additional discounts or concessions may be possible:

• Higher Volume, Better Rate: If you have over 50,000 employees or are committing to a large spend, Oracle may offer a custom rate below the $5.25 floor. Negotiating with accurate employee counts and perhaps competitive context (e.g., considering alternatives) can improve pricing​.
• Multi-Year Commitments: Oracle may propose multi-year subscription terms (e.g., 2-3 years). Agreeing to a longer term can sometimes secure a better per-employee price or protect against price increases for that period. This must be weighed against the risk of being locked in if you later reduce headcount or migrate away from Oracle Java.
• Bundling with Other Oracle Deals: If your organization also buys other Oracle products (databases, applications, etc.), you might negotiate Java as part of a broader agreement. Oracle might discount Java subscriptions in exchange for commitments in other areas (or vice versa)​.
• Negotiation Prep: Be prepared with data on how many of those “employees” actually use Java and its value to your business. While Oracle’s policy is that all employees must be licensed, making a case for a better rate by showing your effective usage density is low could be persuasive in negotiations (essentially, “we’re paying for 10,000 people but only 1,000 use Java—we need a better rate”). Oracle may or may not relent, but it sets the stage for a customer-advocate stance.
• Check for Oracle Programs: Sometimes Oracle has promotions or specialized licensing programs (like an enterprise agreement) that could mitigate costs. Explore these with an Oracle account rep, but with caution (and compare against using no Oracle Java, as discussed next).

3. Limiting or Eliminating Oracle Java Usage (Open-Source Alternatives): One way to avoid the new costs is to reduce your reliance on Oracle’s Java altogether:

• OpenJDK and Other Distributions: Java is open-source via the OpenJDK project. Numerous free Java distributions (e.g., Eclipse Temurin from Adoptium, Amazon Corretto, Azul Zulu, Red Hat OpenJDK, etc.) are functionally equivalent to Oracle’s Java SE. Many are open-source and free to use, even in production, with no licensing fees. Using these instead of Oracle’s builds can completely sidestep Oracle’s subscription costs. Gartner forecasts that by 2026, over 80% of Java applications will run on third-party (non-Oracle) Java runtimes – a jump from ~65% in 2023 – largely due to this licensing change​.
• Support Considerations: The main thing you pay Oracle for (aside from rights to use Oracle JDK beyond public updates) is support and updates. If you go with open-source Java, you’ll need a plan for receiving updates (security patches, bug fixes). Fortunately, many providers offer long-term support (LTS) for OpenJDK. For example, Amazon Corretto and Eclipse Temurin provide free updates for certain LTS versions, and companies like Azul or Red Hat offer paid support if needed, often at a lower cost than Oracle’s subscription.
• Compatibility: OpenJDK is the Java reference implementation. You can usually switch from Oracle JDK to OpenJDK builds with no code changes. The Java specifications ensure compatibility. (Oracle’s JDK and OpenJDK have minor differences, but for most standard applications, they are interchangeable.)
• Partial Usage to Reduce Scope: Some organizations choose a hybrid approach – e.g., limit Oracle Java to specific mission-critical systems (where they want Oracle’s direct support or certain commercial features) and migrate everything to OpenJDK. However, under the per-employee model, if any part of your organization uses Oracle Java, Oracle’s stance is that you should license the whole employee count. Oracle doesn’t easily offer “some users covered, some not” within one company. If you can isolate usage in a separate legal entity (with its contract), you could potentially license just that entity’s employees. This is complex, so many companies choose to completely remove Oracle Java usage to avoid enterprise-wide licensing.
• Timing and Updates: If you plan to drop Oracle Java, do so carefully. Make sure you have installed OpenJDK or other alternatives before your Oracle subscription expires or before you fall out of compliance. Oracle’s FAQ even advises moving to Oracle’s own OpenJDK builds (under GPL license) if you choose not to renew, to keep your apps running without interruption​.

4. Audit Readiness and Compliance: Oracle is reportedly becoming more aggressive in auditing Java usage with the new lucrative model. Gartner noted that 1 in 5 Oracle Java customers can expect a license audit by 2025​. Be prepared:

• Understand Your Installations: Discover where Oracle JDK or JRE is installed in your environment. Java can lurk in unexpected places (embedded in applications, installed by developers, included in third-party software). This inventory is crucial to decide whether to pay Oracle or remove/replace those instances.
• Ensure Third-Party Software Coverage: If you use third-party applications that include Oracle’s Java, confirm if the vendor’s license covers you. Some software vendors have distribution agreements that allow their customers to use Oracle Java as part of the product. If so, those users might not need to be counted under your Java SE subscription (the third party might be responsible for the Java license). Pitfall: assuming you’re covered when you’re not – always get confirmation from the vendor about Java licensing for their product​in writing.
• Don’t ignore Oracle’s Communications: Oracle has been known to send out “friendly” emails offering to discuss Java licensing. While these may be sales tactics to find non-compliance, ignoring them won’t prevent the issue. Suppose you receive such outreach and know you’re using Oracle Java without a subscription. In that case, it’s a red flag – consider proactively addressing it (either by licensing or migrating away) before an official audit comes.

Common Pitfalls and Issues to Watch For

Organizations navigating the Java SE Universal Subscription should be aware of several pitfalls:

• Under-counting Employees: It’s easy to mistakenly exclude certain groups (contractors, part-timers, interns, outsourced teams, etc.) from your count. All of these count as “employees” under Oracle’s definition. If you license fewer than your true total, you could be non-compliant and face penalties or true-up costs. Always use the broad definition when counting.
• Over-counting or Mis-scoping: Be careful which entity’s employees you count. The subscription is typically for a specific company or legal entity. If your conglomerate has multiple subsidiaries but only one buys the subscription for itself, you may not need to count employees of a sister company that isn’t using the software. However, if Java is used across the group, Oracle will push for licensing the whole group. Clearly define the scope of your license (which entities are included) and count accordingly to avoid overpaying or under-licensing.
• Assuming Only Developers or IT Staff Count: A common misconception is that you only pay for IT personnel or those using Java. Every employee and eligible contractor is counted, regardless of role​. That includes non-technical staff, executives, the cleaning crew, and everyone on the payroll if the contract covers the whole company. Don’t let the term “Java SE Subscription” mislead stakeholders into thinking it’s limited to technical users; budget for the full headcount.
• Sticker Shock at Renewal: If you’ve been on an old model and haven’t analyzed the new scheme, you might get a nasty surprise when an Oracle rep presents a renewal quote under the Universal Subscription. We’ve seen cases of 2x-5x cost increases​. Avoid this by modeling the costs well and preparing management for potential increases or the need to make changes.
• Paying for Shelfware: The new model can lead to “shelfware” – you might be paying for Java support for thousands of people who never use Java-based software. This is essentially wasted spend if those users derive no benefit. To minimize this, either negotiate the price down or reduce the actual use of Oracle Java so you can justify not buying it at all. It’s important to communicate internally that simply buying this compliance subscription can be inefficient if Java usage is limited.
• Believing Monthly Means Pay-As-You-Go: Oracle quotes a monthly per-user price, but they typically bill the full year up front. Don’t plan on a monthly true-up or easy cancellation mid-term; you’re signing an annual contract​. Also, you won’t see a refund if your employee count drops mid-year. Treat it as a yearly commitment.
• Letting Coverage Lapse Unprepared: If you decide not to renew Oracle’s subscription, remember that your rights to use Oracle Java binaries and receive updates end when the term ends. A pitfall is to let the subscription expire without replacing the Java runtimes in your environment. That could leave you running unsupported software (with no further security patches) or without a valid license. Always plan a migration to OpenJDK or another solution before your Oracle subscription expires, if you choose to discontinue it.
• Audit and Compliance Risks: As mentioned, Oracle is now enforcing Java licenses more strictly. Being unprepared for an audit – e.g., lacking records of where Java is installed, or having no formal count of employees – is a risk. Also, be cautious when communicating with Oracle. For instance, responding to Oracle inquiries with rough or high-level employee numbers without context might lock you into a certain license quote. Engage with Oracle carefully and with full knowledge of your usage and rights.
• Third-Party Java Use: Ensure clarity on Java usage via third-party products:
  • If a vendor bundles Oracle JDK in their product for you, get written assurance that their license covers it, so you’re not expected to count those users.
  • If a vendor uses OpenJDK, there’s no Oracle cost – but confirm that so you don’t double-pay Oracle for software you’re already getting license-free via another product.
• Not Evaluating Alternatives Timely: Some companies might sign up for the Oracle subscription out of fear or last-minute pressure, without exploring alternatives. This is a pitfall given the significant cost. Often, open-source Java can replace Oracle JDK with minimal effort, so failing to evaluate that option could mean unnecessarily spending large sums. Always assess whether you truly need Oracle’s Java (for technical reasons or support reasons) or if you could run on OpenJDK with little impact. Many have found the latter to be viable, saving millions in the long run.

Recommendations for Organizations

To navigate Oracle’s Java SE licensing in a cost-effective, compliant way, consider the following steps and best practices:

• Assess Your Java Usage Internally: Start with a thorough inventory. Identify where Java is used in your environment – applications, servers, desktops, build systems, etc. Determine which versions and distributions (Oracle vs OpenJDK vs others) are used. This assessment should also cover indirect usage (Java libraries or components included in other software). The goal is to understand how critical Oracle-provided Java is to your operations and how many users/systems truly rely on it. Engage application owners and IT teams to find any Oracle JDK installations. You may be surprised; some pockets of usage might have been under the radar. You can only decide on licensing or migration strategies​with a clear usage picture.
• Model the Costs Under the New Scheme: Armed with your total employee count and usage info, calculate what Oracle’s Universal Subscription would cost. Use the tiered pricing to estimate annual expense for your headcount (see table above or Oracle’s price list). This shows the “price of compliance” if you fully embrace Oracle’s model. Then compare that to the value Java brings to your IT budget. For many, seeing a number like “$1 million per year for Java” triggers a rethink. Also, if you previously paid under the old model, compare the new cost to what you paid before – quantify that 2x-5x increase if applicable, to inform decision makers. This cost modeling is crucial for planning, whether to budget for Oracle or to justify investment in migrating to alternatives.
• Consider Strategic Alternatives Early: If the cost looks high relative to usage, investigate alternatives before renewing or engaging Oracle. For each Java workload, evaluate if you can switch it to an OpenJDK distribution (nearly always yes, technically). Look into support options for those alternatives if your business requires SLAs for Java support. Many organizations have successfully transitioned to open-source Java to avoid new fees, a proven path in the industry. Additionally, consider if you even need to update Java versions frequently – if not, using free LTS binaries might suffice. The earlier you explore this, the more time you have to test and migrate critical systems away from Oracle code if needed.
• Plan Before Engaging Oracle Sales: If you need a Java SE subscription (or at least want to get a quote), prepare your data and strategy before contacting Oracle. Know your employee count (and how Oracle defines it) and have an internal position on what you’re willing (or not willing) to pay. Engaging your procurement or licensing specialists (or a third-party licensing advisor) can be wise to help formulate a negotiation plan. When talking to Oracle:
  • Emphasize if your Java usage is limited. Make it clear you’re paying for coverage for all employees, but only X% actually use Java. This sets the stage for requesting price consideration.
  • Ask about retaining the legacy model (if you have it)—e.g., “Can we renew our existing Java SE Desktop Subscription for another year instead of switching metrics?” Even if Oracle ultimately wants you on the new model, showing that you are aware of your options gives you leverage.
  • Be cautious about volunteering more information than necessary. Only discuss your environment in terms of what’s needed to get a fair deal or confirm compliance. Remember, Oracle reps might use any info to their advantage in a sale or audit.
• Negotiate Smartly if Subscribing: If you do proceed with Oracle’s Universal Subscription, negotiate the best terms:
  • Double-check your employee count before signing – ensure it’s accurate and excludes anyone not legally in scope. Once you sign, you’re committing to that number for the term.
  • See if you can get a better tier or price – for example, if you have just under a tier threshold, pushing slightly over (or negotiating as if you will) might get you into a lower per-employee rate. Or simply negotiate a discount percentage explicitly.
  • Multi-year term for price lock: If Java is a long-term need and you worry about Oracle raising prices, negotiating a 2-3 year term could be beneficial​. Just make sure you’re comfortable with the commitment.
  • Insist on clarity regarding how future headcount changes will be handled (e.g., if you grow, is there a pro-rated charge, or do you address it at renewal? Usually it’s at renewal, but it’s good to confirm any obligations to report interim changes).
• Implement Strong Software Asset Management: Going forward, treat Oracle Java like any other major software asset:
  • Track Java installations across your enterprise. Maintain records of which systems use Oracle Java versus OpenJDK. This helps ensure you remain compliant or can demonstrate that certain installations are non-Oracle (in case of an audit).
  • Maintain documentation of your employee count and how you arrived at the number. If contractors are counted, have lists or HR records that substantiate the count. This can be vital if Oracle ever disputes the numbers.
  • If you remove Oracle Java from some systems, document the date and replacement (e.g., “uninstalled Oracle JDK 8, deployed Temurin JDK 8 on Server X on 2024-05-01”). This creates an audit trail proving you took action to avoid Oracle licensing where it was not needed.
• Monitor Oracle’s Policy Updates: Oracle Java licensing has evolved frequently in recent years. Keep an eye on Oracle announcements or updates to terms. For instance, Oracle briefly had a “No-Fee Terms” license for certain JDK versions, which later changed. If Oracle adjusts the Universal Subscription model or offers new options, you want to know early. Likewise, track when new Java LTS versions come out and their licensing (Oracle might occasionally offer promotions around new versions).
• Leverage Third-Party Expertise if Needed: If your organization is large or your Java usage is complex, consider consulting with third-party licensing experts or firms specializing in Oracle license management. They can provide benchmarks (how much other companies pay), negotiation tips, and technical guidance on migrating off Oracle software. Since Oracle’s model is unique (no other vendor charges for all employees for a developer tool/runtime like this), getting an external perspective can be valuable. Always ensure any advice is independent (customer-advocate) rather than from Oracle.
• Stay Informed on Java Alternatives: The Java ecosystem is broad. Aside from Oracle and pure open-source, vendors like Azul, IBM, Red Hat, Amazon, and Microsoft (all have their OpenJDK builds) might suit your needs. Some offer enhancements or additional tools. Keep an eye on what the community and industry are doing – many are shifting to these alternatives, and success stories can help you make the case internally that “we wouldn’t be the only ones to drop Oracle Java.” A majority of organizations already use non-Oracle Java for many applications.

Conclusion

Oracle’s Universal Subscription for Java SE has introduced a simplified but potentially costly model, taxing organizations based on size rather than actual Java usage. SAM managers and licensing professionals must adapt to this change by thoroughly understanding their Java footprint and exploring all options to optimize spend. The key is to be proactive: assess and rationalize your Java usage, make informed decisions about whether to pay Oracle or migrate, and negotiate or plan accordingly. By doing your homework and keeping the organization’s best interests at heart, you can avoid overspending and ensure compliance while keeping your Java applications running smoothly, whether with Oracle’s support or without it.