Legacy Technology Tracker Methodology

The Legacy Technology Tracker publishes facts, not scores. For each technology it records the support status, the dates that matter, paid extended-support options, vulnerabilities known to be exploited, evidence that the technology is still in use, and its last release. Every value links to its source and carries the date we checked or retrieved it. A short rating rule turns those facts into a risk level; there are no weights.

This page explains where the data comes from, what each date means, how ratings are assigned, what the data cannot tell you and how to cite it. The site-wide approach to sources and corrections is on our methodology page.

Sources, licences and attribution

The tracker data itself is released under CC BY 4.0. Source data stays under its own terms.

Dates and what they mean

Vendors use the same words for different things, so the tracker uses three fixed terms:

• End of mainstream support: the end of mainstream (active) support, when new features and non-security fixes stop.
• End of standard support: the end of the vendor's standard support, including security updates, that comes with the licence. Microsoft calls this the "Extended End Date".
• End of paid extended support: the end of a support period bought separately, such as Microsoft Extended Security Updates (ESU), Oracle Extended Support or a paid IBM extension. Microsoft's "Extended End Date" is never recorded here.

End dates are the last day of support, as vendors publish them. Support still applies on that day and lapses the day after. "Months until" and "months since" count whole calendar months from the data-as-of date to that day after.

When a vendor publishes only a month, the date is stored as the last day of that month and shown as month and year (for example "Apr 2026").

Where an editor has verified the vendor's own lifecycle page, its date replaces the endoflife.date value for that field and the vendor page is shown as the source, with the date it was checked. Other dates come from endoflife.date and are labelled as such.

Support status

A technology is as supported as its best version in scope, because an owner can stay on the technology by upgrading within it:

• Supported: at least one version in scope is in standard support.
• Paid extended support only: no version is in standard support, but paid extended support is still available for at least one.
• Unsupported: every version in scope has passed the end of all vendor support.
• Not verified: we have no verified date or end-of-life flag yet. These entries are tracked but not rated.

