How to upgrade badly outdated angular project?

Question

We are upgrading large scale angular app from 6 to 17. Like everybody else I have also been following Angular Upgrade Guide: but that always talks about upgrading one version at a time.

Our app has nearly 50 third party libraries. So upgrading libraries is the major work compared to upgrading the angular version itself.

As an architect I do not see any point in travelling from v6 to v17, step by step.

In 2023 why any one would write the code of intermediate versions (of angular and used 3rd party libraries) just to discard them?

IMHO there has to be a better guidance on how to upgrade badly outdated Angular projects, but cound't find authoritative answer on the topic.

Is there any logic on why one should not move to V17 directly? Why it is officially recommended to go step by step?

Any guidance is greatly appreciated, thank you.

Teamwork

It can be a challenge, and when you cross thresholds where third-party libs stop working, you can't cleanly test each step in the upgrade journey. How I have handled that myself is to just walk the angular updates forward. When you reach a point where third-party libs are blocking, just comment them out of the package.json and keep going. You can't validate each step, just keep updating. When you arrive at 14 or so, pause. Fix things up, do the research on the packages, get your app building and running again. Then execute the last couple of updates one at a time, fixing each step. – Felicitation

You definitely want to walk each angular version so you can get as many automated update code fixes as possible. Angular tries to help you with many of the breaking changes. – Felicitation

Answer 1

If the angular app is badly outdated, then it is very difficult to upgrade it.

This is not a problem with Angular. 'Inability to upgrade easily' is a wellknown problem with almost all of the opensource software utilities. Opensource never comes with the guarantee of extremely long term backward compatibility or upgrading by skipping major versions.

---

Angular 6 was released in 2018.

Many things have changed since then. Many projects on NPM have got closed down. New projects sprang up. Typescript language had changed considerably in the past 5 years. Nodejs platform went through major updates.

Angular 17 is released in Novemebr 2023.

Jumping from 6 to 17 is a very long jump. Doing it successfully requires the understanding of changes that have happended in the past 5 years not only to Angular, but also to its ecosystem (Typescript, Nodejs, RXJS, Webpack, NPM packages).

If some of the dependencies have become deprecated, then the effort of finding and testing the replacements for the dependencies will also be required.

---

These are my findings based on my experience of upgrading several Angular projects in the past 8 years:

1. Upgrade from Angular 12 to 17 is easy.

Typescript language, Nodejs and the general NPM dependencies for Angular did not have many breaking updates since late 2021. Angular evolved from version 12 to 17 during this period. Upgrade from Angular 12 to 17 is fairly easy, as the ecosystem had been generally stable in this period. Most of the Angular 12 projects can be directly upgraded to 17 without code changes.

2. Upgrade from Angular 2 to 11 is difficult

Between 2016 and 2021, there was a tremendous change in the ecosystem. COVID19 pandemic also caused problems to many opensource projects. Angular evolved from version 2 to 11 during this period. Upgrading Angular from version 2 to any other version till 11 was very difficult due to the nature of changes in the ecosystem at that time.

3. Very difficult to upgrade from before 12 to 13 or above

Nodejs and Typescript have had numerous updates coinciding with the timeframe of Angular changing from 11 to 12. Upgrading Angular from any version below 12 to a version above 12 is very difficult due to this.

---

Recommended upgrade approach for Angular 6 to 17 Though the best practice is to do a step-by-step upgrade, one major version at a time, it can be safely avoided in many cases.

Based on my experience and consideration of the timelines of breaking changes, this 4 stage upgrade will be the easiest:

• Stage 1: Upgrade from Angular version 6 to 9
• Stage 2: Upgrade from Angular 9 to 11
• Stage 3: Upgrade from Angular 11 to 12 or 13
• Stage 4: Upgrade from Angular 12/13 to 17

Cally

Answer 2

This is a cost function, and you are probably making the correct guess in jumping to the new version.

• Cost of trying to upgrade version by version has very high costs. There are many versions, which would having you solve transient problems such as upgrading a library for an intermediate version, only to find that the library is completely replaced by your target version.
• Cost of trying to do a jump upgrade is also high. Odds are that many libraries have changed, some paradigm changes require redesign of code. My years of experience still says do the jump.

