Keep, improve, connect or replace: a framework for business system decisions

Ask most leadership teams what is wrong with a system they are unhappy with, and they can describe it in detail. Ask what they should do about it, and the answer is much less certain. The default tends to be replace it, because that is the option a vendor will happily walk you through. It is rarely the only option, and it is often not the right one.

There are, in practice, four things that can happen to any system, process or spreadsheet a business relies on: it can be kept as it is, improved where it currently falls short, connected to something else so information stops being rekeyed by hand, or replaced outright. Most operational reviews jump straight to the fourth option without seriously testing the first three.

Why replace becomes the default

Replace is the easiest option to sell internally. It is visible, it fits neatly into a budget line, and a demo makes the current way of working look dated by comparison. Keep, improve and connect all require someone to sit with the detail of how work actually happens, which is a less satisfying afternoon than watching a sales demo.

The cost of skipping that detail shows up later, in one of two ways: a new system is bought to solve a problem that was actually about ownership or workflow design, or a perfectly serviceable system is discarded along with the years of configuration, integration and institutional knowledge built around it.

The question is not whether a system is old or unglamorous. It is whether it still does the job, and at what cost to keep it doing that job.

A working order to test the four options

Keep. Does the system already do what the business needs, even if it is not the newest option available? If yes, the honest answer is often to leave it alone and spend the effort elsewhere.

Improve. Is the underlying tool sound, with the gap sitting in configuration, training or a workaround that was never revisited? Reconfiguration is usually cheaper and faster than procurement, and it carries none of the migration risk.

Connect. Is the real problem that two or three systems that each work fine on their own do not talk to each other, so someone rekeys the same information more than once? Integration solves the actual pain point without touching anything that already works.

Replace. Only once the first three have been genuinely tested does replacement become the honest answer, and even then, the case should be able to say plainly why keeping, improving or connecting will not do.

An illustrative example

Consider a business (illustrative, not a specific client) where sales orders, purchase orders and supplier delivery dates were tracked in a shared spreadsheet. The instinct on review was to replace the spreadsheet with a proper order management system, a project that would have taken months and required every supplier-facing team to relearn how they worked. Looking at the actual gap, the spreadsheet was fine as connective tissue. What was missing was an alert when a supplier date slipped and nobody had checked it. That was a half-day fix, not a system replacement.

Why this matters for the commercial case

The government's SME Digital Adoption Taskforce found that many small businesses are held back by gaps in time, cash and know-how, and that switching from one technology to another can feel too high risk. That uncertainty is exactly what a keep, improve, connect or replace test is designed to remove: it turns a vague sense that "the system isn't working" into a specific, proportionate decision, made in that order, with replacement earning its place rather than defaulting to it.

What this means in practice

Before any procurement conversation starts, it is worth writing down, honestly, what keeping, improving and connecting the current arrangement would actually involve, and what each would cost against what it would fix. Replacement is sometimes still the right call. It should be reached because the other three were tested and found wanting, not because it was the first option anyone thought of.

This is the call the Operations Deep Dive makes for each system and spreadsheet it looks at: keep, improve, connect or replace, with the reasons written down.