A vendor whose product sits in your critical path has announced end of life in nine months. Walk me through the decision.
6 min readUpdated 2026-08-15Target archetype: Big Tech, Enterprise Captive, Product Startup
0
Answer
Short answer
Establish what the product is load-bearing for and what the deadline really is once procurement, security review and change freezes are subtracted, then price four options against that calendar: pay for an extension, move to the vendor's successor, replace it, or absorb the capability.
This is vendor risk under a calendar constraint. Good vendor risk work starts by finding every caller, data dependency, contract date, and security obligation before choosing a replacement path. Weak vendor risk answers jump straight to migration and discover the real coupling late. Strong vendor risk management prices the cost of buying time, the cost of switching, and the cost of accepting vendor risk for a limited period with a named owner.
Was this answer helpful?
Likely follow-ups
→The vendor offers a paid extension of twelve months. How do you decide whether to take it, and what do you commit to in exchange?
→Six weeks in you discover a second team integrated with the product directly, outside your inventory. What changes?
→The replacement covers ninety per cent of the behaviour. How do you decide whether the last ten per cent is scope or a feature you retire?
→How would you have made this dependency cheaper to leave when you first adopted it?
The announcement is not the problem statement. The problem statement is what stops working on that date, for whom, and what the organisation has quietly come to rely on beyond the feature you bought. Those are different questions and the second one is where the schedule risk lives. You bought a rules engine; three years later it also holds the only readable record of why a customer was declined, and a compliance team runs a quarterly report out of it that nobody in engineering knows about.
So the first week is inventory, and it comes from observed reality rather than from documentation. Look at inbound traffic and credentials to find every caller, including the batch job and the spreadsheet with an API key in it. Look at what data lives only in the product and in what format you can get it out.
Read the contract, because the phrase "end of life" covers three distinct dates that vendors routinely publish separately: the date they stop selling it, the date they stop shipping fixes including security fixes, and the date the hosted instance is switched off. If it is on-premises software, the third date may not exist at all and you have bought yourself an unsupported system rather than a deadline. If it is SaaS, the third date is real and immovable and everything else follows from it.
You also need to know what breaks quietly. A product that stops receiving security patches does not fail on a Tuesday; it fails when an auditor asks, or when a CVE lands and you have no route to remediation. That distinction determines whether this is a delivery problem or a risk-acceptance problem, and they go to different decision-makers.
The four options, and what each is really buying
The option set candidates usually bring is "replace it", which is one option presented as the whole space. There are four, and each one buys a different thing.
Option
What you are buying
What it costs you
Pay for an extension or extended support
Calendar, and only calendar
Money, and usually a commitment that weakens your negotiating position later
Migrate to the vendor's own successor product
A smaller integration delta
Renewed lock-in, on their timetable, with their pricing reset
Replace with a different product
A fresh evaluation and exit terms you choose
Full integration, retraining, and the migration of everything the old one held
Build or absorb the capability
Permanent control of a thing on your critical path
Ongoing ownership of something that is probably not your differentiator
The fourth deserves a real hearing rather than a reflex dismissal, but only when the inventory shows you are using a narrow slice of the product. A team using six of two hundred features is in a genuinely different position from a team using it as a platform, and the honest version of "build it" is usually "build the six things and delete the rest of the capability", which is a scope decision the business has to agree to because somebody loses a feature.
The second option is the one that gets chosen by default and reviewed least, because it looks like the low-risk path. Price it as what it is: a new contract, so a new exit clause, a new pricing floor, and a new dependency whose end of life you have just moved five years out rather than removed.
Why nine months is not nine months
Work the calendar backwards from the vendor's switch-off date and subtract everything that is not engineering. Procurement and legal for a new supplier is a real elapsed duration in most organisations and it is not one you control. Security and data-protection review of a new processor is another. If the product touches customer data there is a transfer and retention question with a lawyer attached. Then subtract your own change freezes: the quarter close, the peak trading period, the fortnight nobody deploys in December.
Loading diagram…
Read that chain right to left and the engineering build is one box among seven. The useful output of the exercise is the date by which selection must be finished, and that date is often only weeks away when the announcement lands, which is the argument for spending money on an extension before you have finished evaluating anything.
Who decides, and what they need in order to decide
You are not the decision-maker on a spend of this shape, and pretending otherwise is how these decisions stall. Name the accountable owner explicitly, usually whoever carries the budget and the risk for the capability, and work out what they need in front of them: two costed options rather than five, the consequence of the do-nothing path stated plainly, and a date after which the cheaper option is no longer available. That last item is what converts an architecture recommendation into a decision, because it makes delay itself a choice with a price.
Bring the risk-acceptance path deliberately rather than as an admission of defeat. Running an unsupported on-premises product behind tightened network controls for eight months, with a named owner and a review date, is sometimes the correct answer and is always better than the same outcome arrived at by drift. Write it down as a decision record so that in eight months there is a document rather than an argument.
Where these programmes lose control
The failure is rarely the integration. It is discovering in month six that the coupling was in the data rather than the API — that the old product's model of a customer, or its identifiers, are embedded in three downstream systems and in years of stored records, so the swap is a data migration wearing an integration's clothes. The defence is to demand a full export in month one, before you have chosen anything, and to try loading it into a candidate. An export you have not exercised is a promise, and a vendor being wound down is the least reliable counterparty for a promise you have never tested.
The second failure is the deadline reflex: skipping evaluation to protect the schedule, then living for five years with a product chosen in three weeks under duress. If the calendar genuinely will not accommodate a real selection, buy the calendar. Money spent on an extension is the cheapest thing in this entire decision.
Subtract procurement, security review and freeze windows from the vendor's date before you decide anything, because that arithmetic usually shows the selection deadline has already passed — and paying the vendor for time is far cheaper than choosing a five-year dependency in a fortnight.