That said, you now have a stack of "legacy code". You should follow the usual steps:

• Make sure to maintain a machine running a working copy of the legacy code at all times. This allows you to add new formal or informal tests when trying to get your current version to run. This does not need to be a version that is using "live" data.
• Depending on your exact application, you may be able to run a hybrid system. For example, you have a router that runs the old system for generating patient bill PDFs and doing some obscure calculations. You route to the new system for the appointment scheduler. Over time, you route to the new system for everything. This works for some applications and not for others.
• Really avoid letting every possible new feature people of dreamed about for the last few years be part of the success criteria of your project. Argue that it will be easy to add features once you are stable.
• Automated formal tests are great, if you have them. Even manual semi-formal tests are great. That is, "I add an appointment, mark it as missed, and see that the patient is billed for a no show. Works in the old and new system.
• Your PID, or design for the non-project oriented people, should look at the list of libraries linked and which have been abandoned.

You have a project, not an afternoon's effort.

Commutation

Answer 3

IMO, the Angular Upgrade Guide is suitable for cases where you are a few versions behind the latest. So, It's not a good way for your case.

Unfortunately, there are a lot of (breaking) changes in the codebase and the project structure that you need to apply one by one. The migration process is not simple, and I think that's why the Angular development team couldn't deliver a reliable and straightforward solution to make all the required changes at once.

I suggest the best way which is creating a new project from scratch using the latest Angular version and making the changes one by one. Otherwise, you'll get strange errors, and it will take you so much time to resolve even the simple issues. Here you can prioritize all the steps to speed up the process. You also need to make sure the latest or specific versions of the 3rd party libraries are compatible with the new Angular project and its dependencies (one by one).

Squishy

Answer 4

I understand your concern and the biggest hurdle you'll face when you upgrade angular version one by one is for every versions you have to work and fix the third party library versions.

I would suggest you two approach. I would prefer 1st one though.

1. Good Approach with more time cost

• Upgrade angular to new version and then check each library and also update them to the latest version compatible to your current angular version.
• Run the code and keep updating your code and fix all the errors and the changes occurred due to library changes.
• Some libraries would also have major changes and you have to do many changes as well.
• So start with library having minor changes and then go with libraries having major changes (it would be generally ui component library like material or primeNg)
• There will be lot of work but at the end of the day you'll have you angular and all the libraries updates as well.

2. Moderate approach with less time cost

• Upgrade the angular version to latest version and then run the code. Now fix all the errors and libraries version conflict.
• You'll have to work less in this approach but at the end of the day you'll still have some libraries with older version.
• I suggest if you are spending time in upgrading your project you should update all the libraries as well.

Scuff

Answer 5

I find that most of the time if it is difficult to update a library or framework then it is a question of decoupling. Properly decoupled libraries, modules, components or whatever you prefer to call them should be relatively easy to update.

Exhale

Answer 6

Hope this answer isn't coming late though, I recently upgraded our angular v9 app to v17 and below are the steps I took.

1- so I followed the angular guide for upgrading from one version to another sequentially. Everytime the upgrade fail due to a third party library,I comment it out in the package.json until the upgrade is successful. I kept repeating this until I got to version 14. 2- Then I uncomment the third party libraries , delete the node-modules and perform re-installation, if it works, you're good but if it doesn't, then I run the npm command to update that third party library to the latest version then I try again until everything works fine.

note that you may need to make some changes to your code base as some apis for some third party libraries may have change. Thats not a problem though.

3- upgrading to angular 17 came with one minor but major issue. The fact that the compiler has been changed made some popular angular libraries non-functional and their author has not publish a new update. so what should be done? You'll need to either look for the updated version of that library on npm repo probably published by someone else or you have to do the update to the library yourself and push it to npm so you can use it. Upgrading it is not difficult though, there are articles and youtube videos on how to do that.

In the end, what I learnt was that we should not be too third party dependent and many times, we can code some things ourselves that bloat the app with too many libraries many of which will stop being maintained by their author

Pavlish