Angular 20 End of Life Explained: Upgrade to 22 Before 28 November

Nothing breaks on the day, and that is the trap. Angular 20 end of life means no more patches from the Angular team after 28 November 2026. Your app builds and runs exactly as before, but any security bug found later stays unfixed in version 20.

Picture a common setup. A services team in Pune maintains an order-tracking portal for a retail client, built on Angular 20 in mid-2025 and untouched since. The client's yearly security audit asks for supported framework versions, and the report is due in December. The setup is made up, but the dates and the upgrade path are real.

This guide follows that portal from Angular 20 to Angular 22. Our stand-in for it is a small Angular 20 test app with one order badge component. Every command output shown here is from upgrading that app with the real tools.

You need six terms. Each one gets a plain meaning here, and the rest of the guide uses them on the portal.

• npm, package.json and npx. npm is the registry where JavaScript packages live, and also the tool that installs them into a node_modules folder. package.json lists the packages your app needs, and npx runs a command from them, such as ng.
• Major, minor and patch. Angular versions look like 20.3.34: major 20, minor 3, patch 34. Majors can break your code. Minors add features without breaking changes, and patches only fix bugs.
• Active support. The first phase of a major, when it gets regular updates and new minors. Angular 22 was in this phase as of 26 October 2026.
• LTS, or long-term support. The second phase, when a major gets only critical fixes and security patches. Angular 20 and 21 were both in LTS as of 26 October 2026.
• ng update. The Angular command line tool's upgrade command. It bumps the Angular packages in package.json, installs them and then runs migrations.
• Migration. A small script shipped inside an Angular package that edits your code for you, for example moving an import that changed packages.

Angular 20 end of life is 28 November 2026, the date in the LTS ends column of Angular's official releases page. Angular 20 came out on 28 May 2025. Its active support ended on 19 November 2025, when Angular 21 shipped, and LTS began.

End of LTS means the Angular team stops releasing 20.x patches. The releases page lists versions 2 to 19 as no longer supported. It does not promise anything for a version once its LTS ends.

Notice that only the Angular 20 row has an exact day. The table prints June 2027 for Angular 21 and June 2028 for Angular 22 as months only. If a blog post gives you an exact day for those, it did not come from this table.

What LTS covers, and what it does not

The releases page says a fix is considered for an LTS version if it resolves one of two things. The first is a newly found security vulnerability. The second is a regression since LTS began, caused by a third-party change such as a new browser version.

Everything else, including new features and ordinary bug fixes, goes only into the active major. LTS has still been busy: npm shows 19 patch releases of @angular/core 20.3.x published in 2026 up to 14 October.

Will your Angular 20 app stop working?

No. Old versions stay on npm, the public registry where JavaScript packages live, so installs and builds keep working. As of 26 October 2026, npm still serves Angular 19, which the releases page lists as no longer supported, under its v19-lts tag at 19.2.25.

The real cost is risk. The October 2026 HttpClient advisory shows the pattern: 20.3.34 got the fix, and the advisory says the 19.x line will not be patched. After 28 November, Angular 20 is in the same position as 19.

Go to Angular 22 if you can. You have to pass through 21 anyway, and 22 gives you the longest runway: active support until June 2027 and LTS until June 2028.

Angular 21 is a stop, not a destination. Its LTS ends in June 2027, so stopping there means doing this again before then. The trade is that 22 asks for more: a newer Node.js, the program that runs Angular's tools, and TypeScript 6.0, the typed JavaScript that Angular code is written in.

There is one more reason to land on 22. The releases page says majors now come every 12 months, not every 6, and are typically supported for 24 months. Angular 20 and 21 came out before this change, and their own table rows show shorter windows.

Because the code changes for each major ship inside that major's own package. In our check, @angular/core 22 carried only the migrations for 22, so a jump from 20 would skip the 21 edits.

The releases page states the rule without the reason: the target must be supported, and your current version must be within one major of it. It says to update across several majors one major at a time.

We tried the shortcut on our Angular 20 app. Here is what ng update printed:

$ npx ng update @angular/core@22 @angular/cli@22
The installed Angular CLI version is outdated.
Installing a temporary Angular CLI versioned 22.2.4 to perform the update.
Using package manager: npm
Collecting installed dependencies...
Found 20 dependencies.
Fetching dependency metadata from registry...
Updating multiple major versions of '@angular/core' at once is not supported. Please migrate each major version individually.
Run 'ng update @angular/core@21' in your workspace directory to update to latest '21.x' version of '@angular/core'.

For more information about the update process, see https://update.angular.dev/?v=20.0-21.0

Only that temporary CLI was downloaded, so the shortcut is safe to try. It just will not work. For the portal, the plan is two hops.

For most apps, ng update does the code changes and you review them. Each hop has one headline change worth knowing before you start.

