I had been wrestling with this idea for months. My conclusion is that it would be pure insanity to do a migration of a medium size, complex, 7-year old webform app to angular, and probably to anything else except another version of webforms. It would take over 6 months to do so. Very costly and a poor return on investment.
I got very specific as to why I want to migrate, how would customers benefit, how would the company benefit financially, etc. Answers to these kind of questions are leading me down a different path. Although I'm not finished, things are looking pretty good.
There is a pain-point in my code that was driving me to angular. So I plan to use angular just for that section ONLY. I get the new features customers requested and that I can charge for. And most of all, it will have minimal impact on org structure, app session, current database design, and the rest of the webform app.
The vast majority of my time would be developing in angular, and not trying to replace every button event, grid, wizard, etc.
My painpoint webform section is a wizard with 5 dynamic steps(choose a template, update/add/delete stuff, filter for different views, etc.) 4 user controls, 2 gridviews, and all the code-behind stuff.
Amazingly, I can replace all of this without going through control by control. I've learn that the net effect of all the STUFF is only to update a single xml doc stored in the database. By replacing a single div in the aspx page with ng-app, I can wipe out all the code in this aspx section, and associated code-behind code. I don't have to do it piecemeal.
Replacing my aspx functionality with angular looks kind of simple to me. Once the user clicks "done", I will simply send the json to webApi or nancyFx. Then map that json data to the exact shape of the xml doc, and replace it in the db. (Initially populate the ng-app using the reverse)
Here's the important part - I leave all the existing webforms logic, biz layer, and db layer code regarding this xml doc in place. All the ObjectDataSources, classes, everything associated with the xml doc. This way I don't break anything and other code dependent upon the xml doc will work as usual. Sure, there will be a lot of dead code laying around, but I'll use Resharper, later, to remove it after everything is working ok with the new ng-app insert.
Webforms and WebApi can live side-by-side in the same solution and use all the session stuff you mention. For the org structure just add a script folder and put the ng-app code there. Using this method, there's no need to replace server controls with angular code one-by-one. What you are doing is replacing the web behavior and ultimately matching the "final" db state.
For example the gridview will update the db on each row change. Very chatty. Whereas with angular, a grid-like stucture can be user updated with text in various rows, reorder rows, etc., within the browser without any db impact. When the user is finally done, you send the final json object back to the server for db update.