Key Takeaways

• Safe COBOL-to-Java modernization in regulated billing systems happens one algorithm at a time inside a runtime that can host both languages side by side, not through a scheduled cutover of the whole system.
• We did parallel runs that fed the same production input to both the COBOL and Java versions of an algorithm, then did a field-by-field diff of the outputs; that was the real gate for going live, not code review or staging-environment testing, which we also did.
• When choosing which algorithms to convert first, we weighed billing impact, batch volume, and calculation complexity together. We started with moderate-risk candidates to prove the validation and rollback process before moving on to the highest-volume and highest-impact routines.
• COBOL’s packed decimal math and round-off rules don’t behave the same as Java’s numeric types, which led to silent calculation differences at that boundary, which in turn we only caught by putting in that testing.
• Multi-year incremental conversions succeed or fail on unglamorous engineering discipline — JUnit coverage for every converted algorithm and code review against framework standards — because that discipline is what lets several engineers convert algorithms concurrently without regressions compounding across releases.

Executive Summary

Utility metering systems are putting real money against tight regulatory frameworks and also still, for the most part, run on COBOL under new Java-based platforms. In this report, we look at how to modernize that COBOL in stages, one billing function at a time in production without a cutover window. We present a multi-release-cycle COBOL-to-Java conversion effort within Oracle Utilities Application Framework (OUAF) based Customer Care Billing systems. We cover how OUAF’s algorithm plug-in structure allows COBOL and Java versions of billing logic to coexist during migration, how to control a single function’s impact, and how to do parallel run validation that runs COBOL and Java outputs against the same production data before going live. Also, we present a decision framework for the order of conversions and team-wide and year-long takeaways on how JUnit coverage and code review processes play a key role as a conversion effort grows within a team and over time.

Introduction

COBOL has outlived several generations of technology that were supposed to replace it. The U.S. Government Accountability Office has documented this more than once. In its 2023 review of ten of the federal government’s most critical legacy IT systems, it found that several were still running on COBOL, with ages ranging from roughly eight to fifty-one years, while their continued operation collectively cost hundreds of millions of dollars each year [2]. A follow-up 2025 GAO report on eleven critical legacy systems found systems as old as sixty years — including Department of the Treasury systems still running on COBOL and Assembly — and explicitly flagged a shortage of programmers skilled in these older languages as a modernization risk [3]. Regulated utility billing sits in the same category of system: not glamorous, rarely visible to the public, and absolutely intolerant of being wrong.

That intolerance is the whole story. A utility bill is a legal artifact computed against tariffs filed with a regulator, tied to metered consumption, and subject to audit. If, in a batch billing run, a different rate tier is calculated or a batch of accounts is rounded in a different way, the damage is not in the form of a failed API call; it is in the form of disputed bills, manual corrections, and issues with regulatory bodies. We don’t have a real strategy for getting rid of the COBOL in a billing platform. The logic has to be re-done algorithm by algorithm, validated against live data before each transition, and we must have a working rollback at all times.

Legacy systems grow to be “too fragile to change and too important to get rid of” [10], which a later report on modernization put forth shows that legacy and modernized components run together instead of in a single cutover [11]. Martin Fowler’s Strangler Fig pattern took this out into the world at large -- we grew the replacement around the old system here and there; we migrated one piece of function at a time, by the time you know the legacy system has nothing left to do [1]. In this article, we do so at the finest grain -- the individual billing algorithm -- within a platform, Oracle Utilities Application Framework (OUAF), which happens to make that finesse possible. The lessons we see play out in any legacy environment which has a similar feature for running two implementation languages side by side: mainframe COBOL/Java bridges,.NET/COM interop layers, or JNI-based hybrids.

Background

