AngularJS extended support: a bridge and its limits

Paid support for AngularJS can close the security gap while you migrate. It does not modernize anything. Here is what you get, what you do not get and when it is worth paying for.

What extended support is

After the official end of life, several commercial vendors started maintaining their own continuation of AngularJS 1.x. You pay a subscription and receive patched builds of the framework. When a new vulnerability is reported, the vendor fixes it in its version and ships an update. In most cases you swap the package source and your application code stays the same.

It is the same model companies use for old operating systems and old runtime versions: someone other than the original author keeps the software safe for a fee.

What it usually covers

Offers differ between vendors, so treat this as a checklist to verify:

• Security patches for the framework core and the official angular-* modules such as routing, sanitization and animation.
• Fixes for breakage caused by new browser versions.
• A drop-in package that replaces the official one without code changes.
• Documentation for audits. A support agreement, patch notes and a statement you can hand to an auditor or a customer.
• A response commitment for new vulnerabilities, written in the contract.

Some vendors also cover selected third-party libraries from the AngularJS ecosystem. Ask for the exact list.

What it does not cover

• Your own code. Bugs and weaknesses in your controllers, templates and services stay yours.
• Libraries outside the vendor's catalog. Old jQuery plugins, grids, editors and UI kits that nobody maintains remain unpatched.
• The build chain. Old Node versions, task runners and bundlers are outside the scope.
• Hiring. Supported AngularJS is still AngularJS. Candidates react to it the same way.
• Delivery speed. The codebase is as hard to change as it was before.
• New capabilities. You get fixes. You do not get features, performance work or a path to modern tooling.

When it makes sense

• A migration is planned and will take several quarters. Support covers the gap until the last AngularJS screen is gone.
• An audit or a customer contract requires supported software now. A subscription can be in place far sooner than a migration can finish.
• The app has a retirement date. Paying for support until that date can cost less than migrating something you will switch off.
• The app is stable and rarely changes. If nobody needs new features, the delivery argument for migrating is weak, and patched builds may be enough for a long time.

When it does not

• The main pain is slow delivery or hiring. Support fixes neither.
• Most scanner findings come from other libraries. Check where your findings actually are before buying.
• It becomes the reason to postpone the migration again. A bridge with no far side is a recurring cost with no end.

Questions to ask a vendor

1. Which packages and versions are covered, exactly?
2. How fast do you commit to patch a newly published vulnerability, and where is that written?
3. Do you fix issues you discover yourselves, or only public ones?
4. How are patches delivered: private registry, tarball, CDN?
5. Will our dependency scanner recognize the patched version, or will it still flag the package? How do other customers handle that with auditors?
6. What happens to our access to past patches if we cancel?
7. Is pricing per application, per developer or per organization?
8. Can you provide a document for our auditor that describes the coverage?

Question 5 matters more than it seems. If your scanner keeps raising the same findings, someone on your team has to document each exception.

How to compare the cost

Ask at least two vendors for a quote based on your real number of applications. Then compare the yearly fee with the first phases of a migration, using the method in the migration cost guide. Two patterns are worth checking for. For a small app, the fees over the planned term can come close to the cost of migrating it, and then migrating wins. For a large app with a long migration ahead, support during the migration is a reasonable line in the budget.

Use it as a bridge with an end date

1. Sign for the shortest term that covers your migration plan.
2. Put the end of the subscription in the migration roadmap as a milestone.
3. Tell your auditor both things together: patched builds now, removal by a stated date. The security and compliance guide explains how to present it.
4. Review progress before each renewal. If the migration has not moved, the renewal conversation is the moment to ask why.

Extended support is one of several paths. The full comparison is in AngularJS end of life: your options.

More in this section

• How to build the business case for frontend modernization
• A phased roadmap for frontend modernization
• How to choose a frontend migration partner
• Frontend migration risks and how to reduce them