An AngularJS to Angular Migration Case Study

Agile • UPDATED ON June 8, 2020

John Adam

Author

With AngularJS Support Officially Discontinued From Summer 2021 Many Still Relevant Legacy Apps Need To Be Migrated To The Angular Framework

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.

If an app has a long-term future, the decision will ultimately have to be migration to a new open source JavaScript framework that will continue to be maintained for the foreseeable future. The choices here are the AngularJS heir apparent, the most recent version of Angular 2+, which is currently Angular 9, whose stable release was launched in April 2020. Or an alternative JS framework such as React or Vue.js.

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.

Angular Migration Case Study: Our Experience – Your Takeaway

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.

Why Is It Necessary To Prioritise The Migration Of Apps Built On AngularJS?

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.

Technologies more generally, and software development frameworks specifically, have a life cycle. At some point that circle of life leads to either evolution or extinction. In the case of AngularJS, the framework’s path has been one of evolution into the more complete and flexible Angular 2+ series that has, at the time of writing, reached the Angular 9 iteration. The original AngularJS framework contributed a lot of value to the evolution of JavaScript development and leaves a rich legacy. At the heart of that legacy is the contemporary Angular framework iterations.

But the official end of AngularJS maintenance does have consequences for organisations which have active apps built on the framework. It means:

1. The framework itself, it’s related components and infrastructure will lose their official support. The practical consequences of that will be freezing of functionality, no more bug fixes or security patches;
2. Third-party libraries will lose the support of maintainers and contributors, who will, if they haven’t already, themselves migrate to the active Angular 2+ frameworks;
3. The activity of the global community around AngularJS will drop off as many of those developers who had been using it opt for newer, improved technologies. This will include activity on important public resources such as StackOverflow;
4. No, or very few, new blog posts / white papers / tutorials will be written on AngularJS, which probably means no new discoveries or best practices;
5. It will be harder to find experienced and motivated developers to maintain AngularJS products over time because most will be interested in working on the contemporary Angular framework.

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.

AngularJS vs. Angular 9+: Better Algos, Better Architecture And Up To 5x Faster!

 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:

• Angular is up to 5x faster than AngularJS thank to its improved algorithms and architecture.
• This means apps built in Angular are faster and more responsive.
• Load times depend most on app optimisation (code splitting, minification, compression etc) rather than the framework itself. But Angular offers serious optimisations for production build which reduce the bundle size significantly.

Ivy Bundle Size Improvements – Version 9 Ivy vs. Version 8

Source: Version 9 of Angular Now Available — Project Ivy has arrived!

Migrating A Large App From AngularJS to Angular 9: A Step-by-Step

 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.

The Step-by-Step Migration Process

1. Best practise when embarking upon any migration of a large app is to split the system into separate smaller chunks in order to migrate them one-by-one or in parallel; in our case we split the system into widgets (smaller apps) and related modules such as shared components, themes and infrastructure.
2. We then estimated the complexity of each chunk, taking into considering factors including code/logic complexity, amount of code and its structure; this informs us if every feature can be smoothly migrated or where we might encounter complexities in the migration.
3. If the feature is complex and can’t be easily migrated as a part of the chunk, we eject it and estimate it separately (considering time for additional research if needed)
4. After a granular estimation has been made we present it to and reach agreement with the customer (this allows the customer the option to take something out of the scope as low priority). We then start to code
5. The migration itself involved rewriting the app in the new Angular 9 framework, using the original AngularJS app as the model. The goal is to migrate all of the original features.
6. In addition to the migration, our developers also require a test/demo environment to make tests and present the progress and additional CI/CD setup which takes into account new build process (we had a DevOps expert onboard who managed this).
7. Functioning chunks of the app may be made available to the customers as soon as they have been migrated.
8. It is good practice is to start the migration with a less critical chunk to see how it goes in practise and, if necessary, adjust initial estimates to a new benchmark.

 Challenges Encountered And Solutions Arrived At Throughout The Angular Migration Process

 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:

1. We initially researched the options around automating elements of the migration but the complexity of the app in question meant we hit a dead end in that regard;
2. Our initial estimates were slightly optimistic, which we quickly realised. This was a perfect example of why a strong migration methodology should always involve starting with a small, less critical chunk of the overall app to get a realistic benchmark for migration velocity. That’s what we did and subsequently re-set our initial estimation to the new benchmark.
3. TypeScript is a great alternative to raw JavaScript that comes with significant advantages. But writing types for legacy code is challenging. We were fortunate to have all the necessary documentation including Swagger REST API docs.
4. Work with styles is different in Angular 2+ compared to AngularJS because it isolates styles, which AngularJS doesn’t. This is not a major issue but does add complexity to styles migration and requires their additional refactoring.
5. We found we needed to replace some complex third-party solutions, like rich editor or charts. These elements of a system require additional attention from the very beginning, especially if critical features are based on third-party solutions which may not play well with Angular. In reality, the most popular solutions have official “bindings” for Angular, so integration is smooth. But it is important to understand what the situation is before starting the migration process.

Our Learning Takeaway

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.

Migration Flow

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.

Time & Budget Estimation

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.

Migration Coding

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.