Outliving the Vendor

Summary

A regulated organisation acquiring a system to hold clinical records is taking on a retention obligation that commonly runs to thirty years, and occasionally longer. It is buying that capability from a company whose survival over that horizon is not something anyone would underwrite. The mismatch is obvious once stated and is almost never priced, because procurement evaluates the vendor's present condition — financials, references, certifications — which says little about a thirty-year question. The instruments meant to cover it perform poorly under examination. Escrow usually fails on deposit quality rather than on release. Perpetual licences protect the right to run software while saying nothing about the ability to. Data export produces records without the system that makes them intelligible. And the failure mode people plan for — the vendor goes bankrupt — is rarer and easier than the ones that actually occur: acquisition by a party with different priorities, quiet end-of-life of the specific product, or the slow loss of everyone who understood it. The durable version rests on four properties, all testable before purchase: the records must be readable without the application, the configuration must be legible to someone who never met the vendor, the right to continue must survive the vendor's failure rather than depend on its cooperation, and the cost of leaving must be knowable in advance rather than discovered at the moment of need.

1. The mismatch

Clinical trial records commonly carry retention obligations of twenty-five to thirty years, depending on jurisdiction and study type. Some sample and consent records are held longer. Non-clinical material typically carries shorter but still substantial periods.

Set that against the lifespan of a software company, a software product, or a specific major version of that product. None of those three is measured in decades with any confidence, and they fail independently — a healthy vendor can end-of-life a product, and a surviving product can lose the last engineer who understood its data model.

What follows is not a prediction that any particular vendor will fail. It is that the buyer is making a thirty-year commitment against a counterparty who cannot credibly make one, and the contract is usually silent on what happens in between.

Procurement does examine vendor viability. It examines financial statements, customer references, and certifications — all of which describe the vendor's condition now. A thirty-year horizon is not a question about present condition. It is a question about what the buyer holds when the present condition no longer obtains.

2. What actually fails

The scenario people plan for is bankruptcy. It is the rarest of the four and the easiest to handle, because it triggers every contractual protection at once and does so unambiguously.

Acquisition is more common and much worse. The acquirer's interests are not the acquired vendor's. Product lines are consolidated, roadmaps redirected, support tiers restructured, and pricing revisited at renewal. Nothing breaches the contract. The system keeps running. It simply stops going anywhere, and the leverage in the relationship has changed hands without any event the contract recognises.

Product end-of-life is more common still. The vendor is healthy and the product is not. Support windows narrow, the upgrade path leads to a different product with a migration attached, and continued operation of the current version becomes progressively more expensive and less supported. A customer with a validated system and a thirty-year obligation is poorly placed for a migration they did not choose.

Knowledge attrition is the most common and the least visible. No corporate event occurs. The people who understood the customer's specific deployment leave over five years. Support continues and answers become slower and more generic. The system is still supported in the contractual sense and no longer understood in the useful one.

Three of these four leave the vendor solvent, which matters because most contractual protections are triggered by insolvency. The failures that actually happen do not trip the switch.

3. Why the usual protections underperform

Escrow fails on deposit, not on release. The common assumption is that escrow's risk is a vendor blocking release. The more frequent failure is that the deposit, when released, is insufficient — source without build instructions, without configuration, without the dependency inventory, or simply stale. Escrow arrangements with contractual verification are meaningfully better than those without, and verification is often omitted because it costs money and nobody expects to use the deposit.

Perpetual licences protect the right, not the ability. A perpetual licence means the vendor cannot stop you running the version you have. It does not give you source, build capability, the ability to fix a defect, or a path onto a supported operating system in year twelve. It is necessary and it is nowhere near sufficient.

Data export produces records without their meaning. Exporting records to an open format is genuinely valuable and it is not the same as retaining a usable system. A regulated record frequently needs its context to be intelligible — which workflow produced it, which configuration was in force, what the codes meant, who was permitted to do what. A CSV of results plus a PDF of the audit trail may satisfy a retention requirement in form while being materially harder to interrogate than the running system it replaced.