Angular 20 to 21 needs TypeScript 5.9. It also changes setup for apps that use zone.js, the helper library that tells Angular when something may have changed. What changes is change detection, the way Angular decides when to re-draw the screen.

A migration adds the needed setup line if it is missing. In our test app, this hop changed no source files.

Angular 21 to 22 needs TypeScript 6.0 and a newer Node.js. Components now default to a more selective re-draw mode called OnPush, and a migration pins your existing components to the old mode. HttpClient now defaults to the browser's fetch API, and another migration keeps existing apps on the old backend.

One default has no migration: how child routes inherit route parameters. The engineer section shows the one line that keeps the old behaviour.

Both hops have a longer list of removed and stricter APIs. Most apps touch few of them, and the engineer sections after the stop line cover each one.

Do two separate hops, each on its own git branch with a commit at the end. These are the steps we followed on the portal's stand-in app, on Node 22.23.4.

1. 1

   Check your starting point

   Run npx ng version and note the Angular and CLI versions. Commit or stash your changes first, because ng update refuses a dirty git tree.

2. 2

   Take the latest Angular 20 patch

   Run npx ng update @angular/core@20 @angular/cli@20. In our test it moved @angular/core from 20.3.33 to 20.3.34, the release with the XSRF fix. Build, test, commit and ship this even before the major upgrade.

3. 3

   Check your other Angular libraries

   List libraries such as UI kits or state libraries and check that their latest versions support Angular 21, and later 22. Our test app had none. Avoid ng update --force unless you know why a check failed.

4. 4

   Move to a supported Node.js

   Angular 22 needs Node 22.22.3 or newer, or 24.15.0 or newer. Prefer Node 24: Angular 21 and 22 both list it, and the Node.js schedule supports it until 30 April 2028. Node 22 ends on 30 April 2027.

5. 5

   Update to Angular 21

   Run npx ng update @angular/core@21 @angular/cli@21. If you use Angular Material, run ng update @angular/material@21 too, as the official update guide says.

6. 6

   Read the migration log

   ng update prints each migration and whether it changed files. Note any optional migrations it offers; you can run them later by name.

7. 7

   Build, test and commit 21

   Run npx ng build and your test suite, fix anything that fails, then commit. Deploying here is a valid checkpoint.

8. 8

   Update to Angular 22

   Run npx ng update @angular/core@22 @angular/cli@22, plus ng update @angular/material@22 if you use it. This also moves TypeScript to 6.0.

9. 9

   Review the 22 diff

   Read every file the migrations touched, then build, test, commit and ship.

git switch -c upgrade-angular-21
npx ng update @angular/core@21 @angular/cli@21
npx ng build
npx ng test
git add -A
git commit -m "Update to Angular 21"

git switch -c upgrade-angular-22
npx ng update @angular/core@22 @angular/cli@22
npx ng build
npx ng test
git add -A
git commit -m "Update to Angular 22"

We ran the ng update, ng build and commit steps on our test app, on one branch rather than two. We did not run ng test, because our machine had no Chrome browser for the Karma test runner. Run your tests anyway: some Angular 21 and 22 changes show up mainly in tests.

Angular's interactive update guide at angular.dev/update-guide builds a checklist for your exact jump and app complexity. Use it for each hop, with the from and to versions set one major apart.

Run npx ng version after each hop and compare the versions with what you expect. After the second hop, our app showed these lines, trimmed to the important rows:

Angular CLI       : 22.2.4
Angular           : 22.2.3
Node.js           : 22.23.4
Package Manager   : npm 11.6.2
...
@angular/core             | 22.2.3 | ^22.2.3
typescript                | 6.0.3  | ~6.0.3
zone.js                   | 0.15.1 | ~0.15.0

Expect Angular 22.x and TypeScript 6.0.x. If npx ng version instead fails with "could not determine executable to run", or prints an error where the Angular version should be, the install step failed. We saw both in copies of a failed project: package.json said 21, node_modules was gone and no migrations had run.

Then run npx ng build. Ours ended with "Application bundle generation complete" and an initial bundle of 256.58 kB raw, with an estimated transfer size of 72.06 kB.

Note your bundle size before and after each hop. In our run the initial raw total went from 249.79 kB on 20 to 254.01 kB on 21 and 256.58 kB on 22. Each hop added under 5 kB here, so a jump of tens of kB means something new got pulled in.

Angular 20 and 21 run on Node.js 20.19 or newer in the 20 line, 22.12 or newer in the 22 line, or Node 24, while Angular 22 drops Node 20. TypeScript moves up each hop too. These ranges come from angular.dev's version compatibility page and match the engines field in the npm packages.

The caret in ^22.22.3 means any 22.x release at 22.22.3 or above. The versions page only lists 22.0.x, but the engines field in @angular/cli 22.2.4 and @angular/core 22.2.3 asks for the same Node versions.

