back

by doitLP·6y ago·view on hn ↗
They are wholly incompatible. The choice of the Angular name for this new framework was just marketing, beyond some similar design choices. Probably there are better ways now but here’s how I did it:

* Determine exactly how moving to a new framework will benefit your users. If it doesn’t, why are you doing it? It is going to be a lot of hard work and your users will not care you’re on a new framework.

* evaluate if Angular really is the right choice to upgrade to * if it is, do not mix the code in one repo. Use two repos.

* Migrate route by route, starting with lowest impact pages first. When user clicks on the route served by the new angular page it will point to the new app

* to support this, you’ll need to build out foundational modules critical for the switching to happen, e.g. auth, common header, footer, menus etc

* how the switch happens between routes is up to how your app is served. You will need to configure the domain to stay the same between serving the different apps.

* update your deployment and testing strategies to account for two apps going out instead of one.

* we took a bell curve approach, lowest impact routes first, then peaked with critical routes, then back to less and less important pages. This allowed a gradual ramp up to work out the kinks but at some point you will need to get your most important stuff moved over so you’re not building two systems.

* get buy-in from stakeholders that this migration is going to add value for users. Get them excited so you are working together to get it all moved over.

* allocate x% of Dev time to the transition.

* agree on a date for each route and for the full transition so work can be prioritized.

I’m sure there’s loads of blogs with more specifics. Just wanted to share my experience at a high level.