Replace the software you run, or connect it?

Connect it, in almost every case. The software you already run is rarely the problem. The gaps between one tool and the next are. Replacing a system your team knows costs you twice, once to buy it and once while your people relearn their own jobs, and it usually reproduces the same gaps in a newer place.

The question tends to arrive in one particular shape. A business runs Tally for the accounts, Shopify or a marketplace for the orders, WhatsApp for the customers who would rather talk than click, and a spreadsheet holding the stock together. Nothing is broken, exactly. It is just that the same order gets typed three times, the stock sheet is wrong by lunchtime, and the owner finds out what happened yesterday from a phone call. So a vendor is called in, and the vendor proposes one system to replace all of it.

What is actually going wrong?

Not the tools. Each one is usually competent at its own job: Tally is a good ledger, Shopify is a good shop, WhatsApp is where your customers already are. Spend a morning at the order desk and the fault has a shape, and the shape is always the same. It lives in the hand-offs.

A hand-off is any point where a person moves information from one system into another because the systems cannot do it themselves. Somebody reads an order off a screen and types it into the billing software. Somebody copies yesterday’s marketplace sales into the stock sheet. Somebody screenshots a payment and forwards it. Every hand-off has an owner, a frequency and a failure mode, and none of them appear on anybody’s org chart or in any software licence. They are invisible until you count them, which is why the instinct is to blame the tools.

How do you tell which case you are in?

Count the hand-offs. This is a morning of your own time and it does not need us.

Take a sheet of paper to the desk where orders arrive. Every time somebody types something that already exists somewhere else, write down four things: what was typed, where it came from, where it went, and roughly how long it took. Do not interrupt anyone and do not improve anything yet. Just count. Then do the same at the billing counter, and wherever returns or complaints are handled.

The list ranks itself. Three or four hand-offs will account for most of the entries, and everyone at that desk will already have known which ones they were.

Now ask one question of each line: could a machine have done this, if the two systems could talk to each other? For most lines on most lists the answer is yes, and that is a connection problem. Replacing anything is beside the point; you would be buying a new place to do the same typing. The answer is no only when the thing being typed cannot be held in the receiving system at all. That is the narrow case where replacement genuinely belongs on the table.

When is replacing the right answer?

Three tests. A system has to fail one of them, plainly, before replacing it is the honest recommendation.

It has no door, and nobody will fit one. No export, no interface for other software to call, not even a file it can be made to drop somewhere on a schedule, and a vendor with no intention of adding one. A reading step can often do the typing instead, and for one stubborn supplier that is fine. When every connection in the business would have to be a workaround, the workarounds become the system, and that is worth escaping.

Its model cannot hold your business. A customer who can only have one address, when half your customers bill to one place and receive at another. A product with one unit of measure, when you buy in kilograms and sell in pieces. No batch, no serial, no expiry, in a trade where those decide what you can legally ship. You can tell from the inside: your people are keeping the real information in free-text fields, in naming conventions nobody wrote down, in a parallel spreadsheet. The system is already not holding your business. It is being worked around by people who deserve better.

Nobody can change it. The vendor has gone quiet or gone away, the version is too old to be supported, and no one will touch it. This is the one that creeps up on a business, because the software still works, right up until the morning it does not.

Notice what is not on that list. The tool is old. The interface looks dated. A competitor uses something newer. The salesperson had a better presentation. None of those is a reason, and all four are reasons people are given.

Why is replacing the answer you usually hear?

Because it is the easier project to sell and the easier project to run. A replacement is a big, legible, repeatable piece of work: a licence, a migration, a training plan, a number at the bottom. Connecting what you own is fiddly, specific to your business, and hard to make look impressive. It also ends with a smaller invoice.

That is worth saying plainly rather than hinting at, because it is the honest reason and everybody in the room knows it. We would rather say which third of your system is doing badly than sell you a replacement for the two-thirds that are doing fine. When a system genuinely fails one of the three tests, we will say so, and say what moving off it would involve.

What should you insist on if you connect?

Connections have a bad reputation and it is earned. They are usually built as a script somebody wrote once, which fails silently the first time anything upstream changes. Three things separate a connection you can run a business on from one you cannot.

Failures must be loud and must have a name on them. The order that did not reach billing should appear in a queue, with a reason and a named person, on the day. The alternative is finding it as a missing invoice at month end, and by then it is a customer complaint rather than a retry.

The doors move, so the connection must expect it. The marketplaces and the shop platforms change their interfaces a few times a year. That is normal, it is announced in advance, and the work should be built so that one piece changes when it happens rather than the whole arrangement.

And what gets built new should be only what nothing sells. The customer record that holds every enquiry from every source. The approval that used to be a phone call. The owner’s one page, showing the day in the order you would ask about it. Not another ledger, not another shop.

What if you connect and it is still wrong?

Then you have learned exactly which part could not be carried forward, and you have learned it holding a list of specific failures rather than a proposal full of promises. A connection that does not work tells you where the real boundary of your system is, at a fraction of what a replacement costs to discover the same thing. That is not a wasted step. It is the cheapest version of the step you were going to take anyway.

The fashion brand with eleven stores and three online channels did not replace its store billing, its marketplaces or its website. All three kept doing their jobs. What it did not have was one place they all reported into, so month-end meant reconciling three sets of numbers that disagreed. The change was the missing piece, not a new version of the pieces that were already there.

So when a vendor’s first answer is to replace everything, ask which of the three tests your system fails, and ask them to point at the evidence inside your own business. If they cannot name one, you are being sold the easier project rather than the right one. That is the whole of what we do differently on CRM, ERP and integration work: the list of hand-offs comes first, and the list decides.