End-of-life software needs a retirement decision, not an indefinitely renewed exception. Confirm what support has ended, identify the business service that still depends on the product, reduce avoidable exposure, and define the evidence required to remove it from operation. A migration date is useful only when someone owns the work needed to meet it.
The awkward case is the application that still works. Its replacement is approved, but an integration is unfinished. A business owner needs one more reporting cycle. The security team can restrict access, yet nobody can explain when those restrictions will stop being necessary.
Our recommendation is to manage two linked outcomes: reduce exposure while the system remains in service, and remove the dependency that keeps it there. Progress on one should not conceal a stalled decision on the other.
What does end of life mean for software?
End of life, or EOL, describes a lifecycle milestone. End of support, or EOS, concerns the availability of support. They should not be treated as interchangeable dates without checking the supplier's terms. New Zealand's NCSC distinguishes product retirement from support cessation and notes that support can continue after an EOL announcement. NCSC product-support advisory.
For a retirement decision, record the exact product, release, edition, support arrangement, and source of the lifecycle information. Ask what remains available: security updates, technical assistance, or neither. A product name without a release number is not enough to establish the applicable deadline.
If extended support is part of the plan, ask procurement and the technical owner to verify its scope. A proposal to purchase coverage is different from evidence that the relevant installations are covered.
Which unsupported systems should leave first?
The oldest installation is not necessarily the first one to retire. We recommend considering exposure and consequence alongside the practical work needed to replace it.
The Canadian Centre for Cyber Security recommends prioritizing obsolete products that face the internet, perform security-critical functions, or handle sensitive information. Its July 2026 guidance treats replacement as the primary response and temporary controls as limited-duration measures during transition. Obsolete products guidance.
Use the following decision aid to organize the discussion. It is a recommended working method, not a numerical risk model or a substitute for your organization's obligations.
Do not turn this table into a queue sorted only by ease of completion. Removing unused software can be worthwhile, but a program should still explain what is happening to its hardest, most consequential dependency.
Make the migration blocker concrete
“The business cannot migrate” is too broad to manage. Replace it with a specific dependency and an observable next step.
Perhaps a reporting tool requires an old runtime. The next step might be testing the report against a supported runtime, changing its connector, or replacing the reporting workflow. Those are different projects with different owners. Leaving them under one generic exception makes it difficult to tell whether anything has moved.
We recommend recording four items together: the business function, the dependency preventing retirement, the person who can remove that dependency, and the evidence they will produce next. Keep the retirement owner distinct from the team maintaining temporary controls if those responsibilities belong to different people.
For broader upgrade context, see OS upgrades and patch management for resilience. The decision here is narrower: what must change so this particular unsupported service can stop operating?
What should happen while migration is unfinished?
Reduce the routes through which the obsolete product can receive untrusted content and limit what a compromise could reach. UK NCSC guidance describes both approaches, including restricting connectivity and removing unnecessary services. It explicitly cautions that these measures do not provide a risk-free way to keep obsolete products running. NCSC obsolete-products guidance.
Our recommendation is to connect each temporary measure to a specific exposure. “Segmentation enabled” is a weak decision record. “Only the approved reporting service can connect to this application from the designated network” states a condition that can be checked.
Then ask what would invalidate that condition. A new integration, a broader access rule, or a change in how files reach the service may require a fresh decision. Do not wait for the next calendar review if the reason for accepting continued operation has changed.
Where approved automation can maintain a restriction or identify drift, use it within the organization's change controls. Keep the consequential judgment separate: whether continued operation remains acceptable and whether the retirement milestone should move. Neither decision should disappear behind a successful control check.
A retirement plan needs a business acceptance test
Consider a hypothetical finance application retained because it produces a monthly reconciliation report. The replacement can generate the report, but the team has not tested its export to a downstream system.
Calling the migration almost complete hides the unresolved dependency. A more useful milestone is: the finance owner accepts a representative reconciliation and the downstream owner confirms that the replacement export works.
The team can then decide what historical data must remain accessible, where that access will live, and how long a controlled recovery option is needed. Retaining records does not automatically require keeping the old application in routine production.
NCSC's decommissioning guidance emphasizes understanding dependencies, preparing recovery, and verifying that replacement assets work before irreversible actions. It also recommends testing the rollback plan or its key elements where possible. NCSC decommissioning guidance.
In this example, we would make the final milestone removal of the operational dependency, not installation of the replacement. The service owner should be able to explain how the business function continues without reconnecting the obsolete application.
Define what closed means before cutover
We recommend agreeing the closure evidence before the migration window. Otherwise, different teams may use the same word for different states: installed, accepted, disconnected, or retired.
For an application retirement, the closure record should answer:
• Is the required business function operating on the replacement?
• Where are retained records, and who can access them?
• Which old connections and credentials are no longer needed?
• What remains for recovery, under whose authority, and until when?
• Has the inventory been updated to match the actual state?
Adapt the questions to the system. They are not instructions to delete records or disable dependencies without review. An owner may need to preserve a controlled recovery copy, but that decision should describe its purpose and access conditions rather than leaving an unexplained running server.
Report retirement progress without hiding the unfinished work
We recommend showing completed retirements separately from systems operating under temporary controls. Report overdue dependency milestones alongside the number of obsolete installations.
A lower installation count can be encouraging while a critical application remains unchanged. Conversely, a short-term increase may reflect better discovery. Explain changes in scope so leadership can distinguish new visibility from new exposure.
For each delayed retirement, the useful management question is specific: which decision or deliverable is preventing exit? That turns the discussion toward funding, integration ownership, or service redesign instead of another unexplained extension.
Frequently asked questions
Does end-of-life software always stop working?
No. Functional operation does not establish current support or acceptable risk. The Canadian Centre for Cyber Security notes that obsolete products may continue to meet functional needs while introducing security and operational risks. Check the support status separately. Canadian guidance.
Is end of life the same as end of support?
Not necessarily. Verify the supplier's lifecycle policy and the exact release. An EOL announcement and the end of technical or security support can be separate milestones. NCSC product-support advisory.
Can isolation replace migration?
Isolation can reduce particular exposure routes, but it should not be described as a permanent substitute for retiring obsolete technology. Our recommendation is to connect it to an owned transition plan and explicit review conditions. NCSC obsolete-products guidance.
What proves that a retirement is complete?
We recommend requiring business acceptance of the replacement, an agreed disposition for retained data, removal of unnecessary access, and an inventory that reflects reality. Record any remaining recovery dependency explicitly. A completed installation alone does not demonstrate that the old service is no longer needed.
Choose one dependency to remove
Take one unsupported application from the retirement backlog. Name the business function keeping it alive, the next piece of evidence needed to move it, and the owner of that deliverable. Agree what will happen if the milestone slips. Use that decision to make the retirement date credible.
.webp)
%20Signals%20a%20New%20Era%20of%20Supply%20Chain%20Risk.webp)
