# Your old core is slowing you down > Your largest account wants usage-based billing before renewal, and your Oracle core says next year. Rebuilding a legacy core used to be a project you survived; now it's a choice. The five questions โ€” and where AI does the grind while your people make the calls. _Aakash Dharmadhikari ยท 2026-07-02_ --- Imagine you run a twenty-year-old company that sells software to large enterprises. The product is good. Your billing and pricing run on an Oracle core a generation of engineers have come and gone from. Then one day your largest account comes to you at renewal with an ask. They want usage-based billing: pay for what they actually consume, invoiced in their own currency, reconciled straight into their procurement system. A newer rival of yours offers it out of the box. On a modern stack it is a few weeks of work. On your core it is a roadmap item for next year. The renewal is in three months. That is what an old core actually costs you. Not the maintenance bill. The work you cannot take on, and the renewals that quietly walk when you cannot. It is the same shape everywhere the business needs to move. Acquire a company to fold into the core and the core cannot absorb it, so you run two of everything: duplicate systems, duplicate teams, no single view of the customer. The savings you promised slip, a little more each quarter. So why not just rebuild it? Most companies put it off. It takes too long, and it usually misses the date. (BCG found more than two-thirds of large technology programmes miss schedule, budget, or scope.) And the date here is the renewal, an external promise. A budget overrun stays inside the company; a missed renewal does not. The customer leaves, and the market hears about it. So nothing happens. The core stays, and it keeps deciding what you can sell and when. That no longer has to be true. And not because AI writes code faster. Anyone who has run a migration knows writing the code was never the hard part. The hard part was everything around the code, and that is what has actually changed. So to ship that billing capability before the renewal, you have to answer five questions, in order. Each one is a step of the project, and the answer to each sets up the problem in the next. Understand the core. Find out what it will cost your team. Change the piece that could break the business. Move the data. Prove nothing broke. ## 1. How do you understand a system nobody fully knows anymore? Nobody fully knows it. That is the honest starting point. The billing core is decades old, the documentation drifted from reality years ago, and the people who wrote the pricing logic in PL/SQL have moved on. Reconstructing how it actually charges a customer used to take months of your senior people's time, and they still missed the rule that mattered. This is where AI changes the most. Everything goes in: the code, recorded walkthroughs, bug reports, schemas, the live data. One agent reconstructs how the system behaves; a second reviews that reconstruction; both are checked against the runtime traces and the data itself, not one agent's opinion. Within days it produces the picture your business never had: what the core really charges today, and where it behaves in ways nobody intended. On a recent realfast engagement it surfaced, within two weeks, a pricing rule still running in production that the business thought it had retired. What AI cannot do is decide what is true. That still takes senior people who have spent careers inside cores like this. AI does the grind: reading the code, the logs, the data. Their time goes to the calls only judgment can settle. ## 2. How much time will it take from your team? Less than you expect, and on a schedule. This is the question that sinks most of these projects before they start, because the last time you tried, it ate your best people for months. The pricing rules that matter live only in a few experts' heads, so they are never fully out of the loop. The reconstruction from step one changes the shape of it. We do not arrive asking how billing works; we arrive with our reconstructed understanding for them to confirm, plus a short, specific list of questions. Here is the one rounding rule that diverges between two regions; which is correct? On one engagement that meant five to six hours of expert time in the first week, and far less after. It cannot go to zero, and we do not pretend otherwise. But scoped, scheduled and specific is a different thing from the open-ended drain that makes these the projects people dread. ## 3. How do you change the riskiest piece without taking the business down? With the system understood and the cost bounded, you can finally touch the part that scares everyone. The riskiest piece is the one everything else depends on: the charging engine, the ledger, the month-end run that has no rollback. Get it wrong and you do not send a wrong invoice to one customer, you send wrong invoices to all of them. So the work begins at the boundary. AI maps what the billing module depends on and what depends on it: the contracts it holds with everything around it. Those get solidified and wrapped in tests before anything changes behind them. Then old and new run in parallel on the same live transactions, one customer is cut over at a time, and the irreversible steps like month-end posting are carved out and proven first. The discipline that earns trust runs the other way too: if those boundaries cannot be drawn cleanly, we say so before starting, not after. Whether a boundary is safe to cut is an architecture call. The old core stays authoritative until the new path has earned its traffic. ## 4. How do you move decades of billing data without losing any? The new engine is taking shape, but it is empty: to run, it needs your data. And the new charging model is stricter than the old one, so the data cannot just be carried across. Your customer master, your contracts, your rate cards and years of invoices have outlived the people who understood them. What each field holds was never written down; it lived in the memory of a few, the same few a migration waits on and the business can least afford to lose to one. It has to be understood first, then reconciled to rules the old core never enforced: the silent exceptions, the manual overrides, the fields that mean one thing in one currency or region and another somewhere else. AI reads the data itself as the evidence: how records link, what values actually appear, and infers what each field means and how it should map. What it is not allowed to do is guess. On billing data a confident wrong mapping is worse than a slow one, because a wrong number is a mis-charge, so the model is held to what the evidence supports: infer meaning, never invent it. Whether it is right, especially where a wrong value is a compliance event rather than just a bug, is settled by people against the source. ## 5. How do you know nothing broke? Now the new core is built and the data is in. The question every CFO will ask: how do we know it bills correctly? On a billing system you cannot answer that on faith. A wrong invoice is a lost customer, or a regulator's letter. Early on, AI captured what the old core does today as a test suite: the old system's own behaviour becomes the thing the new one is measured against. That baseline is now table stakes. But the hardest part of testing a legacy system is not knowing what to test. It is reaching the state to test it. A test state means rebuilding the history that produced it, one screen at a time: one specific customer, end of month, with a pending adjustment applied. The check takes a minute; reaching it takes hours. So the riskiest cases get skipped in the name of pragmatism, the net has holes, and the gaps surface in production. Our AI agents drive the core into those states directly, so the cases teams used to skip finally get tested, and the new core is proven to bill exactly like the old one on real history. Every run leaves a record, so "are we done?" stops being faith. The pattern across all five is the same: AI does the routine work, and your people make every call that needs judgment. Do all five, and the renewal date stops being a hope. It becomes something you can actually commit to. Back to the customer who came with the ask. On a rebuilt core, usage-based billing is a few weeks of work, and it ships before the renewal. The customer stays. The deeper shift is that your product team stops being the bottleneck for sales, and "not on this system, not this year" stops being the honest answer. Rebuilding an old core used to be something you just had to survive. Now it is a choice you can make: whether the core keeps setting the pace of your business, or you do.

Rebuilding a legacy core?

See how realfast does it โ€” your people make every call that needs judgment, and the renewal date stays intact.

Book a demo โ†’