Every company with an internal tool has heard the sentence "we should just rewrite it". Sometimes it is true. Often it is a reaction to a bad week. This article gives a support lead, an operations manager or a managing director five questions that turn the argument into a decision that can be written down and defended.
It is about the choice between rewriting and repairing one tool. It is not about the steps of a wider modernisation programme; for that, see modernising legacy systems.
Before the questions: collect twelve months of facts
Opinions about old tools are strong and vague. Gather a few simple facts first, from tickets, chat and the people who use the tool:
- How many requests for changes or fixes did the tool generate?
- How many hours did they take, roughly?
- How many times did the tool stop or give wrong results, and what did that cost the business in time?
- Who made the changes, and are they still here?
Rough numbers are enough. If nobody has recorded anything, the first result is that you do not know how much the tool costs you today, and that is worth writing down.
Question 1: How much effort does upkeep take?
Add up the time spent keeping the tool alive: fixes, workarounds, manual corrections by users, and the time of the one person who "knows how to restart it". Include the hidden part, the minutes users lose every day.
If upkeep is small and stable, a rewrite has to justify itself by something else. If upkeep grows every quarter, that growth is the strongest argument for change.
Question 2: How often does the tool have to change?
A tool that does the same job in the same way for years can be left alone, even if it is ugly. A tool that must change every month because the business changes is different: each change is slow and risky, and that cost repeats.
Count the changes asked for in the last year and how long the typical one took from request to use. Long lead times for small changes point towards a rewrite or a deep restructuring.
Question 3: Does anyone understand how it works?
This is the question most often skipped. Look for three things: a person who can explain the main flows without opening the code, any written description of what the tool does, and a way to run and test it on a separate copy.
If one person holds all the knowledge and that person may leave, the risk is already there whatever you decide. A repair can start with writing down the behaviour. A rewrite without that knowledge will repeat old mistakes or lose rules nobody remembers.
Question 4: What is the risk of each path?
Write the risks for both sides, not only for the rewrite.
- Leaving or repairing: the tool fails at a bad moment, a needed change cannot be made, an unsupported component becomes a security problem.
- Rewriting: the new tool misses a rule the old one handled quietly, the project takes longer than planned while the old tool still needs upkeep, users resist the change.
Ask also whether the new tool can be tested early on real cases. A rewrite that shows nothing usable until the end carries much more risk than one delivered in small parts.
Question 5: What does each path cost, and when does it pay back?
Compare three options in the same terms: repair in stages, rewrite in stages and leave as it is with minimal care. For each one write the effort, the period during which both old and new must be maintained, and what stops being a cost afterwards. Use your own estimates and mark them as estimates; a range is more honest than one number.
Do not count only the build. Include data transfer, training, a period of running both tools in parallel, and the time of the people who must explain the old rules.
One-page decision table
| Question | What you found | Points to |
|---|---|---|
| 1. Upkeep | Hours per month and trend | Repair if small and stable, rewrite if growing |
| 2. Change rate | Changes per year and lead time | Repair if rare, rewrite if frequent and slow |
| 3. Knowledge | Who understands it, what is written down | Repair first if knowledge is thin |
| 4. Risk | Risk of each path, can it be tested early | Staged path if early testing is possible |
| 5. Cost | Range for three options, period of double upkeep | The option with the clearest return |
The example is a format, not a verdict. Fill it in with your own facts and keep the table with the date of the decision.
A worked illustration
Imagine a small company with an order-tracking tool built years ago by one developer who has left. Upkeep is a few hours a month, but every change to delivery rules takes weeks, and nobody can say what happens when two orders are merged. The questions point to this: change rate and knowledge are the problem, not upkeep. A sensible first step is not a rewrite but a short repair phase: document the main flows, add a test copy, then replace the part that changes most often. If that works, replacing the rest can follow with much less risk. The example is invented to show how the table is read and does not describe a real client.
Common mistakes
- Deciding after one serious incident, without the twelve-month picture.
- Comparing a finished rewrite in imagination with the real flaws of the old tool.
- Forgetting the double upkeep while both tools run.
- Planning a rewrite that cannot be shown to users until it is complete.
- Not writing the decision down, so the argument returns every year.
A short checklist
- Twelve months of requests, hours and incidents are collected.
- Both paths have written risks, not only the rewrite.
- Someone can explain the main flows, or documenting them is the first task.
- Three options are compared in the same terms, with ranges.
- The decision and its date are kept on one page.
If the answer is a rewrite and you want to reduce the risk of the project itself, see discovery that prevents expensive custom software mistakes. For a CFO-ready summary of options and costs, see a one-page custom software decision memo.
Sources
- Our related articles linked above.
- The approach described is a general working practice, not a standard; adapt it to your organisation. The table and the illustration are invented examples and do not describe a real client. No figures or client results are claimed in this article.