A vendor whose product sits in your critical path has announced end of life in nine months. Walk me through the decision.

What you establish before you cost anything

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.

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.

flowchart LR
    A[Vendor switch-off date] --> B[Buffer for slip]
    B --> C[Parallel run and comparison]
    C --> D[Cutover window outside freeze]
    D --> E[Integration build]
    E --> F[Security and data review]
    F --> G[Procurement and contract]
    G --> H[Evaluation and selection]

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.