When rewriting a system costs less than a year of maintaining it

The system a company has run on for years supports a live process: sales, billing, customer tickets. There is no day on which it can be switched off, and no line in the budget that says what another year of maintaining it costs. Licences sit on one line, staff on another, the manual work around the system on none. So the decision to rewrite is usually made when the system forces it: the vendor ends support, or the only person who knows the code leaves. It can be made earlier.

What the annual cost of an old system is made of

The bill for another year has five components.

1. Licences and infrastructure. Software fees, servers or cloud, vendor support, contracts for versions the vendor no longer develops.
2. The people who know it. The time of administrators, developers and staff who alone can explain why the system did what it did.
3. Workarounds and the manual work around it. Spreadsheets in which someone reconciles data between two systems, reports assembled by hand, tickets retyped from email. Each is small on its own, which is why none of them makes it into any summary.
4. The cost of changes that cannot be made. A new sales channel, a new price list, a connection to a partner's system: if the old system cannot take it, the company pays in manual handling or in revenue forgone. This item is usually missing from every calculation.
5. The risk that the person who knows it leaves. If the rules by which the system really works live in the code and in one person's head, that person's departure turns maintenance into an investigation. The cost: the time needed to rebuild that knowledge, multiplied by the probability that it will be needed this year.

How to set the two calculations side by side

The annual cost is the starting point, but the comparison only makes sense over several years: a rewrite is a one-off expense, while maintenance comes back every year. Three years is a sensible period; over a longer one, the assumptions about prices and people lose credibility.

The first calculation: the sum of the five components times three, adjusted for announced events (end of support, a licence price rise, a departure). The second: the cost of the rewrite, the period in which both systems run in parallel (when you pay for two), and maintenance of the new system for the remaining years: team, infrastructure, licences.

Enter any unknown item as a range and run both variants. The same result at both ends of the range is a decision. A result that depends on the assumption tells you which item to measure before signing the offer.

Three signs it is time to rewrite, and two that it is not yet

It is time to rewrite when:

1. A change required by the market or by regulation is impossible in the old system, or costs as much as a new module. The fourth item of the bill becomes visible.
2. Knowledge of the system's rules sits with one or two people, and the documentation describes a version from years ago. The fifth item then has a real date.
3. The manual work around the system grows every year: another spreadsheet, another full-time post for reconciling data. The company is already paying for a new system, in headcount.

Not yet, when:

1. The problem is one module or one connection to another system, and the core supports the process without workarounds. Replacing one element costs a fraction of a rewrite and buys time for the rest.
2. The company plans to change the process itself within a year: a merger, a new sales model, a reorganisation. A rewritten system would reproduce a process that is about to cease to exist. Process first, then system.

How to rewrite without stopping the process

Sales, billing and ticket handling carry on throughout the project, and the window for switching over, if there is one at all, is short.

The new system is built alongside the old one and works on live data from day one, at first in read-only mode: it sees the same as the old one and shows whether it calculates the same way. Discrepancies surface before anything depends on the new system.

The switch-over goes process by process: first the one in which an error is cheapest and quickest to spot, such as reporting, then ticket handling, and billing last. Each process has a switch-over date, a person who decides on it and a way back to the old system if the first week reveals an error. Switching everything at once has no such way back.

Taking over knowledge from the people who know the old system starts before the first line of code. The rules in the program and in people's heads have to be written down as a list of cases: what the system does with a corrective invoice, with a ticket that has no client number, with a payment in another currency. That list later becomes the test suite for the new system and the proof that nothing was lost. Members of the team have worked on systems that were already running: rebuilding infrastructure monitoring for scalability (so that it could handle a growing network) and moving a workflow system to the cloud. They also built an ERP system (the company's finance and operations) with debt-collection automation.

What to require from the contractor

Before you start comparing prices, the offer should describe five things.

• Scope. The list of processes the new system takes over, and of those that stay in the old one or disappear, with a person on your side who confirms that the list is complete.
• Order of stages. Which process switches over first and why, what is ready after each stage and what can already be used.
• What happens to the data. Where the new system gets its data, how long both run in parallel, who reconciles discrepancies, and what happens to the history the new one does not carry over.
• Knowledge takeover. Who on the contractor's side talks to the people who know the old system, and when and in what form the record of rules is produced.
• Who maintains it after launch. Named people, response times, the annual cost and the way the system will be handed over to your people if you decide to take over maintenance. Without this item, the second calculation is understated.

The first step is an analysis: a record of what the old system does today, both calculations over three years and the order of switch-over, with a recommendation on whether to rewrite and which process to start with.