Oracle Utilities CC&B 2.x to the 25.x release line
Cohash upgrades Oracle Utilities Customer Care and Billing (CC&B) from 2.x releases to 25.4. We confirm which of Oracle's tested one-step paths applies, inventory custom algorithms, business objects, scripts and cloned batch controls, run a technical upgrade on a production copy for timings, and compare full bill cycles on old and new versions before cut-over between cycles.
- 01Path and starting point
- 02Custom object inventory
- 03Technical upgrade on a copy
- 04Parallel bill cycles
- 05Cut-over between cycles
The story
Told without the client's name or anything that could identify them.
A water utility's billing team ran CC&B on a 2.x release with years of custom algorithms and cloned batch controls built up, and framework patches kept breaking code nobody had documented. Oracle published CC&B 25.4 on 9 September 2025 with tested one-step paths from five starting points, so the first job was checking the exact patch level against that list. We inventoried custom objects, upgraded a full production copy to get real conversion timings, and ran bill cycles on both versions until every variance was explained. The production upgrade then ran between bill cycles with a tested rollback point, followed by hypercare through the first full month of billing.
why it was urgentOracle published CC&B 25.4 on 9 September 2025, alongside Oracle Utilities Application Framework 25.4. The release notes list tested one-step upgrades from five starting points: 2.9.0.1.1, 2.9.0.0.0, 2.8.0.0.0, 2.7.0.3.0 and 2.6.0.1.0. If you're on any other 2.x level, you need an extra hop. Better to find that out now than halfway through the project.
- openCC&B sits on a 2.x level Oracle didn't test as a starting point, so there's an extra hop.
- recurringOver many releases, custom algorithms and cloned batch controls have piled up into the hundreds.
- blockedBill cycles already run close to the batch window at seasonal peaks.
- openFramework patches break custom code that nobody documented.
The estate, before and after
Before: CC&B 2.x carrying years of clones
Meter reads and customer changes fed CC&B 2.x, where custom algorithms and cloned batch controls shaped the bill cycle. At seasonal peaks, bill runs sat right up against the batch window.
Read the diagram as text
- Meter reads → CC&B 2.x: usage
- Customer service → CC&B 2.x: account changes
- Custom algorithms and clones → CC&B 2.x: custom logic
- CC&B 2.x → Bill cycle batch: bill cycle
- Bill cycle batch → Customer bills: bills
- Bill cycle batch → General ledger: GL extract
After: CC&B 25.4 with proven bill cycles
CC&B 25.4 runs on OUAF 25.4 with only the extensions the inventory decided to keep. Parallel bill cycles proved the outputs first, and the production upgrade ran between cycles.
Read the diagram as text
- Meter reads → CC&B 25.4: usage
- Customer service → CC&B 25.4: account changes
- Reworked extensions → CC&B 25.4: custom logic
- CC&B 25.4 → Parallel bill cycle compare: test cycles
- Cut-over runbook → CC&B 25.4: production upgrade
- CC&B 25.4 → Customer bills: bills
- CC&B 25.4 → General ledger: GL extract
How we run it, phase by phase.
5 phases take you from Oracle Utilities CC&B 2.x to Oracle Utilities CC&B 25.4 on OUAF 25.4. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Path and starting point
Check your exact release and patch level against the 25.4 tested paths. If you need an intermediate hop, the Database Administrator's Guide tells you how to plan it.
- phase 02
Custom object inventory
List algorithms, business objects, scripts, zones, batch controls and interfaces. Retire clones that base 25.4 now covers, and flag code touched by OUAF changes.
- phase 03
Technical upgrade on a copy
Take a full production copy through the upgrade. Record the conversion run times, then fix what fails to compile, load or run.
- phase 04
Parallel bill cycles
Run selected bill cycles on both versions and compare bills, financial transactions and GL extracts line by line until every variance is explained.
- phase 05
Cut-over between cycles
Run the production upgrade between bill cycles with a tested rollback point, then hypercare through the first full month of billing.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
The upgrade path matches Oracle's tested list
We checked the exact release and patch level against the 25.4 tested paths before the plan was signed. Where an intermediate hop was needed, it was planned from the Database Administrator's Guide.
- result 02
Every custom object has a decision
We marked every algorithm, business object, script, zone, batch control and interface as retire, keep or rework. Clones that base 25.4 makes redundant are gone.
- result 03
The cut-over window is based on measured timings
Conversion run times come from upgrading a full production copy. So the cut-over window is based on how long the large tables really took.
- result 04
Bills match across versions, or the difference is explained
We compared selected bill cycles line by line, on bills, financial transactions and GL extracts, and recorded a cause for every variance.
- result 05
Production upgrade fits between bill cycles
The runbook puts the upgrade between bill cycles, with a tested rollback point. Hypercare runs through the first full month of billing.
Risks we plan for
-
Starting from an untested release
If you assume a one-step path Oracle never tested, you'll find the extra hop mid-project. So we check the exact patch level before anyone signs the plan.
-
Cloned base objects
Cloned algorithms and batch controls miss base fixes and break quietly after the upgrade. Finding them is often the biggest piece of work.
-
Conversion time
Large tables can take longer to convert than the cut-over window allows. Timings from a production copy set the real window.
-
Billing differences found late
Rounding, proration and rate edge cases show up only on real bills. Parallel cycles with line-by-line comparison catch them before customers do.
Where AI helps, and where it needs guardrails
Oracle's CC&B 25.4 release overview names no AI features, so the useful AI work here is on the upgrade itself. We use coding agents to read custom algorithms and scripts, flag clones of base objects and draft retest notes, with engineers reviewing every finding. Agents get read-only access to a code export and masked billing samples, never to production customer data.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- document01
Upgrade path decision based on your exact release and patch level
yours to keep - inventory02
Custom object inventory with retire, keep or rework per item
yours to keep - document03
Conversion timings from a technical upgrade of a production copy
yours to keep - document04
Parallel bill cycle comparison with every variance explained
yours to keep - runbook05
Cut-over runbook timed between bill cycles
yours to keep
Platforms and services on this move
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Can we go straight from CC&B 2.7 to 25.4?
From 2.7.0.3.0, yes, per Oracle's 25.4 release notes. From any other 2.7 level you first move to a tested starting point, and we check your exact patch level before we plan.
02How long does the upgrade take?
It depends on the number of custom objects and interfaces, the size of the database and how many bill cycles you want to compare. We size it after the inventory and a technical upgrade on a production copy.
03Does this apply to Customer to Meter as well?
Yes. Customer to Meter also moved to 25.4 on the same framework release. Same approach, with meter data management testing added.
04Do you work on Customer Cloud Service?
Yes, on configuration, integration and data. On the cloud service Oracle delivers releases, so the work shifts to regression testing and keeping extensions compatible.
Often on the same roadmap
AD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case study
Apache Airflow 2 to Airflow 3
Upgrading self-managed Apache Airflow 2, now past end of life, to Airflow 3, and fixing removed features, auth and scheduling changes before DAGs move.
read the case studyAuth0 Rules and Hooks to Actions before end of life
Rewriting Auth0 Rules and Hooks as Actions before their 18 November 2026 end of life, with token claims compared before and after each change.
read the case study569540cf - 01Oracle: CC&B 25.4 release overview and supported upgradesdocs.oracle.com ↗
- 02Oracle: Customer to Meter 25.4 release notesdocs.oracle.com ↗
- 03Oracle Help Center: Customer Care and Billing releasesdocs.oracle.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it