Why migrate apps built on the AngularJS framework? From its initial release in October 2010, AngularJS has had a good run. But the framework is now outdated and with official support for the AngularJS framework ending in the summer of 2021, companies with legacy apps built on the original angular face a decision. Attempt to continue to maintain their AngularJS app(s) indefinitely, despite the difficulties doing so is likely to involve going forward. Or opt to migrate legacy AngularJS apps.
A majority of times, an AngularJS migration will be to the latest version of Angular. That was the case for the app whose migration this case study will detail. We’ll detail how we approached the migration of a an especially large app and challenges encountered from both a technical and business point of view.
If your organisation has products built on the now outdated AngularJS framework, you may well be planning to migrate them to the latest version of Angular.
This case study will not only give you a clear idea of the technical approach that may be appropriate but what you should be aware of and take into consideration when estimating the resources that will need to be allocated. Either in the context of an inhouse agile development team or if working with an outsourced provider.
As mentioned, Google has officially announced the discontinuation of AngularJS development and support from summer 2021. In reality, Long Term Support (LTS) of stable AngularJS has been winding down since the last version, AngularJS 1.7, was released on July 1 2018. And the writing was on the wall a year or so earlier after the late 2016 release of next generation Angular 2+.
While Google was behind AngularJS and resourced its maintenance and support community, the framework is of course open source. That means an actively engaged dev community could theoretically continue to support the framework even without Google’s backing. But the practicality is that AngularJS, even the most recent version, is now outdated, Angular is fairly universally accepted as far superior, and there is little appetite to do so.
But the official end of AngularJS maintenance does have consequences for organisations which have active apps built on the framework. It means:
The Angular 2+ framework is, by contrast, in active development as well as offering awesome new features and efficiencies, with the promise of many more to be added in the future. Angular 2+ also has a very active community that is constantly producing new articles and tutorials and discussing issues and ideas on StackOverflow and similar resources.
Angular is a fantastic framework, which makes it the natural choice when migrating legacy apps originally built on AngularJS. And while the former evolved from the latter, at this point it represents a significant step up in quality and capabilities.
TechAhead’s blog Angular vs AngularJS – A Complete Comparison Guide 2019), goes into further details for anyone interested in reading up on how the two compare to each other but for me the key improvements are:
Ivy Bundle Size Improvements – Version 9 Ivy vs. Version 8
Having worked with the same client on other projects in the past, we had a strong starting point of mutual trust and understanding. Crucially, we’d also carried out some smaller Angular migration projects already, including one for a key UI kit. However, this app’s migration was a much larger and more complex job.
The iterative releases of Angular 2+ are very retrospectively compatible, which is one of the contemporary framework’s strengths. But unfortunately, the AngularJS and Angular frameworks are not especially compatible with each other. This meant that the migration involved rewriting a majority of the code from scratch in Angular 9.
Any development project of any level or scale and complexity will inevitably throw up challenges and unanticipated problems. Of course, strong planning minimises deviations from the expected but it is unrealistic to expect a complete absence of in-project problem solving.
In the case of this migration, we had to manage the following challenges:
At the conclusion of every project K&C is involved in we document our learning takeaway. So what did we learn from this major AngularJS to Angular 9 app migration?
When we started migration, we already knew Angular 9 was the choice of what the original AngularJS framework would be migrated to. The ‘unknowns’ were exactly how much work would be involved, its complexity and an accurate estimate of the time needed to deliver the completed project.
This case study once again highlighted the importance of breaking a large system down into bite-sized chunks and making the final estimation after first completing a smaller, less critical chunk.
We learnt that our original estimate was too optimistic and we added about 50-60% of time to the total estimate on the first cycle of development. The next estimates were much more accurate.
Initially, we made the wise decision to not estimate the full migration on the basis that it was always likely to prove inaccurate or would have to incorporate a significant buffer to absorb all the unknows.
In this case migration involved the creation of apps from scratch on top of the new Angular framework, using the legacy version as the blueprint. While the initial plan was to create an exact copy of the legacy app’s functionality, there were eventually some changes (improvements) dictated by business considerations.