OUAF underlies Oracle's Customer Care & Billing (CC&B), Revenue Management & Billing (RMB), and Customer-to-Meter (C2M) product lines, widely deployed for utility billing. The framework organizes customizable business logic into “algorithm spots” — defined extension points with typed inputs and outputs — into which an implementation is plugged as a configured “algorithm instance” [12]. Current OUAF SDK documentation describes this plug-in model in terms of Java algorithm components, complete with annotations, an invoke() method, and JUnit-based testing as the expected verification step [12]. Tellingly, that same documentation still carries a section on “Converted COBOL Programs” — a direct trace of the framework's own history of migrating COBOL business logic into Java algorithms across successive releases, the kind of multi-version conversion effort this article is grounded in.

That history matters because it is the mechanism, not a workaround, that makes incremental modernization possible: an algorithm spot does not care whether the logic behind it was written in Java or reached the framework through a COBOL run unit, only that it honors the same inputs and outputs. That separation is what allows a billing platform is able to run a mix of converted and not yet converted algorithms in the same production environment at times across many major version upgrades, without each algorithm having to change at the same time. 

This issue is specific to billing algorithms, which we see as a very complex set of financial calculations that are not at all simple one-off formulas. A single customer’s bill may include rate-tier lookups, proration across the billing period, minimum charge floors, surcharges, and rounding rules; each may, in fact, be a separate algorithm which the framework’s calculation engine puts together. Get any one of those elements wrong, even a little, and the error will go out in a live invoice to an actual customer under a tariff that a regulator has approved. There is no “quick fix and call it a day” type of solution as there may be with a non-financial calculation.

Problem Analysis

The first issue is to determine which algorithms’ responsibilities stop and start where they begin and end. Legacy COBOL systems which do not follow a strict module structure often use the same copybooks and working-storage variables within what appears to be independent processes. An algorithm that looks like a stand-alone entity within the framework may on closer look, turn out to depend on the action of a different program that runs prior in the same batch. Unraveling which programs depend on which has to be done before any Java is written, because if we get the boundaries wrong, the converted algorithm will work in a lab environment but fail in production.

The issue at hand is numeric semantics. COBOL’s native decimal, which includes packed decimal (COMP-3) fields as handled by the COBOL language standard [15], does not by default map to Java’s numeric types. Java’s double is a binary float, which is the wrong choice for currency math altogether; even BigDecimal, if used carelessly, may apply a different rounding mode or scale than what the COBOL program’s ROUNDED clause specified. This is the type of issue that a functional test which uses “reasonable” input values will not bring to light; instead, they present themselves on certain tier interfaces or in atypical proration windows. Each conversion project must put forward that COBOL-to-Java arithmetic parity is a first-class issue, not a code review detail.

To make that risk concrete: consider a hypothetical two-tier residential rate schedule — a lower per-unit rate up to a usage threshold, a higher marginal rate above it — applied to a customer whose billing period spans a mid-cycle rate change and therefore requires proration. A COBOL program that uses COMP-3 fields with an explicit ROUNDED clause may compute the tier-1 charge, tier-2 charge, and proration factor separately, rounding each result to the nearest cent before adding them to the total. A line-by-line Java translation that carries fractional cents through all three calculations and rounds only the final sum can, for some combination of usage level and proration boundary, differ from the COBOL result by a fraction of a cent. Which approach is more “correct”—rounding after each step or only once at the end—is beside the point. During conversion, the target is exact behavioral equivalence with the system currently issuing bills, not conformity with an abstract specification. A discrepancy of a fraction of a cent, repeated across a large customer base, turns into a genuine reconciliation problem. The same is true when a revised rate schedule produces totals that differ slightly from those generated by its COBOL predecessor; sooner or later, a regulator or internal auditor is likely to ask why. A quick check of whether the final total “looks right” will miss the issue. It appears only when every intermediate value is compared field by field, rather than just the amount on the final bill.

Legacy COBOL billing systems we see are also put through less testing than what we see today. Years of incremental patches which implement business rules that often do not have any documented requirements the original which they are based on may have disappeared. The only reliable way to determine if the business rules are correct is to run the live program. That has a direct implication for proving correctness during conversion: the target is not a specification; it is the existing program's actual output.

