Repurchase Displacement Cost

A portfolio review marks a bespoke claims application "repurchase": buy the product instead. The justification is a comparison of the annual licence against the cost of maintaining the application. On that comparison the decision is obvious.

The comparison is measuring the wrong thing. Repurchase does not remove work; it moves the work from building software to changing the organisation. The application disappears and the obligations it was carrying do not, and those obligations — the data, the process, the integrations, and a decade of accumulated customisation — are where the effort and the failure live.

This is the disposition with the widest gap between its apparent simplicity and its actual shape, which is why it is both the most attractive box on a portfolio grid and the one most often mis-assigned.

Why it matters

The characteristic outcome of an underestimated repurchase is the worst possible one: the product is bought and live, the old system is kept running "for the reports", and the organisation pays for both while its process spans the two. The savings that funded the decision never appear, and the estate is now more complex than before.

It matters for the business case specifically. A repurchase justified on a licence comparison and then delivered at three times its estimate does not merely overspend; it spends the organisation's appetite for the next disposition decision.

Implementation patterns

• Estimate the four displaced blocks explicitly, each with an owner and a date: data migration into a model you do not control · process change · integration rebuild · retirement of the customisations. On a system with a decade of history, those four together routinely account for well over 70% of the programme's true cost, and the licence comparison shows them as zero.
• Test representability early. Take the ugliest thousand historical records and try to express them in the product's data model in the first fortnight. What cannot be represented is a decision about history, and it is better taken before the contract than after.
• Fit the process to the product, and get that written down by the business sponsor. The moment the product is configured to reproduce the old workflow, you have bought a bespoke system with a licence fee attached and none of the upgrade benefit.
• Rebuild integrations against the product's published contract, not against a database it happens to expose, so the next version does not break them.
• Fund decommissioning as a named workstream with its own date, because it is where the entire saving lives and it is the part with no champion.
• Decide the fate of history before go-live: migrate it, archive it in a readable form, or keep a read-only instance with a dated shutdown. "We will decide later" resolves to "the old system runs forever".

Industry example

The clearest public illustration is the reverse case. Salesforce's metadata-driven multi-tenant platform, described by Weissman and Bobrowski at SIGMOD in 2009, stores each customer's custom objects and fields as metadata rows in shared tables rather than as a schema of their own, so every tenant runs one version of the code and upgrades are not a customer project.

That removes the version fork, which is the dominant cause of legacy pain in packaged software. What it does not remove is the customisation itself: a decade of declarative automation, validation rules, triggers and integrations accumulates and becomes the organisation's new legacy, owned by nobody in whole. This is precisely the displacement cost, arriving later and under a different name — which is why the repurchase estimate has to include retiring customisations rather than recreating them.

Failure scenarios

• Both systems run indefinitely because reporting was never migrated. This is the most common repurchase outcome.
• The product is configured back into the bespoke system, so upgrades break and the vendor's roadmap benefit is forfeited.
• History is unrepresentable and discovered after signature, forcing either a permanent read-only legacy instance or a data-quality remediation programme nobody budgeted.
• Integrations are built against the product's database rather than its API, and the first vendor upgrade breaks them.
• The users were never consulted, so the process change is refused at go-live and the project becomes a negotiation.

Trade-offs

When not to use it

Repurchase is the wrong disposition when the capability is the differentiation. If the bespoke system encodes how the business actually competes — a pricing engine, a routing algorithm, an underwriting model — buying a product that averages the industry's practice trades the advantage away for a licence saving, and that trade is rarely worth making.

It is also wrong when the answer is cheaper still. Check retire first. A large share of portfolio applications have few users, a duplicate elsewhere, or a capability nobody needs any more, and retiring costs nothing per year afterwards. Repurchase should be considered only after retire and retain have been argued and rejected in writing.

Interview question

Q: Your CFO has approved replacing a fifteen-year-old bespoke claims system with a SaaS product, on the basis that the annual licence is less than the team's cost. You are asked to deliver it. What do you put on the plan that is not on their spreadsheet, and what would make you recommend against the whole thing?

What a strong answer covers: the four displaced blocks and rough relative weights · representability of historical data tested in the first fortnight, before contract signature if possible · process change as a business workstream with a named sponsor, not an IT task · decommissioning funded separately because that is where the saving is · the "both systems running forever" failure as the base case to design against · and the conditions for recommending against: the capability is differentiating, or the business will not change its process.

Quick check

Quiz: What does assigning "repurchase" to an application create that a licence-versus-team-cost comparison never shows? Data migration into a model you do not control, process change, integration rebuild, and the retirement of the customisations — with the saving landing only if the old system is actually switched off.

Flashcard: What is the base-case failure of a repurchase decision, and what prevents it? — Buying the product and keeping the old system running "for the reports", paying for both forever; prevented by funding decommissioning as its own workstream with its own date and deciding the fate of history before go-live.