A Short Journey Back to 2013
In my opinion, 2013 was one of the most important years in modern web development. It was a turning point that changed how we build applications and introduced new specializations and directions within the IT industry.
AngularJS had already existed before 2013, but around that period it started becoming widely popular and began gaining serious adoption across the industry. At roughly the same time, React was introduced and frontend development started moving into a completely new era.
Before that, most frontend development still relied heavily on plain JavaScript. Of course, different libraries and frameworks already existed, but in many real projects there was still not enough structure, not enough ready functionality, and not enough simplicity for building rich client-side applications.
A lot of behavior had to be implemented manually: hiding and showing elements, updating parts of the page, scrolling, validation, dynamic forms, tables and other interactions. Very often, applications also depended heavily on PHP or other server-side technologies to build pages and manage navigation.
The market clearly needed something more productive. Developers needed a framework that could reduce repetitive code and make it easier to build applications that behaved more like real software products rather than traditional websites.
The AngularJS Revolution
When AngularJS became popular, it felt like champagne. Suddenly, many things that previously required a lot of manual work became much easier.
Data binding, directives, routing, dependency injection and a more structured application model allowed teams to build Single Page Applications much faster. The page no longer needed to be fully reloaded for every interaction. Instead, only the necessary part of the interface could be updated.
This created not only the illusion of speed, but a real feeling that web applications were becoming faster, more interactive and more modern.
I still remember that period with enthusiasm. In many ways, it felt like a technical revolution.
But this revolution did not last very long.
Around 2014–2015, discussions about Angular 2 became louder and more common. The problem was that Angular 2 was not simply the next version of AngularJS. It was essentially a new framework with a different architecture and different concepts.
This created a strange situation. Many companies were still building new AngularJS applications, while the direction of the framework had already started moving somewhere else.
Why Migrate from AngularJS?
Today AngularJS is legacy technology. This does not mean that every AngularJS application will immediately stop working, but it does mean that every company using it carries long-term technical and business risks.
Security and Long-Term Risk
Unsupported technology is always a risk. Browsers continue to change, security expectations continue to grow, and new types of attacks appear over time. AngularJS does not evolve in the same way as modern frameworks, so responsibility for keeping the application safe and maintainable moves more and more to the product owner.
Technical Audits and Investor Concerns
In some cases, technical audits performed before investments, acquisitions or IPO preparations may identify unsupported frameworks as a risk factor.
I have seen real situations where AngularJS migration was started because a company wanted to remove such risk from audit reports and technical due diligence documentation.
Access to Modern Capabilities
Modern Angular provides better tooling, better build processes, better performance opportunities and a much healthier hiring market.
Staying on AngularJS means staying aside from many improvements that have appeared in frontend development during the last years.
Migration Challenges
The biggest problem with AngularJS migration is that it is usually not a simple upgrade. In many cases, it is closer to a rewrite.
Companies invested large amounts of money into AngularJS applications, and then discovered that moving to modern Angular could require serious reinvestment.
The challenge is not only technical. It is also organizational. Product development usually cannot stop for a year while engineers rewrite everything. New features still need to be delivered, bugs still need to be fixed, and customers still expect progress.
That is why choosing the right migration strategy is so important.
Migration Strategies
Strategy 1: Complete Rewrite from Scratch
The most obvious approach is to create a completely new Angular application and rewrite the old application piece by piece.
This approach is clean and understandable. You start with a new architecture, new project structure, modern tooling and no direct legacy constraints.
The downside is cost and time. If the old application is still actively used, the team may need to maintain two systems at the same time. If a new feature is added to the old application, it may need to be repeated in the new one.
In my opinion, this approach works best when the team can migrate by pages or business areas and release those parts quickly. If one migrated area takes six months before users can see it, the risk becomes too high.
Strategy 2: Fast Jump Migration
One special variation of the from-scratch approach is what I call Fast Jump Migration.
I used this approach while leading the migration of a large CRM application for a well-known company. The project had a strict deadline of six months. The application was quite difficult: around ten large pages, many forms, editable tables, modals, nested forms and complex business logic.
At the beginning, we tried to rewrite the application in a clean way. But after the first month, I analyzed the velocity and realized that if we continued with the classic “rewrite and refactor” mindset, we would probably need at least one year.
So I changed the strategy.
Instead of trying to redesign everything immediately, I decided to focus on fast code conversion. AngularJS and Angular are different, but they still have some conceptual similarities in component structure, templates and services.
I created several simple internal scripts that helped convert old
AngularJS syntax into Angular syntax. For example, they converted
template expressions, replaced old directives such as
ng-if with Angular equivalents such as
*ngIf, and transformed controllers into class-like
structures.
Of course, those scripts did not produce perfect ready-to-use code. But they gave us a very strong starting point. In many cases, a developer only needed to review the generated component, fix several places manually and continue.
Some components could be moved to Angular in 10–15 minutes. Even controllers with 2,000–3,000 lines of code could sometimes be migrated almost one-to-one and made working in a very short time.
From an architecture point of view, this was not perfect. We intentionally kept many old structures. But the goal of that phase was not refactoring. The goal was migration.
The mindset was simple:
First migrate. Then improve.
In some situations, this approach can be more realistic than trying to refactor everything during migration. Once the application is already running on modern Angular, refactoring can continue step by step without the pressure of the old unsupported framework.
This approach can also reduce the need for a long business feature freeze, because the migration window becomes much shorter.
Strategy 3: Using ngUpgrade
Google introduced ngUpgrade as a bridge between AngularJS and Angular. It allows both frameworks to coexist inside one application.
On paper, this is a very powerful and flexible tool. You can migrate gradually, component by component, while keeping the application alive.
However, I personally do not like this approach for large migrations.
In my experience, such bridges can bring confusion. Developers need to think about two frameworks at the same time, two lifecycles, two ways of structuring logic and two ways of connecting dependencies.
Even though recent versions of ngUpgrade support AOT compilation, I still personally would not use it as my preferred strategy. Maybe something has changed in newer versions, but in my practical experience this kind of bridge can still make the project harder to reason about.
I prefer to separate old and new applications from the beginning. Different repositories, clear folder structures, clear services, clear responsibility boundaries. In my opinion, it is better to develop the new project as a real project, not as a partial tweak of the existing legacy logic.
ngUpgrade can work, and it is powerful. But for me, the cost of complexity is too high.
Strategy 4: Migration Through Web Components
The approach I recommend most often is migration through Web Components.
Web Components are natively supported by JavaScript and modern
browsers. You can create a custom element, register it with
customElements.define(), load the required scripts and
use it inside another application almost like a normal HTML tag.
This gives a very clear boundary between the old AngularJS application and the new Angular functionality.
For example, if you need to create a new form, dashboard, widget or section, you can build it in modern Angular, package it as a Web Component and insert it into the old AngularJS application.
Communication can happen through a simple API: attributes, properties and events. The old application does not need to know how the new component is implemented internally.
This is the main advantage. You do not mix frameworks deeply. You integrate them through a clear interface.
Over time, more and more parts of the old application can be replaced with new components. Eventually, whole pages or business areas can be moved to modern Angular.
In my experience, this is the cleanest practical approach for large projects where a full rewrite is too risky and ngUpgrade creates too much confusion.
Strategy 5: Strangler Pattern
Another approach worth mentioning is the Strangler Pattern.
The idea is to gradually replace old routes, pages or business domains with new implementation until the legacy application disappears.
Conceptually, this is close to Web Component based migration, although the implementation details may be different.
This approach is useful when the application can be naturally split into independent areas and migrated step by step.
Final Recommendation
There is no single migration strategy that fits every company and every product.
If you have enough time, money and team capacity, a complete rewrite can be the cleanest solution.
If the deadline is aggressive and the main business goal is simply to move away from AngularJS quickly, Fast Jump Migration can be a very practical option.
If the application is large and still actively developed, I personally recommend Web Components as the most practical and controlled migration path.
I do not usually recommend ngUpgrade for large long-term migrations, even though it is powerful. In my experience, clear separation between old and new systems is easier to manage than a hybrid application where two frameworks live deeply inside one project.
AngularJS played an important role in frontend history. It helped many teams build modern web applications and accelerated the adoption of Single Page Applications.
But every technology eventually reaches the end of its lifecycle. The real question is not whether migration should happen, but how to do it in a way that protects the business, reduces risk and gives the engineering team a better foundation for the future.