Architecture and Design

The resulting architecture is a strangler pattern applied at the algorithm level rather than the service or module level. For each of the algorithms, we present how it looks up which of the configured instances of that algorithm to use and then triggers the action that is implemented behind it. In the past, this was a COBOL program accessed via the framework’s language bridge, and now a Java class which implements the same spot’s interface after it has been converted over. Both of these implementations put out the same results and have the same input requirements, so the router does not need to be aware of which language is being used on the other side.

Figure 1 illustrates this dispatch mechanism, including the exact configuration swap point where an algorithm instance is cut over from the COBOL implementation to its Java replacement.

Figure 1: Algorithm plug-in routing. The batch/algorithm driver invokes an algorithm spot, which is dispatched to either the legacy COBOL implementation or the new Java implementation based on the active configuration in the algorithm registry—the swap point where cutover happens.

Two design decisions make this safe to operate over years. First, cutover is a configuration change, not a code deployment: the COBOL-backed algorithm instance and its Java replacement can both exist in the configuration at once, with only one marked active. Promoting the Java version out or rolling back to COBOL is a controlled config switch, which is not a full deploy; this is key in a scenario of a fallback within a billing cycle under time pressure. Also, we see that conversions are versioned against the platform’s release cycle. In this OUAF setting, we had COBOL programs which we converted to Java across successive framework upgrades from one major CC&B release to the next and also for the release after that, which meant each converted algorithm had to be revalidated for its own correctness as well as against the framework’s changing runtime behavior at each version boundary.

The general lesson extends past OUAF: In any legacy setting that has a bridge between two programming languages which at a whole provide the same interface a mainframe COB which translates between COBOL and Java, a.NET/COM which acts as an interface between those languages, a JNI which puts a C lib into a Java environment -- we see this same pattern. The interface is what you migrate, not the full codebase.

Implementation

Selecting the first candidate. Not every algorithm is a good first conversion. Practical prioritization rests on three factors: the algorithm’s blast radius—meaning the number of customer accounts or bill types routed through it—along with batch volume, including how often it runs and at what scale, and calculation complexity, reflected in the number of branches, tiers, and edge cases it contains. Early candidates are usually mid-complexity, moderate-volume algorithms — complex enough to prove the process works, contained enough that a mistake is recoverable. The highest-blast-radius, highest-complexity algorithms are converted later, once the parallel-run and rollback process has already been proven on lower-stakes logic.

Parallel-run validation. The core discipline is running the COBOL and Java implementations of the same algorithm against identical production data and diffing their outputs before the Java version is ever made authoritative. The same idea underlies the parallel-run pattern described more broadly in migration engineering: invoke both implementations, compare their results, and promote the new one only after confidence in equivalence has been established [7]. Shadow-validation methods used in other migrations follow a similar approach; a shadow copy operates alongside production and is checked continuously for consistency before cutover [9]. For a billing algorithm, that means taking a representative slice of real account data—synthetic cases alone fail to capture the edge cases that legacy systems accumulate over years—running it through both implementations, and comparing every output field. The final bill total is not enough. Two offsetting errors can produce the same total, just as they do in the tier-and-proration example above. Differences get root-caused one by one; only after a run produces zero unexplained differences across enough billing cycles does the algorithm become a cutover candidate.

Figure 2 shows this parallel-run validation workflow end to end, from production input through the sign-off gate that authorizes cutover.

JUnit test design. Every converted algorithm gets a JUnit suite exercising its individual calculation paths and edge cases — tier boundaries, proration at period start and end, minimum-charge floors, negative-usage corrections — rather than only the typical case. This mirrors the framework's own documented expectation that algorithm components are unit-tested with JUnit [5], [12], and aligns with the broader discipline codified in test-process standards like ISO/IEC/IEEE 29119, which treats test design and documentation as first-class artifacts [6]. These suites prove the conversion correct at delivery and catch regressions the next time the framework is upgraded.

