In this guide 6 sections
Improve what still fits. Replace it when a proven packaged product covers your needs better than more spending on the old system could, and the new vendor is established. Rebuild only when the system blocks the business and no configuration or replacement can fix that, because rebuilds carry the longest delays and highest risk. Most owners overestimate the need.
Business fit, technical health and continuity risk
These are three separate questions. Business fit asks whether the system supports how the company operates, technical health asks whether the code, database schema, backup routine and servers are sound enough to build on. Continuity risk asks what happens if the system fails tomorrow or the one person who understands it leaves, and how long the business could trade without it.
Conflating them is the commonest mistake. A system may score well on one and badly on another: a stable ledger everyone understands, or a modern app that cannot price a made to order job. Score all three honestly.
Each combination points to a different answer, and writing the three scores on one page lets the owner and the person who runs the system argue from facts.
Configuration, integration, repair and replacement compared
Run three checks first. Can the system be configured, can it be integrated with a specialist invoicing app for the one job it does badly, and can a known defect be repaired? These routes are almost always cheaper and faster than replacement, so rule them out explicitly, in writing, before anyone requests a replacement quote.
Write the result down. A single table listing each option, what it would fix, what it would leave broken and roughly how long it would take gives the owner a real comparison.
Replacement needs a structural gap. A structural gap is not a missing setting but a limit the vendor has no plan to close, or a vendor who has stopped issuing security patches.
What drives migration cost and disruption
The licence is not the cost. The cost of replacing or rebuilding sits in data migration, rewriting each import file and API connection, staff retraining and the dip while two systems run side by side. Map these drivers first.
Ask how much history must move cleanly, how many other systems connect to the old one, and how badly your busiest season would suffer from a week of disruption.
Compare two very different cases. A system with fifteen years of invoices, stock ledgers and six live integrations is a far riskier migration than a two year old system with one integration. Get an estimate from whoever will actually do the work, and treat any number quoted before the drivers were mapped with scepticism.
Scoring a scenario against decision thresholds
Do not decide from gut feel. Score the situation against three thresholds: critical workflows the system blocks, a single person or unsupported customisation behind it, and a configuration project closing most of the gap.
Suppose a trading company runs a DOS era billing program that prints invoices on a dot matrix printer, yet nobody on staff can modify it. It cannot connect to a payment gateway. One employee knows its quirks, and that mix of blocked growth, real continuity risk and no configuration path is a genuine case for replacing or rebuilding. An annoying newer system is different.
A discovery phase before committing
Treat the score as a hypothesis. A short discovery phase maps tables, import files, integrations and workflows in enough detail to produce a realistic scope and cost before either side commits to the project.
Discovery catches two surprises. A rebuild that looked necessary from a distance may turn out to be a barcode scanner integration and a changed tax setting once someone opens the system up. The reverse happens as well: a repair that looked sufficient may hide business rules buried in stored procedures that no patch can touch.
Improve-replace-rebuild decision tree
A decision tree that starts from three scores for business fit, technical health and continuity risk, then tests whether configuration or integration can close the gap. It ends at improve, replace or rebuild. Each branch names its trigger.
Open a blank worksheet to printQuestions owners ask
Can we modernise in stages?
Usually yes, and staging is often the safer path because each module can be signed off by the warehouse and accounts teams before the next one is touched. Staging costs more in coordination but far less in risk, and a failed stage can be rolled back without stopping the whole business.
When is a full rebuild justified?
A rebuild is justified when the current system blocks critical workflows and carries a real continuity risk, such as an unsupported platform or one irreplaceable person. A third condition completes the test: no realistic configuration, integration or repair path closes the gap, however much time you give it. Age alone is no reason.
What should we budget for discovery?
Treat it as a small, fixed piece of work priced separately from the main project, with a written scope and a named report. Ask the supplier to state the questions discovery will answer, so you can walk away with the findings if you decide not to proceed.