Each entry is either fixed (a finished product or version set, such as Windows Server 2012 or AngularJS, whose last end date is the end) or rolling (the vendor keeps shipping new versions, as with Rails, PHP or vSphere, so the newest version's end date is not an end for the technology). Third-party support offers, such as HeroDevs for AngularJS, are listed separately and do not change the status.

Risk rating rules

Each rating uses only the facts on the page and is published with its reason in words, for example "High: support ended 31 Dec 2020; 36 vulnerabilities on CISA's KEV list."

• High: the technology is unsupported, or its paid extended support ends within 12 months, and it has at least one entry on CISA's KEV list or no releases since support ended.
• Elevated: only paid extended support remains, or standard support ends within 24 months, or the technology is unsupported with no KEV entries.
• Watch: supported for at least another 24 months, but with a dated warning sign: a licence change or end-of-sale announcement recorded in the last 24 months, or falling job postings. A licence change counts in either direction (for example Redis moving to a source-available licence in 2024 and adding AGPLv3 in 2025), because either one changes what an owner has to review.
• Low: supported for at least another 24 months with no dated warning sign recorded. "No licence change recorded" means none is in our records for the period; it is not a guarantee that none happened. A supported product can be rated Low and still have KEV entries; the reason says so, because supported versions receive security fixes.
• Not rated: the support status is not verified.

Implementation rules:

• For rolling products, the 24-month test ignores the end date of the newest version. That date is still shown as a fact.
• "No releases since support ended" is evaluated only for unsupported products: it compares the newest in-scope release date with the end of support. It is not evaluated for products in paid extended support, because paid patches (for example Microsoft ESU) do not appear in public release data.
• A licence change or an end-of-sale announcement counts as a warning sign for 24 months from its date, then remains on the page as a fact. The reason names which one it is ("licence change …" or "end of sale announced …").
• Falling job postings will count only once job-posting data is published. Until then no rating depends on it.

How exploited vulnerabilities are matched

The CISA KEV catalog names a vendor and a product for each CVE. We match in one of two ways, and each count says which:

• By product name: exact vendor and product strings from the catalog, ignoring case and extra spaces. Used when the catalog names the product itself (for example Adobe ColdFusion).
• By version, through NVD data: used when the catalog names only a product family, such as "Microsoft Windows" without versions. We count KEV-listed CVEs whose NVD product (CPE) configuration matches the versions in scope, for example Windows Server 2012 and 2012 R2.

Counts are de-duplicated by CVE and shown for all time and for the 24 months before the as-of date, with the date the newest entry was added. Where a count would mislead, KEV is marked "not tracked" for that entry.

Why usage is shown as a share of the crawl

HTTP Archive crawls millions of home pages each month and records which technologies it detects on them. The crawl itself changes size: between August 2025 and August 2026 the mobile crawl fell from 9,297,415 to 8,900,615 home pages (about 4%) and the desktop crawl from 5,876,485 to 5,379,682 (about 8%). A raw count can fall only because the crawl shrank, so trends are read from the share of all crawled pages, and every count is shown with its share and crawl month.

The table shows the mobile crawl, which is the larger of the two; fact pages show desktop too. A count that is not version-scoped covers every version HTTP Archive detects, and is labelled that way (for example "CentOS, all versions" on the CentOS 7 entry). Where the version can be detected (Drupal 7, Magento 1, jQuery 1.x and 2.x, PHP 5 and 7), a version-scoped count is shown and labelled.

npm counts are downloads from the npm registry in the last complete seven-day window before the refresh, with the same window a year earlier.

Update cadence

• Monthly refresh: collectors re-read every source, the changes are reviewed as a diff, and the results are published as a new monthly data set.
• Daily status: support status, months until or since each date, and the risk rating are recalculated every day from the latest monthly data, so a support end that passes between refreshes shows the next day. Pages and downloads therefore state two dates: "status as of" (the day of the calculation) and "data checked" (the day the sources were read).
• Quarterly snapshot: at the end of each quarter the month's data is frozen as an unchangeable snapshot. The quarterly Legacy Technology Report and any quarter-on-quarter comparison use snapshots only. Errors found later are recorded as errata alongside the snapshot rather than by editing it.
• The methodology is versioned. The current version is shown on the tracker page and in the downloads.

Limitations

• HTTP Archive counts home pages, not applications. Internal systems, intranets and pages behind a login are invisible to it, and a site counts once however many applications it runs. Usage figures are evidence that a technology is still deployed on the public web, not a count of installations.
• Detection depends on fingerprints. HTTP Archive relies on Wappalyzer detection; many sites do not reveal a version, so version-scoped counts are lower bounds.
• The crawl changes size from month to month (see above).
• KEV lists only vulnerabilities known to be exploited. No KEV entries does not mean no vulnerabilities, and software that is rarely internet-facing may be under-represented.
• Version scoping depends on NVD data, which can be incomplete or lag behind new CVEs.
• endoflife.date is community-maintained. Dates we have checked against the vendor's own page are shown with the vendor as the source; the rest are labelled endoflife.date.
• npm downloads include automated installs such as build servers and mirrors; they measure activity, not the number of applications.
• Coverage is a selection, not a census: technologies behind the migration paths on this site, high-profile end-of-support events and widely deployed legacy web technologies.

Corrections

If a date, count or source is wrong, tell us through the contact details on our About page and include the source that shows the correct value. We check it against the source, correct the next refresh, and record the correction here with the date and the values changed. Published quarterly snapshots are not edited; corrections to them are recorded as errata.

No corrections have been recorded yet.

How to cite

Cite the tracker with its version and data-as-of date, both shown on the tracker page:

Software Modernization Intelligence. Legacy Technology Tracker, version [version], data as of [date]. https://softwaremodernizationservices.com/legacy-technology-tracker/. Licensed under CC BY 4.0.

To quote a single fact, keep its date with it and link to the technology's page. Please also credit the original source named next to the value (CISA, HTTP Archive, endoflife.date or the vendor).