Code review and standards compliance. As a conversion project scales beyond a few engineers, code review for consistency with framework practices, proper use of algorithm annotations, defensive error handling, and SQL that does not impair batch performance is what enforces quality across algorithms that may be developed by different people at different times. This is what prevents an inconsistency introduced in one converted algorithm from becoming a second, unrelated defect discovered later in production.

Performance and Scalability

Conversion sequencing should also be informed by batch volume. Algorithms used by a large segment of customers in every billing cycle should be subject to early and in-depth performance validation as compared to low-volume and occasional use algorithms, because a small drop in performance of a high-volume algorithm may turn an overnight batch process into a missed deadline. Parallel-run validation should be exercised at full production data volume, not a sample, before cutover — a converted algorithm that matches COBOL output correctly but runs meaningfully slower at scale is not yet ready, even if its calculations are exact.

Performance regressions in a straightforward COBOL-to-Java line-by-line port tend to hide in a few predictable places. A COBOL routine's implicit access to already-loaded working-storage data can become, in a careless Java translation, a fresh database or cache lookup executed once per algorithm invocation — invisible in a parallel-run sample of a few thousand accounts, and expensive once the same algorithm runs against an entire customer base every billing cycle. The practical response is to profile the converted algorithm under representative batch load before cutover, not just validate its output correctness, and to treat a converted algorithm that is behaviorally correct but meaningfully slower at full volume as not yet cutover-ready — the same discipline applied to correctness, applied instead to cost.

Security Considerations

Billing logic changes deserve the same rigor as changes to a payments system, because in effect that is what they are. Access to modify or promote an algorithm instance in production should follow least-privilege principles — the ability to change which implementation is active for a given algorithm spot should be restricted to a small, defined set of roles, separate from the broader development team that writes and tests candidate code [13]. In each case of configuration change who made it, what it was changed from to what, and when- we will have an audit trail, also for the fact that billing issues may not present until months after the bill was sent out and also for the chance that a regulator or internal auditor may want to go in and see what exactly the calculation logic was at a given time. This maps directly onto the access-control and audit-and-accountability control families in frameworks like NIST SP 800-53, a reasonable baseline for financially critical configuration changes even outside a formal compliance mandate [14].

Separating between which team members are allowed to author and JUnit test a put forward implementation (a large group of developers) and which are allowed to push a production algorithm live (a small, controlled group), and also treating that push to live as a typical auditable config change instead of a special case: we document who did the change, what from to what, and the date of the change through the same config change audit that the platform uses for other prod config changes; we do not maintain a separate log for algorithm cutovers.

Operational Excellence

Once a converted algorithm goes live, monitoring needs to watch its outputs, not just its uptime. Comparison of batch run results to that of prior cycles’ statistical baselines volume of bills produced, distribution of calculated amounts, count of which is an exception puts to light a faulty algorithm before we wait for customer feedback. Rollback needs to be rehearsed, not theoretical: reverting the algorithm instance's configuration back to the COBOL implementation and rerunning the affected batch job should be a known, tested procedure, not worked out for the first time during an incident.

A rollback rehearsal has to answer a harder question than whether the configuration can be flipped back: if the Java implementation already processed part of a batch before an anomaly was caught, does reverting the algorithm instance and rerunning cleanly reprocess only the affected accounts, or does it risk double-billing or double-crediting accounts that already completed successfully under the Java path? Working that out in a drill, before it is needed live, is what separates a rollback that is actually safe from one that is merely configured. Batch failures are usually identified and fixed through the platform’s built-in monitoring and restart or rerun tools. That makes configuration-based cutovers preferable to code deployments operationally: if a cutover goes wrong, it can be rolled back using the same tools as a routine batch failure, without requiring an emergency deployment.

Trade-offs and Limitations

