A Canadian municipality responsible for core city services, public safety, library systems, and utility operations had a familiar Oracle Java problem: Java was present across the environment, but no one had a defensible, current picture of which installations were actually risky, which were already covered, and which could be migrated away from Oracle altogether.
That uncertainty became more serious after Oracle’s Java subscription model shifted toward an employee-based metric. An initial licensing-position workbook prepared in late 2023 showed a worst-case exposure tied to 1,499 employees. For leadership, that turned Java from a technical cleanup issue into a potential city-wide commercial event.
UMS was engaged through Dell to replace that broad assumption with facts. Across the review and refresh cycles, UMS classified 216 Java endpoints, showed that 193 were already covered by legacy BCL terms or non-Oracle/OpenJDK distributions, and narrowed the real follow-up set to 23 endpoints, with 10 server-side systems receiving explicit remediation recommendations. Instead of reacting to a theoretical city-wide licensing burden, the municipality got a targeted action plan it could actually execute.
The Challenge
The municipality’s Oracle Java footprint had accumulated the way most public-sector estates do: organically, over time, across different departments and technology eras. Java showed up in desktop installs, infrastructure components, application servers, and embedded dependencies that were not centrally tracked in one place.
Three issues made the situation urgent:
- Oracle’s licensing model created a large theoretical exposure — The initial 2023 baseline modeled the issue against 1,499 employees under Oracle’s Java employee metric, even though the actual technical problem was much narrower.
- The environment included mixed versions and mixed rights — Some installations were still covered by older Binary Code License terms, some were running GPL/OpenJDK builds, and some appeared to fall under Oracle Technology Network-era rules that required closer review.
- Critical city systems could not be disrupted — The Java footprint touched operational systems associated with libraries, public safety, Azure integration workloads, Cisco security tooling, and PeopleSoft-related functions. The municipality could not afford a blunt, one-size-fits-all response.
The internal team had the institutional knowledge to explain what these systems did. What it did not have was the time or licensing specialization to turn raw scan data, contract history, and application context into a clean decision framework before Oracle sales or compliance pressure escalated.
How UMS Solved It
UMS approached the work as a licensing-triage exercise, not just a device scan. The goal was to separate theoretical exposure from actionable risk and give the municipality a path that balanced remediation speed with operational safety.
Step 1: Build the baseline UMS first gathered Oracle entitlement records, support-renewal information, hardware details, Java publisher data, versions, updates, install paths, and VMware context. The initial review established the severity of the issue: without deeper analysis, the municipality could be viewed through the lens of Oracle’s employee metric rather than a smaller set of systems that actually warranted action.
Step 2: Classify every endpoint by coverage During the refreshed Q4 2024 reconciliation, UMS organized the Java estate into a coverage model the city could use for decision-making:
| Category | What UMS Found | Why It Mattered |
|---|---|---|
| BCL-covered endpoints | 165 | Older covered installations could be separated from current commercial risk |
| GPL/OpenJDK endpoints | 28 | Non-Oracle distributions did not need the same commercial response |
| OTN-era endpoints needing follow-up | 23 | This became the real shortlist for deeper action |
That one step changed the conversation. Instead of debating Java as an abstract city-wide issue, leadership now had a defensible breakdown showing that the majority of the estate was not an immediate Oracle subscription problem.
Step 3: Prioritize remediation at the system level UMS then moved from classification to targeted recommendations. In the server baseline, 10 systems were called out with explicit remediation guidance. Those recommendations were specific to the workload:
| System Type | Example Workloads | Recommended Action |
|---|---|---|
| General server installs | ONTARIO, SIMCOE, SVAP240P | Move to OpenJDK or a supported alternative such as Azul |
| Microsoft-integrated workload | Azure ADF Integration Runtime | Switch to a Microsoft-supported or other OpenJDK path |
| Security tooling | Cisco Firepower-related host | Move to a Cisco-supported OpenJDK option |
| Public-safety application stack | FireCAD systems | Validate versioning because some instances may no longer require Java |
This mattered because the answer was not “buy Oracle for everyone.” The answer was different for each affected system depending on version, workload, and bundled rights.
Step 4: Extend governance beyond the report UMS did not stop at a baseline deck. An executed September 16, 2024 statement of work added a refreshed Oracle Java reconciliation, an updated financial risk assessment, and ongoing teleconference and email support through September 30, 2025. That gave the municipality a way to keep validating findings, handle questions from stakeholders, and avoid drifting back into uncertainty after the initial remediation phase.
Results
| Metric | Before | After | Impact |
|---|---|---|---|
| Oracle Java exposure basis | Worst-case model tied to 1,499 employees | 23 endpoints isolated for deeper review | 98.5% narrower action scope |
| Java estate visibility | Fragmented and department-specific | 216 endpoints classified | Defensible city-wide baseline |
| Endpoints cleared from immediate commercial concern | Unknown | 193 endpoints identified as BCL or GPL/OpenJDK | Majority of estate ruled out |
| Server remediation plan | No prioritized list | 10 servers received explicit next-step guidance | Actionable technical roadmap |
| Ongoing support | One-time review risk | Support in place through Sept. 30, 2025 | Governance beyond the baseline |
The most important outcome was not a generic “savings estimate.” It was decision-quality. UMS converted a vague Oracle Java concern into a bounded, evidence-backed worklist the municipality could defend internally and act on without disrupting critical systems.
Key insight: With Oracle Java, the biggest win often comes before procurement. If you can shrink the issue from an employee-wide commercial assumption to a named set of systems, you negotiate and remediate from a position of control instead of fear.
Additional Outcomes
- Protected critical operations from blunt remediation — Library, utility, public-safety, and infrastructure workloads were assessed in context instead of being swept into a blanket licensing response.
- Created multiple response paths — The municipality could choose among OpenJDK migration, version validation, vendor-supported alternatives, or limited Oracle coverage depending on the system.
- Established a repeatable governance model — Ongoing support gave the IT team a way to review future Java questions before they turned back into city-wide uncertainty.
The broader lesson applies well beyond this municipality. Oracle Java exposure is often overstated at the beginning because the first model is built from incomplete information. Once deployments are mapped to versions, application dependencies, and alternative coverage, the real problem is usually smaller, more specific, and far more manageable than it first appeared.
See also: How a federal agency cut M365 spend by 54% in 2 months for another example of UMS turning a sprawling software problem into a targeted action plan.