- Software may still open after support ends, but the vendor may stop security fixes and normal help. That turns a quiet date into a growing business risk.
- Keep one calendar with the product, version, owner, support date, business use, replacement path and next decision. Confirm each date at the vendor source.
- Use reminders at 180, 90 and 30 days. Upgrade, replace or reduce access before the deadline, then remove old copies and update the inventory.
Software does not switch off when support ends; it may keep opening, serving customers and moving data, which makes the deadline easy to miss.
The change is quieter: a vendor may stop security fixes, normal support or tested updates for that version, so new flaws can remain open. A rushed move may also break linked tools or block access to old data.
A software support calendar puts each known date in one place. It also names an owner and the next action. A small team can start the first version in one hour.
Why support dates need attention now
Fresh US guidance gives small firms a clear first step: NIST's April 2026 draft for very small businesses says to keep an inventory of important hardware, software, data and cloud services. A list is useful because a team cannot plan for a product it has forgotten.
UK guidance is just as direct: the National Cyber Security Centre says obsolete products no longer receive security updates and may lack newer defences. It advises buyers to consider the support lifetime when they choose hardware or software.
The UK Software Security Code of Practice raises the bar for vendors by asking them to explain the support and maintenance they provide. It also calls for at least one year's notice before support ends, which is a good buying question even when the code is voluntary.
Current vendor calendars show why this work cannot wait for a once-a-year audit. Microsoft's 2026 list includes products and versions ending support on several dates, while every supplier uses its own names, stages and rules. Your calendar must point to the source for each product you use.
Start with the tools that keep work moving
Do not begin with every browser add-on and test app; start with software that stores important data, controls access, takes payments, runs a website or supports daily work.
Ask finance for paid renewals, IT for managed devices and servers, and team leads for the web apps they use. Review sign-in records and browser extension lists for tools that purchasing may not know about.
Give each product one row. If two teams use different versions, create two rows because their support dates may differ.
| Field | What to record |
|---|---|
| Product and version | The exact service, app, device software or code package in use. |
| Owner and business use | The person who can decide, plus the work and data that depend on it. |
| Support date and source | The vendor date, policy stage and direct source link. Mark an unknown date clearly. |
| Impact | Users, data, linked tools, public access and the cost of downtime. |
| Decision | Upgrade, replace, retire, isolate for a short time or seek extended support. |
| Next check | The next owner action, due date, test date and approved budget. |
Keep the first sheet simple. A long asset tool is not required. The calendar must be clear enough for another person to use if the normal owner is away.
Confirm the date at the vendor source
Terms such as end of sale, end of service and end of life do not always mean the same thing: one stage may end feature work, another may end security fixes, and paid extended support may have its own final date.
Use the vendor's lifecycle page, release notes or support notice as the main source, then save the link and the date you checked it. Do not rely on a search snippet or a third-party calendar for the final decision.
For software as a service, ask how forced upgrades and retired features are handled. Record the notice period, data export path and any action your team must take. Our software vendor evidence checklist has wider questions about updates and incidents.
Mark unknown dates as a task, not as “no deadline,” then contact the supplier and give the question an owner. Silence is not proof of long support.
Use 180, 90 and 30-day reminders
Set the first reminder 180 days before the support date, then confirm the version, owner and business need. Check links to other systems, licences, devices and stored data, and ask for a rough cost and a safe test space.
At 90 days, choose the path: upgrade to a supported version, replace the product or retire the work. Test data export and restore, then check that users can complete the main task in the new setup.
At 30 days, close the gaps by booking the change window and confirming backups, rollback steps, user notice and vendor help. Run a final access review and remove accounts that are no longer needed.
A high-risk system may need earlier reminders. A complex server, medical device or custom app can take more than six months to replace. Start when the calendar shows the risk, not when the deadline feels close.
Choose an exit path before the deadline
An upgrade is often the shortest route, but it is not automatic. Check hardware needs, licence changes, file formats and links to other systems. A supported version can still be a bad fit if it breaks the work around it.
A replacement needs a data map. List what must move, what can be archived and how the old data will be read later. Test the export before the final week. A vendor promise is not the same as a file your team has opened.
Some software should be retired. Remove the app, service account, API key, firewall rule and old installer when the work ends. Update the inventory and keep only the records the business must retain.
If a short delay is unavoidable, write down the risk and the end date. Limit who can reach the system. Remove public access where possible, block new features and watch logs. NCSC guidance is clear that these steps do not make an obsolete product risk-free.
Plan the change around real work
The support date is only one part of the plan. A safe move also needs a tested backup, a clear owner and a way back if the change fails. Our backup restore test explains how to prove that a saved copy can support real work.
Check admin access before the change. Use a clean account with strong sign-in protection, and avoid doing the work from an everyday browsing session. The separate admin browser profile guide gives a simple setup.
Tell users what will change and when. Give them one place to report missing data or broken steps. Keep the old system read-only for a short, agreed period only when this is safe and needed.
Put support terms into the next purchase
A calendar works better when the dates arrive before a contract is signed. Ask how long the current version will receive security fixes. Ask how much notice the vendor gives and whether export tools remain available after cancellation.
Record the answer in the contract or order notes. Link it to the renewal date. This gives the team time to compare the cost of staying with the cost of moving. It also reduces the hidden work behind switching SaaS tools.
Review the calendar for 20 minutes each month. Look at the next 12 months, chase unknown dates and close finished rows. The goal is not a perfect database. It is enough warning to make a calm, tested choice before updates stop.
Sources and further reading
- NIST: Small Business Cybersecurity for Non-Employer Firms
- UK NCSC: Obsolete products
- UK Government: Software Security Code of Practice
- Microsoft Lifecycle: Products ending support in 2026
- UK NCSC: Decommissioning assets
Frequently asked questions
What is software end of support?
It is the date after which a vendor no longer provides some or all fixes, updates or normal help for a product or version. Exact terms vary, so check the vendor policy.
How early should a team plan for software end of support?
Start at least six months before a known date for a normal business tool. Complex systems, hardware links and regulated data may need a year or more.
Can a business keep using unsupported software?
It may keep running, but the risk grows when new flaws receive no fix. If a short delay is unavoidable, limit access, isolate the system, monitor it and set a firm retirement date.