Incremental, algorithm-by-algorithm conversion is neither free nor automatically the right choice. For smaller systems with modest transaction volumes or no regulatory exposure, the costs of parallel-run infrastructure, dual-language tooling, and a migration sequenced over several years may outweigh the risk of a big-bang rewrite. In those situations, a conventional rewrite-and-cutover approach is simpler and less expensive. Even when incremental conversion makes sense, it brings a substantial burden: for the entire multi-year migration, teams must maintain two toolchains—a COBOL compiler and runtime alongside a Java build and test pipeline—and keep engineers proficient in both. The latter burden grows over time because COBOL expertise is becoming scarcer. The GAO has explicitly identified the shortage of programmers skilled in older languages such as COBOL as an operational risk for organizations that still depend on them [3]. A migration stretching across years has to plan for fewer people being available to read the remaining COBOL by the time the last algorithms are converted — itself an argument for deliberate sequencing rather than converting the easiest algorithms first and letting the hardest ones drift indefinitely.

Production Lessons Learned

Converting our COBOL programs to Java over the years of Customer Care Billing upgrades, we identified issues which presented themselves as we went along. What we thought were simple translations of algorithms from theory to code proved to be more complex than we expected, because our COBOL codes relied on framework inner workings or shared copybook structures which varied between platform releases -- which in turn meant that a conversion which we thought was good for one version of the platform required a second look after the next upgrade. That is a direct consequence of doing this work across multiple release cycles rather than once: each version boundary is a chance for a previously-converted algorithm's assumptions to quietly stop holding.

JUnit coverage written for converted algorithms mattered more after the fact than at the moment of conversion. Its immediate value is proving the conversion correct; its longer-term value, clear only over repeated upgrade cycles, is catching a regression introduced by an unrelated framework change before it reaches a production billing run. Code review discipline followed a similar arc: early on, with one or two people doing the work, informal consistency was manageable. As we grew, more algorithms adopted the framework, more contributors joined the project, and code drops became more frequent; what held quality together was a consistent application of framework standards, refined SQL patterns, and uniform error handling, which we achieved through code review. Without that discipline, each converted algorithm tends to reflect whoever happened to write it — exactly the inconsistency that made the original COBOL hard to maintain in the first place.

Best Practices

• Treat the algorithm, not the module or the batch job, as the unit of migration — it is the smallest boundary the framework can cut over independently.
• Build out your parallel run validation prior to writing the conversion code, not after; the validation harness is what makes each subsequent conversion trustworthy. 
•  Compare each intermediate output an algorithm produces, which is to say any issues in earlier stages, not just the result, since equal results at the end may be hiding issues in the steps leading up to it.
• Write out your COBOL-to-Java arithmetic parity tests to explicitly test boundaries, proration edges, and rounding; do not count on “typical case” tests to bring those out. 
• At cutover, make that a config change with a practiced rollback path, no one-way code deployment.
• Re-validate previously converted algorithms at each platform version upgrade rather than assuming past validation still holds.
• Enforce code review against consistent framework standards as the team and the converted-algorithm inventory both grow.

Future Outlook

Of the eleven critical federal systems, most modernization plans extend over years into the future; also, many agencies still do not have full plans, and we see that the workforce issue for COBOL and related languages comes up time and again as an issue [3]. That is a consistent picture of what algorithm-level conversion in a live billing platform is to report: in release cycles and years, what is gating us is validation, which in turn is a result of care taken rather than speed. Tooling for automatic COBOL to Java translation is improving and will probably reduce the manual rewriting that is required. It will not remove the need for parallel-run validation, though — however, a Java replacement is produced, proving it matches the COBOL original's behavior on real production data remains the non-negotiable step before it can be trusted with real bills.

Conclusion

