A smooth Angular migration strategy in a chaotic world

Photo by Chris Briggs on Unsplash

Technical backlogs and massive technology migrations are always difficult to convince and execute at a very early stage of a product journey. As the heading suggests the problem statement we had was to convince everyone into getting an Angular Migration (AngularJS to Angular 6+) plan approved and ensure that this model would last a very long term, without affecting:

1. Active feature development.
2. Performance even if this project execution spans over a very long time.
3. Upgrades to external packages used within the system, so that your software isn’t outdated by a long way.

The above points become extremely crucial when:

1. When you are at an MVP/MMP stage or you are Initial/Growth phase. These are the stages your main focus would be on New feature development, this is because at these stages your product is not finished and ready to sell to the wider market you are targeting. Your focus and energy will be mainly channeled towards enhancement requests and new feature developments, so that you would be able to enable the organization to hit the sales goals. These are stages when technical backlogs take least priority
2. You are building an Enterprise grade software and you cannot afford to have downtimes, performance problems, buggy experiences, etc.

Based on all the above points and various experiences we could gather from various blogs, tech write ups, etc. we could jot down the following approaches:

1. Rewrite the application completely — This was a clear no go, because our application was pretty large sized at that stage itself and because we were still transitioning from MVP to MMP stage, we just couldn’t afford to stop active feature development as a whole. If we were to continue active feature development using this strategy our development and testing cost for the same feature would almost double, and we would end up with redrawing the finishing line continuously.
2. Use iFrames and rewrite parts of the application — This would have two different problems, including the point above albeit at a modular level or a business area level, also at the same time too many iFrames would end up creating performance bottlenecks and code management and maintenance would be a huge challenge.
3. Use ng-hybrid recommended by Angular itself — We took this road mainly because we can coexist both Angular versions. Thus new features can be developed in Angular 6+ and plan a migration journey for existing code. Of course the initial effort required to set this path was huge and at times very tiring for those were directly involved in setting this strategy in code. Some of the challenges faced were as below:

a. We had a custom build system so, we had to upgrade that and also revamp the build system to cater to the hybrid code.

b. We had a performance problem at a slightly later stage since we started off with the upgradeStrategy which is where documentations go. The problem was this strategy runs change-detection cycles and digest loops a lot more than required and screens that were complex became very slow for the user even in production mode. So we had to switch to downgradeStrategy, which runs the CD and digest loops in a very optimized way. Documentation for this strategy was very minimal for some reason, but it didn’t matter for us at the time.

Currently its been 3 years since the Hybrid mode was created, we are in the final stages of migration. Over the span of these 3 years

1. We have shipped various complex and ultra complex features
2. We have executed various technical backlogs including migration tickets
3. Upgraded from Ng6 to Ng9
4. Moved to ivy engine
5. Revamped our build system.

So if you are thinking about such a migration in Angular space, I believe this small article would be able to help you arrive at a decision. You may also reach out if you need any help, may be my experience would be helpful.