Angular End of Life —
The 18-Month Treadmill & Every EOL Date

Angular — the TypeScript framework, versions 2 through 22 — has one of the shortest support windows in mainstream front-end development: roughly 18 months per major version. A new major ships about every six months, which means a version reaches end of life every six months too. Right now, Angular 19 has already reached EOL (May 19, 2026), and only Angular 20, 21, and 22 are still supported.

This is a different product from AngularJS (1.x), which is a separate, fully end-of-life framework — don't confuse the two. This page covers modern Angular (2+): every version's EOL date and EOL Risk Score™, why teams fall behind so fast, the ng update path forward, and extended-support options for versions you can't move off yet.

Angular Version EOL Schedule

Every Angular major from 2 through 19 is now end of life. Only 20, 21, and 22 are within their support window. Scores below are live EOL Risk Scores™ — click any to see the full breakdown.

The 18-Month Support Policy Explained

Angular's support model is fixed and predictable — which is exactly what makes falling behind inexcusable, and also exactly why so many teams do.

Each major version gets about 18 months of support, split in two: 6 months of "active support" (regular updates and bug fixes) followed by 12 months of "long-term support" (LTS) (critical fixes and security patches only). After that 18-month total, the version is end of life and receives nothing further.

A new major ships roughly every six months (historically around May and November). Do the arithmetic and the treadmill is obvious: with a new release twice a year and an 18-month window, there are only ever about three supported majors at once — and one of those three drops off every six months. Skip two release cycles and you are already on borrowed time.

Angular 20, 21 & 22 — The Supported Versions

How to Stay Current with ng update

Angular is designed to be upgraded one major at a time, and the CLI does most of the work. The failure mode is not the mechanics — it is letting too many versions pile up so the jumps compound.

• 01
  Find your current version and the gap Run ng version. Cross-reference against the table above to see how many majors behind you are and when your version reached (or reaches) EOL. That gap is your migration backlog.
• 02
  Upgrade one major at a time Use the official Angular Update Guide and run ng update @angular/core@N @angular/cli@N for each successive major. Do not skip majors — the automated migrations (schematics) are written to run between adjacent versions. Commit and test after each one.
• 03
  Let the schematics do the refactors ng update runs code migrations automatically — standalone components, the new control-flow syntax, signal inputs, removed APIs. Review each migration's diff rather than rubber-stamping it, but most mechanical changes are handled for you.
• 04
  Update the ecosystem in lockstep Angular Material, NgRx, and third-party component libraries each track Angular's majors. Update them alongside core — a lagging library is the most common thing that blocks an ng update. Check each dependency supports your target major before you start.
• 05
  Make it a standing schedule, not a project Put the next two Angular EOL dates in your roadmap now and book the upgrade before each one. On a six-month cadence, the only sustainable strategy is to treat upgrading as routine maintenance — small, frequent, and never deferred until it's an incident.

Extended Support for Older Angular

Plenty of production Angular apps are stranded several majors back — often on Angular 12–16 — because an upgrade was deferred until the cumulative gap became a daunting project. Those apps are now running EOL framework code, shipping unpatched to every user's browser, with Risk Scores of 60–70.

Extended (post-EOL) support bridges that gap. Specialist vendors maintain security-patched builds of older Angular majors — backporting fixes for newly disclosed vulnerabilities — so a stranded app stays protected while you plan a staged path back to a supported version. It buys you a safe runway to do the ng update work properly instead of under incident pressure.