How to migrate ASP.NET Web Forms to Angular and .NET Core

If you came here to get some hate for ASP.NET Web Forms you've come to the wrong place. More like how I feel about my ex-in laws; I can tolerate them but prefer not to spend time with them.

ASP.NET and Web Forms played important roles in building out the World Wide Web to be more than cat photos (remember?). But now it's an obsolete technology that has a lot of shortcomings, including finding a developer under 60 who's already familiar with the platform. 

In terms of migrating to something contemporary, it has a few things in its favor: it's a web technology (not a desktop one) and it uses C# and the .NET Framework. 

In our continuing effort to find ways to kill off Windows legacy coded--by making it modern and better--we've hit a major milestone in our technology to modernize ASP.NET Web Forms.

WebMAP and Angular to the rescue

Our WebMAP technology is clearly the best and fastest way to modernize older Windows-desktop stack to web with ASP.NET Core and Angular. Since its introduction a few years ago (I'm too lazy to look up the date, so there), we've had customers from all over the world find this approach cuts time, risk, and cost to move desktop apps to performant, modern web applications. We've developed versions that can migrate C# Winforms, VB6 (via Winforms), VB.NET, PowerBuilder, Silverlight, and Access to Web. Now, with WebMAP for Web Forms, we're going from web to (better) web. (Note we only support ASP.NET apps written in C# at this time).  Here's how we do it:

1. We preserve the business logic for all of the form controls and events in C#, migrating them to use ASP.NET Core. Using Harry Potter Magic™* we mirror the original code for easy maintenance by your team
2. We separate the user interface for all the forms (including all the controls, properties, position, etc) to a separate project
3. The UI or client project uses Angular and Kendo for Angular (for UI widgets) with HTML5 and CSS. No runtimes or funky plug-ins required to run on any browser.
4. We run as a single page application (SPA), tracking changes to the view model and updating the server only with changes; this reduces chattiness and keeps performance high.

With this approach, we have de-coupled the back end from the front end which makes future maintenance and enhancements a lot simpler and faster--use client side folks to maintain the client and C# devs to work on the server side. 

Why?

Why not indeed? 

Our mission--from the very beginning 20+ years ago--has always been to build tools that can automate migration from legacy languages and platforms to modern ones, while preserving the business logic and the UI. A customer comes to us with an important app that's, say, 5 million lines of code. Realistically, can they actually rewrite it in any predictable timeline or budget? 

We've learned as size of an app increases in LOC, complexity increases as an exponent of that size. I don't have a proof, but I think it's reasonable to concede that it's not linear--a 500kloc app is much more than twice as complex and risky to rewrite than a 250kloc app. Again, no proof but it seems similar to the concept of polynomial time. 

Want to learn more? Check out our web page here. We have a repo on github with before and post-migration code here. You can build each version and fool around with them. I'm going to do a code walk-through video shortly (this is pretty new so even I haven't had much of a chance to mess with it) so Watch This Space! as they say. 

LMK what you think and if you have questions. My email is john.browne@mobiize.net. I LOVE hearing from you.

* Just kidding. It's actually called code weaving and takes advantage of Roslyn. https://www.mobilize.net/products/app-migrations/webmap-aspnet-webforms