
Migrating Angular: From v16 to v17
Written by: Randy MS
Date: 4/3/2025
đ¸ Image: Credits and thanks to Ravi for the image above! Taken from Unsplash.com.
â ď¸ Important Disclaimers
âď¸ For security reasons, some details have been intentionally left out.
âď¸ This is not a step-by-step guide or a document to follow for updating an Angular app.
âď¸ This article provides a general overview, reflections, and storytelling on how the upgrade was achieved within the given context.
Intro
It's no secret that YouTube, Udemy, and Coursera tutorials are light-years away from real-world corporate projects. You might learn the basicsâReact Hooks, Angular bindings, or SCSS nested classes with their quirksâbut when it comes to actual production code, things can get pretty intimidating.
Now, add the challenge of working with legacy code, written by developers who left the project long ago. And letâs not even mention the missing documentation or the total lack of guides that could give you a clue about what a mysterious block of code actually does or where key resources are buried.
And if thatâs not enough, imagine being tasked with upgrading the entire front-end engine to a newer versionâit's like going to war in the dark.
Well, I found myself in exactly that situationâand somehow, I made it through!
Of course, I didnât do it alone. I had help, especially from a close dev colleague I work with every day. So all credits are shared and kudos to my trustworthy friend.
Additional
It's funny how lifeâs coincidences happen. A couple of weeks after completing the upgrade, I came across a really interesting article about a similar upgrade done by Airbnb. How cool is it to find a write-up that describes the exact same work I had just accomplished!
Feeling proud and excited, I shared the post on my LinkedIn profile, adding some personal thoughts on the process.
The article itself is the following: "How Airbnb Smoothly Upgrades React" by Andre Wiggins.
Story
Some tech details to take into account: (1) This upgrade was from Angular v16
to v17
, and (2) by the time of the upgrade v19
Angular was not released yet.
The assigned task was simple: upgrade Angular to stay within LTS and avoid falling behind on releases, while also protecting the project from potential security breaches.
Summary
It was a success! The upgrade worked as expected, with minimal issues from breaking changes.
Full Context
đĽď¸ Tech Context
As far as I was told, the project originally started with Angular v13
and remained on that version for approximately a year and a half. Then, about six months after I joined the project, the first upgrade was executedâfrom v13
to v16
âby a fellow developer who was in charge of the main UI components.
When we were assigned the second upgrade, our first task was to evaluate whether to upgrade to v17
or go all the way to v18
. We had to analyze the time effort, potential breaking changes, and which option would be the most practical.
Of course, the answer was pretty straightforward:
âď¸ Move to the next version and make it work without breaking anything.
âď¸ Ensure that clients wouldnât even notice the upgrade happened.
đť Tech Context
The UI of the project is split into two main modules:
đ˘ -> The main app UI.
đď¸ -> A built-in custom component library with a playground to showcase all components, which feeds into the main app.
Since both modules are separate Angular projects, this meant we had to perform two separate upgrades to ensure compatibility. The full upgrades on both cases took about a full sprint, approximately two weeks.
The steps we took to make the upgrades were:
1ď¸âŁ Created a decision document
- We analyzed the pros and cons of upgrading to
v17
vs.v18
. - Once the decision was made, we expanded this document into a guide to define the best strategy for the upgrade.
2ď¸âŁ Conducted thorough research
- We reviewed Angularâs official documentation on upgrading.
- This helped us identify the required changes to comply with the new rules introduced in v17.
3ď¸âŁ Presented the upgrade strategy
- We compiled an approximate estimate of time, development effort, and potential challenges. Alongside with the breaking changes.
- We also took into consideration possible upgrades of third-party libraries we also use in the project that must be upgraded in order to work as well.
4ď¸âŁ Do the upgrade
- We executed the upgrade on both projects and began testing the entire app to ensure everything worked correctly.
- We deployed it to a test environment multiple times to verify all changes, carefully inspecting the
ng-version
on each deployment.
After multiple deployments and thorough testing, the upgrade was a success both locally and in an isolated test environmentâthough not yet in the DEV or MAIN environments. This was our primary objective before moving forward.
The Day After
Once we successfully deployed to our development environment, we initially thought the entire operation was a complete success. However, we soon noticed that the local Angular server was experiencing serious performance issues.
â ď¸ The problem?
- It was consuming a huge amount of memory, causing the app to frequently crash and even overheat the computer.
- It seemed that the new Angular update had issues with the builder and hot reload.
â
The solution?
We switched to the new esbuild-based builder with Vite:
đ @angular-devkit/build-angular:browser-esbuild
This not only fixed the performance issues but also made the entire project significantly faster.
Although this builder was already available from v16
, it had not been applied. However, for v17
, it became essential in our case.
Other challenges
In the weeks following the upgrade, the most common issue we encountered was with the UI framework we use for our components.
- Some functions were deprecated.
- Some component names were changed.
- Most unexpectedly, some automated functionsâsuch as dropdowns, panels and checkboxes, among othersâbecame manual.
Fortunately, styles were largely unaffected, and the Angular app itself functioned correctly, with most flows appearing stable. However, the UI components where these changes were applied were significantly impacted.
Nothing that sitting down and carefully debugging couldn't fix!
Conclusions
For my first time participating in an Angular upgrade process, I definitely felt up to the challenge. This wasnât my first time handling upgradesâas youâll find in later posts on my blogâI had previously upgraded Next.js a few times, as well as a create-react-app project. However, those were small and simple projects compared to this one.
The bigger the project, the harder it is to keep everything up to dateâeven more so when working with a team of over 50 people, including developers, BAs, SMs, POs, QAs, stakeholders, and more.
Lessons Learned from This Experience
đ Angular updates and releases move fast.
- This might not be news to some, as rapid updates are common in certain software. If this is the case for your project, prepare accordingly by allocating time and resources to make upgrades a regular cycle.
đ You donât have to upgrade with every release.
- Itâs not always necessary to update immediately with every new version, but try not to fall too far behind either.
đ Teamwork is essential!
- Upgrades like these can be done by a solo developer, but it's best to work with two or three teammates. Constant feedback, double-checks, reviews, and testing are key to success.
đ The more complex the business, the more complex the projectâand the harder the updates.
- Larger projects with intricate business logic make upgrades even more challenging.
đ Confidence is keyâtrust yourself!
- Sometimes, things arenât as hard as they seem. Learn as much as you can, trust your abilities, and research properly. Every goal can be achieved successfully with the right attitude.
đ Patience is crucial.
- Be transparent about the process.
- Share and show real progress to interested parties.
- Communicate effectively.
- Create a strategy and stick to itâbut be flexible enough to adapt to unexpected circumstances.
Recommendations
Here are some recommendations I would give to othersâand follow myselfâwhen working on projects and upgrading them to newer versions:
â Keep your project updated constantly.
- This includes keeping third-party libraries up to date as well. Donât wait too long to make the jump!
â Be cautious with the latest versions.
- New releases may be buggy, fragile, or introduce breaking changes, so if necessary, stay close to the latest stable version instead of always jumping to the absolute latest one.
â
When upgrading across multiple versions (e.g., v16
to v18
), set checkpoints.
- Find a stable intermediate version, deploy it, and then proceed to the next upgrade. For example, if
v17
is stable, deliver that first before moving to v18.
â Avoid tech debt at all costs.
- Itâs better to push small but high-quality code that follows best practices rather than shipping multiple features with inconsistent logic.
â If taking on technical debt, document it properly.
- Be aware of the potential long-term cost, and make sure the team knows the risks. It can make the next update to break those code!
â Follow code conventions strictly.
- Once coding guidelines are set, stick to them. They exist for a reason!
â Donât reinvent the wheel!
- Understand the framework youâre using and follow its best practices, recommendations, and styling guidelines.
- Each new release builds upon previous versions, so sticking to the framework's best practices ensures a smoother upgrade process.
â Donât rush!
- Even if 90% of the app seems to work, donât assume itâs safe until you verify the remaining 10%. Just because it works in most places doesnât mean it works everywhere.
â Test everything properly, especially if the product is live.
- Thorough testing is critical when the product is already in production.
â Be wise when choosing the stack at the first stage of the project.
- The key to every successful project is choosing the right tools at the earliest stage of architectural design.
- Don't just follow the crowd: Avoid picking tools just because they are popularâwhat works for others may not be the best fit for your project.
- Analyze the project with a medium- and long-term perspective: Find compatible tools that integrate well with each other and will remain relevant as the project evolves.
- Look for proven success cases: Choose technologies with a track record of delivering value and measurable benefits.
- Consider how updates will impact the project: Keeping up with the latest releases is crucial, but itâs hard to predict the direction a framework will take.
- Choose tools that offer:
âď¸ Strong support.
âď¸ Robust security.
âď¸ A history of reliable updates.
- Choose tools that offer:
â Create a strategy, build a plan.
- Have a strategy and stick to itâbut be flexible enough to adapt to unexpected circumstances.
â Be prepared to backtrack if needed or requested.
- It may not be ideal, but it's a situation that can happen.
Final Notes
On a personal note, it feels incredibly rewarding to be part of this kind of project. The knowledge gained and the experience acquired not only help me grow as a developer but also as a person and a professional.
I feel grateful to be part of work like thisâsomething I have always aspired to be involved in.
Cheers,
Randy MS
đ