One source disagrees. The Angular CLI 22.0.0 release notes give the minimums as Node 22.22.0 and 24.13.1. The shipped packages and the versions page require 22.22.3 and 24.15.0, so use the higher numbers.

We ran the Angular 22 CLI on Node 20.19.5 to see what happens. It stopped before doing anything, with exit code 3:

$ node node_modules/@angular/cli/bin/ng.js version
Node.js version v20.19.5 detected.
The Angular CLI requires a minimum Node.js version of v22.22.3 or v24.15.0 or v26.0.0.

Please update your Node.js version or visit https://nodejs.org/ for additional instructions.

So upgrade Node on developer laptops and in CI, the automated build machines, before the 21 to 22 hop. Node 20 reached end of life on 30 April 2026 according to the Node.js release schedule, so it is worth leaving even if you stay on Angular 21. Node 26, which the schedule makes LTS from 28 October 2026, is listed on the versions page only for Angular 22. Angular 21's packages do not block it, but it is not a listed pairing for the 21 hop, so Node 24 is the safer choice for both hops.

For most apps, very little that ng update does not fix. The official 21.0.0 changelog lists the breaking changes. In our test app, the 20 to 21 migrations ran and changed no source files, and the production build passed.

Our app was a fresh project from Angular CLI 20.3.41, which is the best case. Apps first created on older Angular versions may carry older patterns and see more migration edits.

Zone-based change detection must be asked for

The 21.0.0 changelog says Angular no longer provides a change detection scheduler for zone.js apps by default. Zone.js is the helper library that tells Angular when something may have changed. Apps that use it need provideZoneChangeDetection in their providers, the list of services set up at start-up.

The migration that adds it shows in the log as "Migrates deprecated bootstrap options to providers". Its source in @angular/core 21.2.25 skips apps that already set up change detection. Our app already had provideZoneChangeDetection with event coalescing in app.config.ts, so the log said no changes.

Removed APIs and stricter checks

• TypeScript older than 5.9 is no longer supported. Our app already had TypeScript 5.9.3, so nothing changed.
• Removed: moduleId in component metadata, the component interpolation option, NgModuleFactory, ignoreChangesOutsideZone and the old UpgradeAdapter for AngularJS hybrids.
• ApplicationConfig is no longer exported from @angular/platform-browser. A migration moves the import to @angular/core.
• Router.lastSuccessfulNavigation is now a signal, a value you read by calling it like a function. A migration updates the call sites.
• Router navigations can take a few extra microtasks, small queued steps, to finish. Tests that assert right after navigating may need to wait.
• Host bindings, the bindings a component declares on its own element, are now type-checked, so hidden type errors there can fail your build.
• The CLI no longer auto-detects cnpm as a package manager, and zone.js drops Internet Explorer and the old non-Chromium Edge.

An upgraded app is not the same as a new Angular 21 app

Angular 21 made new projects zoneless, with Vitest as the default test runner. Upgrading does not convert you. After ng update, our app still had zone.js, the Karma test runner and provideZoneChangeDetection.

A fresh project from CLI 21.2.28 had no zone.js at all, and used Vitest with jsdom, a browser simulator, for tests. The v21 launch post says Karma and Jasmine are still fully supported. Moving to zoneless or Vitest is a separate project you can schedule later.

Angular 22 changes more defaults than 21 did. The biggest is change detection: components that do not set a strategy are now OnPush, which re-checks a component mainly when its inputs or signals change. The 22.0.0 changelog and update guide list the rest.

OnPush becomes the default, and the migration pins the old behaviour

The old default strategy is now called Eager. To keep your app behaving as before, the 22 migration adds ChangeDetectionStrategy.Eager to your components. Here is what it did to our order badge component:

-  changeDetection: ChangeDetectionStrategy.Default,
+  changeDetection: ChangeDetectionStrategy.Eager,

It also added changeDetection: ChangeDetectionStrategy.Eager to our root component, which had no strategy set before. In 22.2.3, Default still exists as a deprecated alias that equals Eager, so old code compiles.

Templates and the compiler get stricter

• TypeScript older than 6.0 is no longer supported. ng update moved our app from 5.9.3 to 6.0.3 by itself.
• The strictTemplates compiler option now defaults to true. A migration adds strictTemplates: false only if your tsconfig, the TypeScript settings file, does not set it.
• Optional chaining in templates, the ?. operator, now returns undefined instead of null. A migration wraps existing expressions in $safeNavigationMigration() to keep the old result.
• Two template diagnostics may start firing. The migration switched off nullishCoalescingNotNullable and optionalChainNotNullable in our tsconfig.app.json and tsconfig.spec.json.
• data- prefixed attributes no longer bind to inputs or outputs, and duplicate input or output bindings now fail compilation.
• An element matched by multiple component selectors now fails at compile time.

