The sunk-cost trap

An Australian business owner, reviewing the accounting platform they had chosen, set out a familiar sequence. The platform was selected on its strengths, and it does those well. It also will not hold multi level or quantity based pricing, or the kind of inventory control the business runs on. So the pricing lives in add-ons and a spreadsheet, and the business pays for both the platform and the gap.

That is the trap, and it is worth saying plainly that it is not a procurement failure. The evaluation was done properly. The advanced capability that drove the decision is genuinely there. What was missing was something so ordinary that nobody thought to test for it, because nobody demonstrates the ordinary parts and nobody asks about them.

Why the gap is invisible until it is expensive

A demonstration shows a product doing what it is good at. That is what a demonstration is for, and it is not dishonest. The consequence is that the evaluation covers the differentiators, which are the reason the shortlist exists, and skips the parts every product is assumed to have.

The gaps we see most often are not exotic. A job platform where staff cannot update their own availability. An invoicing product that will not combine several invoices into one. A ledger that cannot run contractor superannuation through the same path as payroll because that path is tied to employees. A field platform that requires so much manual entry that an owner described it as needing a full time person to feed it. None of these are faults in the sense of something broken. They are design boundaries, chosen deliberately by a vendor building for a different shape of business, and they are entirely reasonable decisions that happen to be wrong for you.

The cost shows up somewhere else. The gap becomes a spreadsheet, the spreadsheet needs the same data the platform already holds, and somebody types the same number twice. That is how a feature gap turns into a permanent hours-a-month line in the payroll, and it is the point at which connecting the systems you already run becomes the cheaper question than replacing any of them.

The three options people consider

Live with it. The gap is absorbed by a person, usually the most capable administrator in the building, and the cost is invisible because it is already inside a salary. This is the option almost everybody takes by default, and it compounds, because the spreadsheet that fills the gap becomes load bearing and then becomes irreplaceable.

Buy an add-on. A second subscription that does the missing thing, connected to the platform by whatever integration the two vendors have agreed on. Sometimes this works. Often it introduces a second place the same record lives, which is the same problem with a monthly fee attached.

Replace the platform. The instinct that feels like resolve, and the one that most often makes things worse.

What replacement actually costs

The evidence on migration is consistent and it is worth reading before anyone commits to it. An Australian owner described support taking more than six weeks to move an offline file into the vendor's online product, and moving to a competitor at the end of it. Another described a forced move between versions that disrupted invoicing and left reporting without customer information. Another found they could not cancel online at all, with a ten day notice requirement applying to a monthly plan.

None of that is unusual and none of it is malice. Moving a system of record means moving history, and history is where all the special cases live. The estimates people make are for the data. The time actually goes to the exceptions, the re-training, the reports that have to be rebuilt, and the fortnight where both systems run and neither is trusted.

So the honest comparison is not the annual fee of the platform you have against the annual fee of the one you want. It is the cost of the gap against the cost of the move, plus the risk that the replacement has a different ordinary thing missing that nobody demonstrated to you either.

Connecting around the gap

The option that gets skipped is the one that treats the platform as a component rather than a decision to be defended or reversed.

The platform keeps doing the thing it was chosen for and keeps being the system of record for the records it owns. The missing function is built once, connected to it, and reads and writes through the interface the vendor already publishes. The pricing rules that ended up in a spreadsheet become rules in a table your team edits. The double entry that filled the gap stops, because the two places holding the same number are joined instead of both being typed into.

This is cheaper than a migration in every dimension that matters, and it is reversible, which a migration is not. It also has an effect people do not expect: it makes leaving possible later. Once the gap function lives outside the platform and the connection is documented, the platform is no longer holding your business hostage through the workarounds built around it.

How to tell which one you have

Four questions, and they can be answered in an afternoon by the people already doing the work.

Does the gap cost hours a month, or does it cost correctness? Hours can be connected around. Correctness, where the platform is producing answers the business cannot rely on, is a harder case and sometimes does argue for a move.

Is the record the gap concerns owned by this platform, or by something else? A gap in a record the platform does not own is almost always a connection problem, not a product problem.

Does the vendor publish an interface you can read and write through? If yes, the gap can be filled without touching the platform. If it is read only, or absent, the options narrow, and that is worth knowing before the annual renewal rather than after it.

What would actually change for the person doing the work? If nobody can name a task that stops, the migration is being driven by frustration rather than by arithmetic, and frustration is a poor scoping tool.

The sunk cost is not the point

The money already spent is gone whichever path is taken, and it should not be an argument for staying. What should be an argument is that the platform is doing several things well, that replacing it puts those at risk to fix one thing, and that the one thing can usually be fixed where it sits.

Working out which case you are in is a counting exercise before it is an engineering one: what the gap costs a month, who absorbs it, and what the interface will let you do. That is what an engagement opens with, and the answer is sometimes that the system you have is fine and the plumbing around it is not.