Keys to success in Angular migrations
Background and context
Enterprise Companies sometimes face similar challenges. Technology is continuous evolution: one day you’re on the edge of the trend and the next you have to deal with a really big problem about redefining your technology stack (and it gets worst when you have a deadline to become Cinderella).
This article focuses on the transition from AngularJS to other trending technologies like React or Vue, and some not that trending, like Angular.
Angular JS 1.0 was released back in 2010 and it has been maintained until 2018 when Google announced it was entering into long-term support (LTS) ending the maintenance by July 2021. Last year, and in response to COVID-19, the announcement was updated: the new deadline is by the end of this year (31st December 2021).
This context creates some trouble across enterprise companies that have adopted Angular JS as their main framework to build web applications. The decision is not simple and affects multiple areas, teams, infrastructure, and money, of course. In the last year, we have been helping several companies with these challenges and earned some experience transitioning from AngularJS to React and Angular. Here is a list with some tips to consider if you’re in this difficult position.
What are the real problems?
Migrating to new frameworks or libraries has some real and concrete challenges but also some problems that appear once you start making a decision.
This is the main trouble you face. AngularJS will be out of maintenance by the end of the year and you have several apps, dealing with sensitive data and exposed to the internet that will be at risk if you don’t start migrating. There are some options available.
Migrate to Angular: This option always appears as the most natural approach, but it has some side effects. You may think that moving from AngularJS to Angular could mean just an update, but the only thing these frameworks have in common is the name. They work very differently and they are based/built with another perspective. If you’re migrating to Angular, you need to re-write a lot of your code since Angular is based on Typescript and your codebase must be adapted to it, which is not a simple task on big applications.
Also, the way that Angular works with directives and controllers are different than what you’re used to, let’s put it simply, you need to start thinking in components. Even though AngularJS provides component directives, the migration is not straightforward. Angular has some restrictions on how these component directives should be used and existing tests must be migrated as well (same reason).
You can find more details about this migration here To be fair, Angular also provides some tools like ngUpgrade which is a helpful tool to start this step-by-step migration process.
Thinking in the long term, this a great opportunity to adopt a modern technology that will provide support for a long time. Based on the State of JS survey from 2020, in almost all the categories, Angular is decreasing traction and popularity year after year. This will have a concrete effect on the community and support. Since you need to make a radical decision, is a good exercise to see the full map and consider resetting from scratch and migrate to another technology.
Migrate to React: In this scenario, you consider rewriting apps from scratch, which also carries some other side effects (we’ll review them later). We have found that React provides a lot of flexibility to migrate from AngularJS which is something you will definitely need when working on these projects. The reason is that you’ll be facing challenges that will need custom solutions and having a strong and active community behind will provide you better tools to find those solutions.
Taking this path will require some decisions to be made:
- Full migration vs partial migration
- Current apps maintenance while you are developing the new ones
- Migration as it is or Redesign apps
- Integrate with a Design System
- Update your development stack
This is just a summary of the most important issues, but you’ll be facing more and that’s why flexibility is important. React community continues to grow, there are thousands of libraries and extensions available and it’s less restrictive in terms of how things should be done (big difference vs Angular, which is an opinionated framework).
Going to the details, the migration strategy is one of the most critical decisions. Our experience shows that partial migration is the best approach. The reasons are mainly risk reduction (you’re incrementally migrating apps and the learning curve gets dramatically reduced) and minimize duplicated maintenance: you don’t need to support the same feature twice.
When you’re in the incremental migration path, one of the first difficulties is having the current AngularJS application working together with React apps. The solution is based on micro frontends and connecting them with AngularJS Router.
There are some options to make it work, in our case, we have written directives and added routes to AngularJS to redirect traffic to the right app, that way the context is being managed by the parent app and it can be passed through the children app.
Routing is a big subject in these integrations, you may want to maintain the same routing structure and make sure that they are being handled by the right application.
Having several apps running isolated and using the AngularJS app as the glue across all of them allows you to maintain the current codebase while you are migrating modules/sections.
There’s an important consideration while working on these micro frontends and it’s about dependencies. A reasonable scenario is having the same dependency in different apps (AngularJS - React) causing trouble to define precedence and duplicated assets. Normally you see this issue on Styling differences, we tackle this issue using React Portals and/or iframes to separate responsibilities.
Thinking in the long term, a micro-frontends approach will bring flexibility when you have to migrate from React to the new-fancy-modern-js-library.
Talent and company stack
It’s impossible to leave this subject aside. Being at the front of these migrations has a direct impact on your team and your company stack. You’ll probably need to upgrade your team abilities in any direction you take. From Angular to React or any other new library, you need to consider the effort and costs needed to have your team acquiring the new skillset. And this is not only about the learning curve, but there are also others side effects that it’s worth considering since you’re at this inflection point.
Probably you’ll reconsider the company stack, your CI/CD pipelines to adapt them to the new technology, review your i18n strategy, modify your development stack (adding/changing linter rules for example), reviewing your git rules, and adding new webhooks, etc.
Here again, having a micro-frontends strategy and using monorepos to separate responsibilities and configurations will bring you enough flexibility not only for this technology transition but also for the next migration you’ll be fronting.
Partial and incremental migration looks like the best option, it will provide flexibility at this point and will give you better tools to make the next tech-transition decision. From our experience, React is our first choice in terms of support, flexibility, and extensibility.
We are totally aware of the type of challenge companies are facing. Losing the support of their current tech stack is a problem with a deadline and consequences. We have walked this path with our clients and helped them on finding custom solutions for these transitions which gave us enough knowledge and the full picture to consider all the alternatives and technologies.