HttpClient, router and removed APIs

• HttpClient now uses the browser's fetch API by default. On upgrade, a migration adds withXhr() to provideHttpClient() calls that set neither withFetch nor withXhr, so your app keeps the older XMLHttpRequest backend. Keep it if you need upload progress events; remove it to move to fetch. If you use server-side rendering, the update guide says XHR in @angular/platform-server is deprecated, intended for removal in Angular 23, and recommends fetch.
• The router's paramsInheritanceStrategy now defaults to always, so child routes inherit parent route parameters. No migration sets this for you: add withRouterConfig({ paramsInheritanceStrategy: 'emptyOnly' }) to provideRouter to keep the old behaviour, or test your nested routes.
• provideRoutes, ComponentFactoryResolver, ComponentFactory, createNgModuleRef and ChangeDetectorRef.checkNoChanges are removed.
• Hammer.js gesture integration is removed from platform-browser.
• Forms min and max validators no longer accept string values; bind numbers or null.

Tooling changes in the CLI

The Angular CLI 22.0.0 changelog drops Node 20 and removes the experimental Jest and Web Test Runner builders. ng serve now gives the PORT environment variable top priority over other port settings. The webpack-based builders are deprecated in favour of @angular/build.

If you use server-side rendering with @angular/ssr, the server no longer falls back to client-side rendering when a request fails host validation. Requests with an unrecognised Host header now get a 400 Bad Request, so list every valid host in the allowedHosts option before you deploy.

If you test with Karma and code coverage, note that istanbul-lib-instrument is now an optional peer dependency, a package you must install yourself. In our run the CLI migration added it to devDependencies automatically.

Four things surprised us, and each can cost a team an afternoon. All of them are from our own runs on 26 October 2026, so check them against your setup.

The install step can fail and leave a half-done upgrade

With npm 10.9.9, the npm that came with our Node 22.23.4, the first ng update to 21 rewrote package.json and cleaned node_modules. Then it printed "Installing packages [FAILED: Unable to install packages]". No migrations ran.

Running npm install by hand failed with "Cannot read properties of null (reading 'edgesOut')", even after deleting package-lock.json. The npm log pointed inside npm's own dependency resolver. With npm 11.6.2 on the PATH, the same package.json installed and the full update succeeded.

The lesson is general. If the install step fails, do not hand-fix package.json and move on, because the migrations never ran. Reset with git, fix the tooling, and run ng update again.

Each Angular package carries only its own major's migrations

The releases page gives the one-major rule but not a reason. The packages show one consequence. @angular/core 22.2.3 ships only migrations registered for 22.0.0, and @angular/core 21.2.25 ships only its 21.0.0 ones.

So a direct jump from 20 would skip the 21 code changes, such as moving the ApplicationConfig import. We checked these two packages only, not Angular Material or third-party libraries.

The ng update version list has a sorting quirk

Running ng update with no arguments on our Angular 20 app listed the target as 21.2.9, though 21.2.25 was the newest 21.x. The suggested command was still correct: ng update @angular/core@21.

The Angular CLI 20.3.41 source sorts version strings as text when it builds this list, so 21.2.9 sorts above 21.2.25. The real update installed 21.2.25. This is undocumented as of 26 October 2026; pin your version and trust the installed numbers, not the list.

There is no dry-run flag, so git is the safety net

ng update in CLI 20.3.41 and 22.2.4 has no --dry-run option; passing it gives "Unknown argument: dry-run". ng update refuses a dirty tree with "Repository is not clean" unless you pass --allow-dirty, and the --create-commits flag asks it to commit the updates and migrations for you.

Both hops began with "Installing a temporary Angular CLI versioned ...". The target version's own CLI runs the migrations, so you do not need to update the project's CLI by hand first.

Treat it as a risk and rollout question, not a framework trivia question. Interviewers listen for whether you tie the deadline to risk, keep each step reversible and know how to check the result.

1. 1

   State the risk and the date

   Angular 20 LTS ends 28 November 2026. After that, new security bugs in 20.x will not be fixed, so take the last 20.x patch and plan the move.

2. 2

   Name the constraint

   Angular updates go one major at a time, so 20 to 22 is two hops. Each hop has its own migrations and breaking changes.

3. 3

   Make each hop reversible

   One branch and one commit per hop, a build and test gate between them, and a deploy of 21 as a safe checkpoint.

4. 4

   Call out default changes

   Angular 22 makes OnPush and fetch the new defaults, and migrations pin the old behaviour for existing code. The router's parameter inheritance is the exception you set by hand.

5. 5

   Say how you verify

   Check ng version, a passing production build, the test suite and bundle size, then watch errors in production after a gradual rollout.