An end-of-life date rarely switches a platform off. Pages may still load, transactions may still process and employees may continue working as they did the day before. That continuity makes the warning easy to defer.

“It still works” answers only one question. Leadership also needs to know which vendor commitments have ended, which controls now depend on compensating measures, how connected services may change and how long the organisation can retain the necessary skills.

End of life, end of support and extended support can mean different things across products and contracts. Confirm the supplier’s exact policy, dates, versions and entitlements before drawing conclusions. A marketing announcement or inherited spreadsheet is not enough.

What changes when support ends

Depending on the product and agreement, the organisation may lose security updates, fixes, compatibility assurance, technical help or access to tested upgrade paths. Some suppliers offer paid extended support with narrower coverage. Open-source products may rely on a community or a specialist provider rather than a single vendor.

Create an evidence record containing:

  • product, edition, version and components;
  • published lifecycle dates and source;
  • current contract and support entitlement;
  • security-update and defect-fix position;
  • dependencies and supported versions around it;
  • data, users and business services affected;
  • internal and external support owners; and
  • the date and authority for the next decision.

The National Cyber Security Centre’s guidance on obsolete products explains that unsupported products no longer receive security updates and may lack newer mitigations. It recommends moving away from obsolete systems in the long term while applying risk-reduction measures when immediate migration is infeasible. The guidance is explicit that those measures do not make continued use risk-free.

Five risks to assess

1. Security weaknesses without a supplier fix

A newly disclosed vulnerability may affect the platform after routine fixes have ended. Exposure depends on the weakness, configuration, reachability, data, existing controls and ability to detect or contain exploitation. Unsupported does not mean already compromised; it changes the available response.

Ask the security team to identify known vulnerabilities, externally reachable components, privileged access, segmentation, logging, backups, recovery and incident response. Record temporary controls with an owner and expiry date. A firewall rule or reduced access can lower risk without repairing the underlying software.

The ICO’s current system and network security audit material includes keeping an inventory, assessing unsupported systems and applying appropriate mitigating controls where such software continues in use. Data-protection applicability and required measures depend on the organisation and processing, so legal, privacy and security specialists should advise.

2. Control and assurance difficulty

Auditors, clients, insurers, regulators and procurement teams may ask how the organisation manages unsupported technology. The unsupported state does not automatically establish breach of a particular obligation. It can reveal weak asset governance or make the effectiveness of a control harder to demonstrate.

Map the platform to applicable policies, contracts, risk tolerances and regulatory requirements. Retain the lifecycle notice, risk assessment, mitigation evidence, accepted residual risk and migration decision. A known condition with active governance is different from an unsupported system nobody can account for.

Do not make generic statements that regulation always requires every component to be vendor-supported. The legal and regulatory position must be established for the system, service and jurisdiction.

3. Integration and compatibility failure

Connected services continue to change. Authentication protocols, APIs, browsers, operating systems, payment services, analytics and marketing platforms may stop testing against the obsolete product.

Build a dependency map and identify which side owns compatibility. Monitor release notices for critical connections. Test representative journeys after material changes and create alerts for silent failure, such as a form that displays a success message while no record reaches the CRM.

Where the organisation freezes a connected component to protect compatibility, include the consequence. One end-of-life product can cause a wider part of the estate to remain on old versions.

4. Distributed maintenance cost

Support premiums, additional testing, workarounds, monitoring and incident effort may sit across several budgets. The total can be material without being visible as one line.

Measure actual invoices and time. Separate cost that would continue after migration from effort created by the unsupported state. Avoid assuming that every old platform costs more than its replacement; target services also need licences, operation and skills.

Track trend drivers rather than applying a standard annual escalation. A departing supplier, a contract change or an additional compensating control provides a defensible reason for a forecast change.

5. Knowledge concentration

Risk grows when only one person understands configuration, recovery or custom integration. The problem is concentration and recoverability rather than the age of the specialists.

Test documentation, access to source and configuration, supplier continuity, succession and the ability to restore service without a particular individual. Use rehearsal where the service is important. Paying for scarce expertise may be a rational short-term control, though it should have an exit condition.

Keep architectural constraint separate from AI urgency

The source article argued that an end-of-life platform blocks AI readiness. That may be true for a specific use case requiring structured data, supported APIs or a modern content architecture. It is not a universal consequence of end of life.

Start with the intended AI-assisted service and its data, integration, security, legal and professional requirements. Assess whether the existing platform creates a real constraint. Do not use AI momentum as an extra reason to replace technology when the connection has not been demonstrated.

The same discipline applies to every proposed opportunity. A system can limit change; a list of features the business might someday want is not a quantified cost.

Decide whether to replace, contain or retire

Rank systems by consequence rather than age or irritation. Consider:

  • importance of the business service;
  • sensitivity and criticality of data;
  • external exposure and known vulnerabilities;
  • ability to stay within recovery and impact tolerances;
  • dependency and failure behaviour;
  • strength and duration of compensating controls;
  • support and knowledge concentration;
  • replacement complexity; and
  • viable alternatives, including service retirement.

Possible decisions include immediate migration, a phased replacement, isolation while a migration is prepared, paid extended support, removal of a vulnerable function, reduction in data or users, or retirement of the service.

Time-bound every containment decision. State what new vulnerability, support change, incident, audit finding, contract date or control failure would trigger escalation. Review it at a frequency suited to the risk.

Plan migration and decommissioning together

A target platform does not remove the old risk until traffic, integrations, data and operational responsibility have moved and the old assets are securely retired.

Plan data retention, archives, legal holds, credentials, domains, integrations, backups, rollback and evidence of destruction or transfer. The NCSC’s decommissioning guidance treats retirement as a lifecycle phase with its own risks and recommends considering it during procurement.

Phase by service and dependency where that reduces risk. Some platforms are safer to move together because their data and interfaces are tightly coupled. A blanket rule that phased migration is always superior can create a long, fragile period of dual running.

The Replatform Reckoning provides a broader business-case framework. Verify any product timelines and financial examples in it against current supplier information before using them.

The decision is not automatically “replace tomorrow”. It is whether continued operation has a named owner, current evidence, effective controls and a dated exit or review. End-of-life warnings remove part of the support on which the original operating decision depended. Leadership should make the next choice with that change visible, rather than waiting for an incident or supplier change to choose on its behalf.