Source code without buildability is an artefact, not an asset. Receiving source is only useful if a competent third party can build, deploy, and maintain it without the original team. That is a property of how the software is constructed and documented, and it is rarely tested before it is needed.

None of these instruments is worthless. The point is that each is routinely treated as covering the thirty-year question when it covers a narrow part of it, and the parts left uncovered are the ones the common failure modes actually hit.

4. What durability requires

Four properties. Each is testable before purchase, which is the only reason to list them.

The records must be readable without the application. Retained data should be interpretable by someone who has the export and the documentation and nothing else — including the audit trail, whose integrity should be independently verifiable rather than asserted by the system that produced it. A hash-chained trail that can be checked with a published method survives its originating application; one that can only be validated by the software that wrote it does not.

Ask to see: an exported audit trail, and the method for verifying its integrity without using the vendor's software.

The configuration must be legible to a stranger. The rules governing the system — data model, workflow, permissions, validation logic — should be readable artefacts that a competent engineer who never met the vendor could understand. This is what makes a third party able to take the system on, and it is the single largest determinant of whether escrow is worth anything.

Ask to see: the configuration for one workflow, and ask whether your own engineers could read it.

The right to continue must survive the vendor's failure. Continued operation should not depend on the vendor's cooperation at the moment of need, which is exactly when cooperation is least available. This means examining the licence chain: whether components are licensed on terms that survive insolvency, whether sublicences convert to direct licences from the upstream owner, whether an acquirer is bound. Most buyers never look past their direct counterparty, and the direct counterparty is frequently not the ultimate owner of everything in the stack.

Ask: what components of this system are licensed from someone other than you, on what terms, and what happens to our rights if you cease trading? The quality of the answer is informative independent of its content.

The cost of leaving must be knowable now. Whatever the exit arrangement — buyout, escrow release, migration — its price should be established at signature, or computable at any moment from a formula fixed at signature, rather than negotiated at the point of departure. A price negotiated when you need to leave is not a price; it is an assessment of your alternatives.

Ask: what would it cost us to take full ownership of this system, and will you write that number into the contract?

5. What this changes about buying

Vendor viability assessment answers a different question than the one being asked. Financial health tells you about the next few years. It says nothing about year twenty, and the instruments that do say something about year twenty are contractual rather than financial.

The failures worth designing for leave the vendor alive. Insolvency clauses cover the least likely case. Acquisition, end-of-life, and knowledge attrition need their own provisions — assumption on change of control, notice periods on end-of-life, and knowledge transfer that is contractual rather than goodwill.

Ask about the chain, not just the counterparty. A vendor's own durability is bounded by what it holds from others. This is the least examined area in most software procurement and, in stacks assembled from many components, frequently the weakest link.

Willingness to answer is itself information. A vendor who has thought about the thirty-year question will have answers ready. One who has not will treat the question as unusual — which is a finding, given that the buyer's obligation is not unusual at all.

6. Scope of the claim

Where the claim applies, and what it costs.

Thirty years is an obligation, not a prediction about the system. Nobody expects one deployment to run for three decades. Systems are replaced, and records are migrated. The argument is that the obligation persists across those transitions and the migrations are where records are lost, which is where the obligation bites.

The cost of durability is real and is not priced here. Escrow with verification, exit provisions, and buyout options cost money — sometimes the vendor's, sometimes the buyer's. They are worth it, and a buyer should price them deliberately rather than discover them.

7. The question worth asking

Not "is this vendor financially sound." Ask it, but know what it answers.

Better: what do we hold, on the day this vendor stops being useful to us, that lets us keep meeting our obligation?

The answer is enumerable now. The records, in what format, verifiable how. The configuration, readable by whom. The rights, surviving what events, granted by whom. The cost of exit, fixed or negotiated.

Organisations that enumerate it usually find the list shorter than expected, and generally find that the shortfall was contractual rather than technical — which is fortunate, because contracts are easier to change before signature than after.

Appendix — A thirty-year checklist

This paper argues from mechanism and from ordinary contract practice rather than from measured evidence about vendor failure rates, which it does not have. Every test in §4 and the appendix applies to us as much as to anyone; a reader evaluating us should run them on us first.