Support status · AngularJS
Is AngularJS still supported?
AngularJS has been unsupported since 31 December 2021.
The Angular team ended long-term support on that date, after a final release of 1.8.3 in April 2022. Nothing has been patched since, and nothing will be. Vulnerabilities disclosed in AngularJS after that date stay open permanently. The fix does not exist and is not coming. Commercial vendors sell extended support, which is a real option and worth knowing about, but it buys time rather than a way out.
- Support ended
- 31 December 2021
- Final release
- 1.8.3, April 2022
- Patches since
- None, and none planned
- Community upgrade path
- None that is mechanical
Source: endoflife.date: AngularJS. Check it. We would rather you did.
- Dates from the project itself, linked
- No email needed to read them
- Deferring is sometimes right
What that actually means
The position most estates are in
Your build has been telling you since 2021
Every dependency scan flags it, every penetration test writes it up, and every security questionnaire has a question it fails. None of that stops a release, so it accumulates as a known finding that is quietly carried forward each quarter instead of being fixed.
"Just upgrade to Angular" is why the last attempt failed
There is no mechanical path from $scope, string-annotated dependency injection and two-way binding to any modern framework. The estimate that assumes there is comes back much larger halfway through, when the money is already spent.
The people who could read it have moved on
A framework nobody has written new code in since 2016 is not on anyone's development plan. Hiring for it means paying a premium for someone willing to take a step backwards, and the people who built yours have long since left.
Exposure
What breaks, how likely, what it costs
Stated generically here because it is generic until someone looks at your estate. These are the scenarios that actually land, in the columns your risk register already has.
| Scenario | Likelihood | Impact |
|---|---|---|
| A new CVE is disclosed against AngularJS 1.x | Has happened repeatedly since EOL | No patch will ever exist. The finding is permanent until the framework is gone |
| A customer security review asks about end-of-life components | Routine in enterprise procurement | An honest answer names an unsupported framework in the browser-facing tier |
| A dependency you do need to update refuses to work with it | Increasing every year | The upgrade you wanted is blocked by the framework you were not upgrading |
| The one person who understands the directive layer leaves | Eventually certain | Change velocity on that application drops to near zero |
What we do about it
The work itself
What the application does, recovered from the code
Controllers, services, directives and the templates they drive, read at volume and written down as behaviour. Most AngularJS estates have business rules that exist in exactly one place: a watcher nobody remembers adding.
The real boundary between app and framework
Which code is genuinely your domain logic and which is framework ceremony that should not be ported at all. In a $scope-era codebase this line is not where anyone expects, and finding it is most of the saving.
Behaviour pinned before anything moves
Characterisation tests driven through the browser against the running application, because the existing unit tests, if there are any, test the framework wiring rather than the behaviour anyone cares about.
Replaced route by route, both versions live
The old application keeps serving the routes that have not moved. Each route ships independently and reverts independently. No branch that lives for nine months and no weekend when everything changes.
What decides the cost
The three things worth knowing before anyone quotes
- Component API
- Code already using .component() with one-way bindings ports at a fraction of the cost of $scope-era controllers. The ratio between them is the estimate.
- State location
- Whether state lives in services or is scattered across scopes and $rootScope decides whether routes can move independently at all.
- Custom directives
- Directives with their own compile or link functions are the slowest thing to move and the easiest to miscount at the quoting stage.
The engagement
How the work runs
You tell us what you have
Roughly how many screens, whether there is a build step, and which screen the business would notice first.
We read the code
Module structure, how much uses the 1.5+ component API, where the state actually lives, and how much of it is dead.
One route goes first
A real screen, in production, in TypeScript, served alongside the AngularJS app. That is where the estimate stops being a guess.
The rest follows in that order
Measured against the first route, sequenced so the highest-traffic screens leave the unpatched framework earliest.
Questions
Frequently asked
Is AngularJS still supported?
No. Long-term support ended on 31 December 2021 and the final release, 1.8.3, came out in April 2022. There have been no patches since and there will be none. This is one of the clearest end-of-life positions in front-end development: the project is closed, not slowing down.
Can we buy extended support instead?
Yes, and it is a legitimate move in some situations. Commercial vendors sell never-ending support for AngularJS with backported security fixes. If you have a hard compliance deadline and no capacity this year, buying a supported answer to the questionnaire is rational. Be clear-eyed about what it is: it removes the audit finding, it does not reduce the size of the eventual rewrite, and it adds a recurring cost to an application you have already decided has no future.
Should we move to Angular, React, Vue, or something else?
Angular is the smallest conceptual jump and the largest amount of work: the name is shared but the framework is not, so it is a rewrite either way. Given it is a rewrite either way, the destination should be chosen on what your team will still be able to hire for and maintain, not on which one sounds like the thing you already have. We build in TypeScript and would usually argue for React, and we will tell you when your team's existing skills point somewhere else.
Is ngUpgrade or a hybrid app worth doing?
Sometimes, and it is worth taking seriously rather than dismissing. Running AngularJS and Angular side by side lets you move incrementally without a big-bang release, which is genuinely valuable. The cost is that you maintain two frameworks and their bridge for the duration, and estates that pick this route without a hard deadline for finishing tend to still be hybrid three years later. We would rather run the increments behind a route boundary than inside a hybrid bootstrap, for exactly that reason.
The application works perfectly. Is this actually urgent?
It is not urgent in the sense that something breaks on a date, because nothing will. It is urgent in the sense that the cost of moving rises every year while the benefit of having moved stays the same, and that the decision is usually taken out of your hands eventually by a customer questionnaire, an auditor, or a dependency you cannot upgrade. If it is internal-only, low-change and nobody is asking, deferring can be the right answer, and we will say so.
Can this be done without a feature freeze?
That is the main thing we design for. Moving route by route with both versions served means the AngularJS app keeps taking changes while the replacement proceeds. A rewrite that requires the business to stop asking for things is a rewrite that gets cancelled in month five, which is the usual reason these projects fail.
Have you migrated AngularJS specifically?
Our deepest delivery experience is ColdFusion, and this is the technology on this site closest to what we do every day, because the destination is TypeScript, which is the language we build in. What we would not claim is a portfolio of finished AngularJS migrations. The method transfers because it is about reading code you did not write and pinning behaviour before changing it, not about the framework.
Talk to someone who would read the code
A name, an email, and three optional questions. What comes back is a reply from the engineer who would read the code, and it is either a conversation about replacing it or an honest reason why we are not the right people.
Other platforms