Introduction

So you’ve got a big app written with AngularJS, and you want to move to something newer, something modern, something supported, something with a vibrant community. Something like React, Angular, Vue or Svelte. Great! How long will it take to migrate your code though? If no two apps are alike, how can you know how long it will take your team to migrate from AngularJS to a newer framework? Keep reading and see how we do this with our partners and for our clients.

Most managers will want a best effort guess about the time required to migrate a project from AngularJS to something newer. If your manager still isn’t convinced you need to migrate, check out some of our other content. We’ve worked on many migration projects, helping teams move from AngularJS to Angular. The following is the best way we’ve found to estimate the time required for a proper conversion. These same calculations will work when going from AngularJS to React, Vue, or something else.

TLDR

We know many of you want the short version first, so here it is:

• Find out how many lines of code (“LOC”) are in your project.
• Find out the average LOC your team writes in a week (“LPW”).
• Solve LOC / LPW. This is your time to migrate (“TTM”).
• Multiply TTM by 1.4. This is your estimate.

TTM Estimate = (LOC / LPW) * 1.4

The Goal

In order to stop depending on AngularJS, we need to define our goal as: The successful removal of AngularJS from the project’s codebase. Having that goal clearly stated helps us frame the rest of the conversation. The rest of this post aims at helping you accomplish this goal. It’s important to remember that on December 31st, 2021, long-term support for AngularJS (“LTS”) ends and AngularJS will no longer receive updates of any kind. Learn more in "What to do When AngularJS Support Runs Out".

Now let’s talk about how to estimate our progress towards that goal.

Lines Of Code

The first variable we need to make your estimate is the total lines of code in your project. By looking at the LOC for your project we can know quite a bit about the task ahead. For our purpose here, we are purely going to use it as a variable in an equation.

So how do we count the lines of code on your project? There are some open source projects that can help us here. One that is readily available is called Count Lines Of Code (“CLOC”), and you can find it here. Using this tool we can quickly discover how many LOC we’re working with.

Our team recommends including your unit tests with your LOC count, as you will be migrating all of your tests away from AngularJS as well.

Lines Per Week

The next variable we need to solve for is: LOC Per Week (“LPW”). This number represents the number of LOC your team writes in a week. Knowing your team’s LPW can be helpful for many reasons. For our purposes, we’re going to use it as an indicator of your team’s velocity. LPW is a way to apply time across your total lines of code in the project.

This can be a tricky number to uncover for some teams. Some AngularJS projects are currently in maintenance mode, and are being maintained by one developer who only works on the project part-time. If this is your situation, you’ll want to look at your repo and find the LPW during a time it was under active development. Another option you can consider is to look at another codebase in your company and find its LPW.

Once you have calculated your team’s LOC production for one week, repeat that process for the prior 4-6 months, then come up with the average LPW over a 4-6 month period. Once you’ve got this, we’re ready to make our estimate.

Time To Migrate

Now divide your total lines of code by the number of weekly lines your team can produce. Divide the LOC by the LPW. The result here is the number of weeks your team will need to migrate your project to a new framework. This is your time to migrate (“TTM”).

While we’ve calculated your team’s TTM, there is one more adjustment required before we can take this estimate to our management. We need to add time to the estimate for your team to learn the new framework and get up to speed with the modern practices in that framework.

Unless your team is already familiar and proficient with the new framework they’ll be using, you need to factor time into your estimate allowing your team nominal amounts of time to get up to speed. We recommend adding a 40% buffer on top of your TTM. So take your TTM and multiply it by 1.4. By adding 40% to the TTM, we’ve added 40% more time to the TTM. This is our final estimate of time required to migrate this codebase from AngularJS to something newer.

Example

Suppose a project has 100K lines of code. Now suppose the team working on that project produces 1000 LOC per week. 100K / 1000 = 100. Add a 40% buffer to that total (to account for learning), and we get 140 weeks as our final estimate. This means that team would need 2.7 years to migrate this project from AngularJS to the next framework.

Additional Notes

It’s empowering for teams to have an estimate based on their historic velocity. Management can make a decision based on the team’s past efforts and velocity, rather than rolling the dice without any forethought into the total effort required to perform a migration.

There are things that will slow down / speed up this process. Let me name a few additional things your team can consider for adjusting your estimate up or down.

Are you going to focus purely on migrating? Or will you have additional features and business tasks to perform as you attempt to migrate your project away from AngularJS?

• If your team expects to migrate while adding new features along the way, your team will need to consider increasing the estimate to account for how that work will disrupt the migration process. Alternatively, you can add developers to the team, which will increase the velocity, and decrease the TTM estimate.

How healthy is your current codebase?

• If you’ve performed maintenance over the years, you may be OK here.
• If not, there may be significant amounts of technical debt that you need to consider in your estimate.

Is your project using Webpack already?

• If yes, great! Most modern frameworks provide you with build/CLI tooling which is based on Webpack.
• If not, you may need to update your build system to use Webpack before you can proceed. For this, you’ll want to consider increasing your estimate.

Is your project using TypeScript?

• If your next framework uses TypeScript, but your existing codebase doesn't, we recommend adding a bit more time to account for the learning curve involved in the JavaScript to TypeScript transition.

Is your current project using the latest version of AngularJS?

• If yes, great! Open source tools that make the migration process easier will be based on the latest version of AngularJS (currently 1.8.4).
• If not, you will want to spend time updating to the latest version of AngularJS. For projects moving from AngularJS to Angular, the ngUpgrade tools built by Google are based on AngularJS 1.8.4. I can confirm, based on extensive experience, that you will encounter unexpected problems if you try to migrate from an older version of AngularJS to Angular. The same applies to migrating to React, Vue, et ‘al. Starting from the latest AngularJS will make the migration go smoother.

This list is not exhaustive. There are many other technical aspects and concerns that you may want to consider in order to add additional precision to your migration estimate.

Conclusion

The estimation techniques mentioned above are fantastic for teams who aren’t sure where or how to begin estimating the cost of the migration process in order to get budgets approved. Having worked with dozens of clients that are migrating away from AngularJS, we are the experts at helping you ask the right questions and building the most precise estimate possible.

We encourage you to begin your estimations by performing the exercises above to derive your initial migration estimates. The XLTS.dev team is here to help you along the way. If you need guidance in any of the following areas, please reach out to us:

• Estimating / Planning - Let us help you plan for this migration.
• Migration Setup - We can do all the up-front setup, so your project can utilize a hybrid framework that supports AngularJS, as well as your next framework.
• Migration Training - Let our experts train your team on the ins and outs of migrations.
• Migration Development - Whether you would like us to take your code and migrate it entirely, or you’d like us to embed with your team and assist with the migration, we’re prepared to begin migrating your project today.

If this is your team’s first time migrating from one framework to another, it can be an extremely daunting and risky endeavour.

To help ensure a successful outcome for your migration, you should contact us and leverage our expert guidance as your team migrates away from AngularJS.

FAQ

Updated: March 5, 2024

The first high-severity CVE since AngularJS End of Life has been officially reported. For AngularJS Never-Ending Support (formerly XLTS) clients, we found this CVE last year and issued a fix immediately. For all others, as Google’s official AngularJS long-term support partner, we encourage you to either:

1. Migrate off of AngularJS, or
2. Contact HeroDevs about how you can keep your AngularJS environment secure, compliant, and compatible indefinitely.