Software that has run a business for years usually knows things nobody wrote down: the discount one customer gets, the rounding the accountant expects, the order status that only means something in the warehouse. When it starts to hurt, someone always proposes starting again, and someone else always says it would be cheaper to fix what is there.
Both can be right. There is no general answer to which is cheaper, only an answer for a particular system, and it comes from a handful of facts about it. This article is about those facts: six questions, how to answer each one with evidence rather than opinion, what the answers point to, and, because the answer is sometimes "replace", what a replacement actually involves when it is done carefully.
1. Does it still do the job?
Write down what the business needs the system to do this year. Then compare it with what the system does.
If the work it does is still the work you need, and the complaints are about speed, errors or missing pieces, improvement is on the table. If the business has moved, a shop that became a subscription service, a single warehouse that became three, and the system models something you no longer do, every improvement is spent bending it into a shape it was never meant to have.
How to check: list the five things people do in the system most often, and ask the people doing them what gets in the way. Their answers are usually more specific, and more useful, than any management summary.
2. Where does it hurt?
Pain concentrated in one area, reporting, one integration, one slow screen, points at that area. Pain everywhere, and especially pain that moves around when something is fixed, points at the foundations: the data model, the framework, the way the parts are wired together.
How to check: collect the last few months of complaints, bug reports and support tickets, and sort them by the part of the system they are about. If a handful of parts account for most of them, that is good news: those parts can be improved or replaced on their own. If they are spread evenly, the problem is probably underneath all of them.
3. Is the platform still supported?
A programming language version, framework or server operating system that no longer receives security updates is a deadline, whatever else is true. It does not always mean replacement. Often the upgrade is the improvement, and a system that is upgraded to a supported version can run for years more. But it does mean that doing nothing is not an option, and the longer the upgrade waits, the bigger it gets.
How to check: write down the exact versions of the language, the framework, the database and the server operating system, and look each one up on its project’s support page. Note the end-of-support dates. A system three versions behind on everything is a different project from one that is one minor version behind.
4. Is every change getting harder?
When each small change breaks something unrelated, when estimates for simple changes keep growing, or when nobody dares to touch a particular part, the cost of keeping the system rises with every request. That cost is real even though it never appears as an invoice for "the old system": it appears as every new feature costing more than it should.
How to check: look at the last ten changes. For each one, how long did it take compared with its estimate, and did it cause a problem somewhere else? If most of them ran over and several caused side effects, the system is charging interest on every change.
5. Can the data get out cleanly?
If the data can be exported and understood, both improvement and replacement are possible. If it cannot, if it is locked in a format only this system reads, or its meaning lives in code nobody understands, that is the first problem to solve either way, because neither a replacement nor a serious improvement can start without it.
How to check: export one real month of the main records, orders, customers, bookings, whatever the system is about, and try to explain every column to someone who has never seen the system. The columns nobody can explain are where the unwritten rules live.
6. Who understands it?
A system that only one departed developer understood is riskier to change and riskier to replace, because in both cases the first job is to find out what it actually does. That work is not wasted, it is the specification for whatever comes next, but it has to be done before any estimate, for improvement or replacement, means much.
How to check: ask who could fix it tonight if it stopped. If the answer is nobody, start there, whatever you decide later. What I check before taking over an existing application describes the first steps.
Replacing in stages
Replacing in stages is the option most often dismissed as slow, and the one that most often goes well, because at every point there is something working to fall back on. The pattern:
- Pick the part with the clearest edges and the most pain. Often a report, an export, or one customer-facing page.
- Build it new, reading from the old system’s data or a copy of it.
- Run both side by side and compare the results on real work. Differences are either bugs in the new part or unwritten rules in the old one, and both are worth finding.
- Switch that part over, and retire it in the old system.
- Repeat, part by part, and keep the data moving in one direction only, from old to new, until the old system has nothing left to do.
The hardest rule in that list is the last one. Two systems that both write the same data will disagree sooner or later, and then nobody knows which one is right.
Moving the data
Whether the replacement happens in stages or at once, the data has to move, and data migrations fail in predictable ways. What helps:
- A written mapping: every field in the old system, where it goes in the new one, and what happens to values that do not fit. Writing it forces the unwritten rules into the open.
- Dry runs on real data, early and often. The first migration of real data always finds something: dates in three formats, customers entered twice, a status nobody remembers creating.
- Counts that must match: number of customers, orders, open invoices, the total of all order values, before and after. A migration that "worked" but lost forty orders did not work.
- A decision about history. Not every old record has to move, but the decision should be made deliberately, and whatever is left behind should still be readable somewhere.
Switching over
When the day comes to switch, whether for one part or for everything, a short written plan prevents most of the drama:
- a time when little is happening, and people are around to check
- a freeze on changes in the old system just before the final data move
- the final data move, and the counts checked again
- the switch itself, and the old addresses redirected to the new ones, so links in e-mails, bookmarks and search results keep working
- a list of things to check straight after, done by the people who use the system
- a way back, written down in advance, and a deadline after which the way back is no longer used
The way back is the part most often skipped, and the one that makes everyone calm enough to go forward.
A replacement estimate is usually compared with the cost of the next improvement, not with the cost of everything the old system does. Before comparing, list what the old system does that nobody asked for:
- the e-mails it sends, and to whom
- the exports and reports someone opens every month
- the scheduled jobs that run at night
- the integrations, including the ones that only receive data
- the rules hidden in code: discounts, rounding, rights, numbering
- the old addresses that search engines and customers still use
- the training: how long it will take people to be as fast in the new system as they were in the old one
Each one is either rebuilt, replaced by something else, or deliberately dropped. An estimate that has not made that decision for each of them is not finished.
Not sure whether to improve it or replace it?
Describe what the system does and what hurts.