Regulated utility billing is an unusually unforgiving environment for legacy modernization, precisely because the logic being replaced produces numbers that become legal, auditable financial records the moment a bill goes out. That which is proscribed is the big-picture rewrites, and what in turn is rewarded is a design that has two programming languages which, at the same time, put on a stable interface, as each algorithm is at a time refactored and proven against live performance before it is put into production. Oracle Utilities Application Framework's algorithm plug-in model is one instance of a pattern that recurs anywhere a legacy system has to keep running while it is rebuilt underneath: bound the unit of change tightly, validate it against the system it is replacing rather than against a specification, and make the switch reversible. We don’t see that as cutting-edge engineering. We see that as a methodical approach which plays out over years’ worth of work, which is what financial legacy systems’ success requires.

References

[1] M. Fowler, “StranglerFigApplication,” martinfowler.com, Aug. 22, 2024. [Online]. Available: https://martinfowler.com/bliki/StranglerFigApplication.html

[2] U.S. Government Accountability Office, “Information Technology: Agencies Need to Continue Addressing Critical Legacy Systems,” GAO-23-106821, May 2023. [Online]. Available: https://www.gao.gov/products/gao-23-106821

[3] U.S. Government Accountability Office, “Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems,” GAO-25-107795, 2025. [Online]. Available: https://www.gao.gov/products/gao-25-107795

[4] Agile Alliance, “Introduction to the Technical Debt Concept,” agilealliance.org. [Online]. Available: https://www.agilealliance.org/introduction-to-the-technical-debt-concept/

[5] JUnit Team, “JUnit 5,” junit.org. [Online]. Available: https://junit.org/junit5/

[6] ISO/IEC/IEEE 29119-1:2013, Software and Systems Engineering — Software Testing — Part 1: Concepts and Definitions, International Organization for Standardization, 2013.

[7] Zalando Engineering, “Parallel Run — A Migration Technique in Microservices Architecture,” engineering.zalando.com, Nov. 2021. [Online]. Available: https://engineering.zalando.com/posts/2021/11/parallel-run.html

[8] Microsoft, “Strangler Fig pattern,” Azure Architecture Center, learn.microsoft.com. [Online]. Available: https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig

[9] InfoQ, “Shadow Table Strategy for Seamless Service Extractions and Data Migrations,” infoq.com. [Online]. Available: https://www.infoq.com/articles/shadow-table-strategy-data-migration/

[10] S. Comella-Dorda, K. Wallnau, R. C. Seacord, and J. Robert, “A Survey of Legacy System Modernization Approaches,” CMU/SEI-2000-TN-003, Carnegie Mellon Software Engineering Institute, Apr. 2000.

[11] R. C. Seacord, S. Comella-Dorda, G. Lewis, P. Place, and D. Plakosh, “Legacy System Modernization Strategies,” CMU/SEI-2001-TR-025, Carnegie Mellon Software Engineering Institute, 2001.

[12] Oracle Corporation, “Plugging in Algorithms,” Oracle Utilities Application Framework SDK Developer's Guide, docs.oracle.com. [Online]. Available: https://docs.oracle.com/en/industries/energy-water/framework/254/sdk-dev-guide/Topics/SDK_Plugging_in_Algorithms_1.html

[13] OWASP Foundation, “Least Privilege Principle,” owasp.org. [Online]. Available: https://owasp.org/www-community/controls/Least_Privilege_Principle

[14] National Institute of Standards and Technology, “Security and Privacy Controls for Information Systems and Organizations,” NIST Special Publication 800-53, Rev. 5, Sept. 2020.

[15] ISO/IEC 1989:2023, Information Technology — Programming Languages, Their Environments and System Software Interfaces — Programming Language COBOL, International Organization for Standardization, 2023.

[16] Amazon Web Services, “Seamlessly migrate on-premises legacy workloads using a strangler pattern,” AWS Architecture Blog. [Online]. Available: https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/

[17] M. Fowler and K. Beck, Refactoring: Improving the Design of Existing Code, 2nd ed. Boston, MA: Addison-Wesley, 2018. [Online]. Available: https://martinfowler.com/books/refactoring.html