Next WrldIt is 8:30 on a Monday. The weekend must be billed, two collections arriving Friday must be applied and a client swearing they already paid must be answered. The system is slow to open, the current-accounts screen looks from another era and for a credit note three unrecorded steps must be remembered. Someone says aloud: “we have to throw this away and redo it”.
And yet, by ten billing went out. Balances close. Collections knows who to call first. It is slow, but it sustains operations every day. Annoying enough to want to change it, working enough that changing it is scary.
The question seems technical. It is a question about risk and continuity. At stake is the sales, billing, collection and debt circuit running without cuts while we change it.
What the old system knows, although nobody wrote it
A billing and current-accounts system with years in production accumulated operational judgment, more valuable than code.
It knows that such client is billed at month end although delivery is partial. That another must have invoices split per branch or they reject them. That certain receipts don’t go out until warehouse confirms goods.
None of that is usually in a manual. It is in the system and in detours people invented to make it close. When replacement is proposed, those rules are assumed to pass alone to the new system. They don’t pass alone.
Rebuilding from scratch forces rediscovering that knowledge under pressure. And what isn’t rediscovered is lost. The first replacement cost is forgetting how the company works. If the system sustains operations, it is because it contains right decisions to rescue before discussing technology.
What really hurts
Not everything annoying weighs the same. Separate pains.
There are usage ones: uncomfortable screens, extra steps, complicated prints. They tire, but don’t prevent control. There are information ones: doubtful balances, outdated debt, reports disagreeing across teams. They confuse and generate rework. And there are risk ones: if it breaks, nobody knows how to fix it; if a fiscal rule changes, everything shakes.
Distinction matters because each pain asks for another answer. A usage problem can be solved with better reading over the same base. An information problem asks ordering data and allocation rules. Only structural risk, when the base no longer admits changes, points to replacement.
One question orders conversation: if tomorrow you had to bill double, what would break first, people, information or the program? The answer usually shows where the real limit is.
Modernize or replace, on what matters
Modernizing is evolving by parts, without stopping operations. Replacing is building another and migrating everything at some point. Seen from business, they differ in four dimensions.
In risk, modernizing exposes gradually: each change is bounded and fixable. Replacing concentrates risk in one cut, when everything must work together. In billing, that day coincides with due dates, claims and real payments.
In cost, modernizing spreads investment and lets you stop when benefit is achieved. Replacing demands investing much before seeing results, plus invisible costs: discovery, data cleaning, training and parallel operations.
In time, modernizing delivers improvements in weeks. Replacing promises everything together, but late. Meanwhile, the old system keeps hurting.
In continuity, modernizing keeps the sales, billing, collection and debt circuit running. Replacing stresses it exactly where it hurts most: incoming money and controlled debt.
The rule is simple: replacing is justified only when the base prevents evolving or sustaining it costs more than rebuilding. Otherwise, modernizing preserves working knowledge and reduces risk.
How this circuit is modernized by parts
Think of a typical case. A company bills daily with an old system. Issuing works, but current accounts aren’t reliable: hand-applied payments, late-loaded credit notes and balances disputed by phone. Each team has its spreadsheet because they don’t fully trust the other.
That circuit can’t stop. It doesn’t start by rewriting. It starts by ordering.
First, visibility without touching issuance: a single query per client, with invoices, payments, credit notes and balance ordered by due date. Arguments about what each client owes drop because everyone watches the same.
Second, discipline in collections: a guided way to apply payments, proposing applying to most overdue but allowing exceptions with reason. The rule isn’t changed, it is made explicit. Month-end errors and rework fall.
Third, order in exceptions: clear circuit for credit and debit notes, with who authorizes them and how they affect balance. Many differences are born here, not in original invoices.
Fourth, only then, issuance: prior validations, templates and controls, keeping numbering and working logic. And finally, debt by age to decide who to collect first.
Each step delivers something usable and doesn’t interrupt billing. If a step fails, that step is adjusted. That is the difference between evolving and betting.
The underlying philosophy is the least complexity needed to correctly solve the problem. If with ordered visibility and allocation debt becomes controllable, rewriting billing that month isn’t needed.
When replacing is right
Some cases where modernizing insists on a base no longer delivering.
When no support is possible: nobody can maintain the system, there are no reliable backups or any minor change can break issuance. If touching it is lottery, evolving by parts is also risky.
When data isn’t reliable at origin: hand-rebuilt balances, duplicated receipts, inconsistent numbering. A new interface would only show the same disorder faster.
When rules are impossible to extract: interest, bonuses or taxes depend on patches nobody understands. If you can’t explain how a balance is reached, you can’t safely evolve either.
And when change cost is bounded because use is low: a barely used side module or a circuit pausable for days without affecting collections. There the cut is manageable.
You don’t replace because the system “got old” or “looks ugly”. You replace because it prevents operating with control or sustaining it costs more than redoing. Age isn’t an argument; inability to evolve is.
Expensive mistakes
First is rewriting for aesthetics. Changing screens without ordering allocation rules leaves the same problem with better appearance. In current accounts, what orders isn’t design, it is criteria to apply payments and treat exceptions.
Second is underestimating hidden rules. The client whose credit isn’t cut although overdue, the invoice held until the remittance arrives, the partial payment purposely left unapplied. If not surveyed before, they appear as new-system failures when they were business rules nobody told.
Third is migrating everything in one weekend. Moving history, balances and open payments in two days, with the company billing Monday, usually ends in manual reconciliation for weeks. These migrations rarely fail for technology: they fail because operations can’t pause.
And a fourth, less visible mistake is not defining what a right balance means. Without agreed criteria — which reports must match, who validates — each team argues with its number. Before modernizing, agree how order is measured.
How to decide without guessing
Back to Monday at 8:30. Frustration is legitimate, but not a plan. Before choosing, answer three questions with facts.
Which part of the circuit today sustains money control, although uncomfortable? That is preserved and evolved, not thrown away.
Which part prevents precisely knowing who owes, how much and since when? That is ordered first, because without reliable information no new system will work.
And which part no longer admits changes without breaking everything? Only that part justifies rebuilding, and only if the operational cut is manageable.
If the base still allows ordering information and improving by stages, modernizing is the lowest-risk path. If it no longer sustains control nor evolution, replacing becomes necessity. Choosing well is choosing what lets you keep billing, collecting and controlling debt while improving.