A software end-of-support review checklist turns a vague upgrade concern into a controlled decision. Inventory the product and version, verify the vendor's support date, map every dependency, assess exposure, choose a replacement or containment path, and test recovery before the deadline. The goal is not to upgrade everything at once. It is to stop unknown unsupported software from quietly becoming a business dependency.

Verify the lifecycle fact with the vendor

Start with the exact edition, version, operating system, and deployment type. Similar product names can have different support dates. Use the vendor's lifecycle page, release notes, or support bulletin and record the source URL and the date checked. Microsoft's Lifecycle site is an example of a first-party index for product support and retirement dates.

Distinguish between end of mainstream support, end of security updates, end of extended support, and retirement of a cloud feature. Write the vendor's language in the record instead of compressing every event into the label end of life.

Build an owner-and-dependency inventory

For each product, record:

  • business owner and technical owner
  • devices, servers, or accounts where it runs
  • data stored, processed, exported, or synchronized
  • integrations, scripts, browser extensions, and file formats it touches
  • authentication method and service accounts
  • backup and restore procedure
  • contract, renewal, and license dates
  • vendor support deadline and evidence link

Interview the people who use the workflow. An application can appear unused in a central console while still powering a month-end export or a single critical workstation.

Prioritize by exposure and business impact

CISA has advised organizations to evaluate unsupported hardware and software and discontinue use as soon as possible because obsolete technology can remain exposed to known weaknesses and no longer receive normal vendor remediation. Microsoft's Windows lifecycle FAQ likewise explains that products outside support no longer receive technical assistance or software and security updates.

Score each finding using practical factors: internet exposure, administrative privilege, sensitive data, number of users, ease of exploitation, availability of compensating controls, and operational impact if the tool stops. A public-facing server with no security updates should normally rank ahead of an isolated utility that processes no sensitive data, but the final decision should be documented rather than assumed.

Choose a treatment and name the deadline

Use one of four explicit dispositions:

  1. Replace with a supported product or version.
  2. Remove because the workflow is no longer needed.
  3. Isolate temporarily with documented controls and an approved retirement date.
  4. Accept the risk through the organization's actual approval process.

Temporary containment can include restricting network access, removing local administrator rights, disabling unused services, separating sensitive data, increasing monitoring, and limiting who can sign in. These measures can reduce exposure, but they do not turn unsupported software into a supported product.

Test the replacement like a recovery exercise

Create a representative test with copied or synthetic data. Verify installation, authentication, permissions, imports, exports, reports, integrations, printing, accessibility, and backup restoration. Keep the old system available only as long as the transition plan requires, and prevent new records from splitting between two systems without a reconciliation method.

For file-based workflows, test several old files, including a complex example. For server software, test monitoring, logging, certificates, scheduled tasks, and disaster recovery. Record defects, owners, and retest dates.

Complete the retirement evidence

Before closure, confirm that the unsupported version is no longer running, scheduled tasks and integrations were moved, service accounts were disabled or repurposed intentionally, data retention requirements were met, and backups can be read by the supported environment. Update the asset inventory and attach the vendor lifecycle evidence.

Set a recurring review at least often enough to catch known support dates before they become emergencies. The useful output is a short register: product, version, owner, deadline, risk, chosen action, test evidence, and completion state. That register gives a small team a repeatable way to make lifecycle work visible and accountable.

Sources

  1. Top Ten Cybersecurity Misconfigurations — Cybersecurity and Infrastructure Security Agency
  2. Microsoft Lifecycle — Microsoft Learn
  3. Windows lifecycle FAQ — Microsoft Learn

Related reading