Angular's update tooling is built and tested for moving up one major version at a time, so each step applies the code changes for that release. If you are several majors behind, update through each version in turn, running tests between steps, and use the official update guide for the checklist.
What the documentation says
The Angular releases page states the criteria for ng update to any version. The version you want to reach must be supported, and the version you are leaving must be within one major version of it. Its example: from 11 to 12 is fine if 12 is still supported. To go from 10 to 12, you update from 10 to 11, then from 11 to 12.
The page also says ng update provides code transformations, which the team says they test ahead of time over a very large number of projects at Google, and points to an interactive Update Guide for step by step instructions between majors.
Why small steps work better
Each major release removes APIs that were deprecated earlier. Angular's deprecation policy says a deprecated API stays available for a minimum of one major version, roughly a year, and that deprecations are announced in the change log with a recommended update path. Each step's migrations are written against the previous release's code. Skipping versions asks the tooling to work from a starting point nobody wrote it for.
Small steps also make failures easy to place. If tests break after moving from 15 to 16, you know the cause is in that change set.
The support calendar shapes your plan
The releases page describes an active phase of 12 months and a long-term phase of 12 months where only critical fixes and security patches ship, and says a major release arrives about every 12 months. It also warns that dates are general guidance and may change. Check the live table before you commit to a plan.
| Phase | Length | What ships |
|---|---|---|
| Active | 12 months | Regular updates and patches |
| Long-term | 12 months | Critical fixes and security patches only |
Working backward: if you are on a version that has entered its long-term phase, you have about a year before security patches stop. Each major you are behind adds a step, and each step needs a test cycle. Starting early is cheaper than starting when the window closes.
A practical sequence
- Record the version you run and the table of supported versions.
- Update third party libraries that block the next step first, such as UI kits and state libraries.
- Run the update guide for your from and to versions and choose the complexity that matches your app.
- Run ng update for the framework packages, commit the generated changes on their own, then fix the leftovers by hand.
- Run the full tests and a production build.
- Merge, then repeat for the next major.
Keep each major as its own pull request. If a step goes wrong, you can revert a single release instead of a quarter of work.
Quick check
Can I run the update from two majors back in one command?
The documentation says to update across multiple majors one at a time.
Does a code transformation replace testing?
No. The transformations handle known patterns. Your own code and libraries still need tests.
Safeguard inventories your dependencies, including front end packages, and shows which have known vulnerabilities and which are reachable. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
