A mid-market financial services firm needed off Oracle 12c ahead of extended-support expiry — but its core ledger and nightly batch settlement system left zero room for a precision error. OptiSol used Data Guard-based parallel-run testing to validate every settlement run against Oracle 23ai, and the process surfaced a rounding mismatch weeks before go-live.
Oracle 12c was approaching the end of its extended-support window, and the firm's core ledger and batch settlement platform sat squarely in scope. Unlike a typical application upgrade, a numeric or logic discrepancy here would not just be a bug — it could misstate a client's balance.
Oracle 12c's extended-support window was closing, and the ledger platform underpins statements and settlement records subject to financial-services audit and regulatory review. Staying put was not a viable long-term option.
The nightly batch settlement job and its supporting packages had accumulated years of numeric handling, rounding conventions, and exception logic. No one wanted to touch it without proof it would behave identically on a newer engine.
A ledger and settlement system has to reconcile to the cent. An optimizer change, a datatype default shift, or a subtle arithmetic path difference between versions could silently misstate a batch total — and might not surface until an audit.
Rather than cut over on faith, we stood up a Data Guard-based 23ai standby and ran real settlement cycles against it in parallel with production for weeks — reconciling every output before the target environment was allowed anywhere near go-live.
Every package, procedure, and job involved in the ledger and settlement flow was inventoried and checked against Oracle 23ai's compatibility matrix, with numeric-handling and datatype-default changes flagged as the highest-priority risk area.
A cloned schema was migrated to Oracle 23ai and every settlement-related package recompiled and unit-tested in isolation, with particular attention to rounding functions, precision arithmetic, and currency-conversion routines.
An Oracle 23ai standby was built and kept current with production via Data Guard, giving the team a continuously up-to-date target environment without freezing or duplicating manual data loads.
Every nightly batch settlement run was executed against both the 12c production system and the 23ai standby, with outputs reconciled line by line. One run produced a small but real precision mismatch in a settlement total — traced to a rounding function behaving differently under 23ai's numeric handling. It was fixed and re-verified for several subsequent cycles, entirely before go-live.
With weeks of matching settlement output behind it, cutover was executed as a planned Data Guard switchover rather than a migration event — traffic redirected to the 23ai environment with a tested fallback path held in reserve.
"Finding that rounding mismatch during parallel-run testing, instead of after go-live, is the entire reason this kind of validation exists. That one catch was worth the extra weeks on its own." — OptiSol Oracle Engineering Lead
Let's Talk
Tell us what you are running today and where you need expert support.
"*" indicates required fields
Global Presence
Five global locations. One connected engineering team.
North America
Chennai · Coimbatore
Client services
Regional operations
Client services
