ASP.NET Webforms – should I convert my legacy app to MVC?

If I was starting a new .NET website today then it is easy to say I would prefer to use MVC over Webforms. Over the last few months I have been faced with upgrades on some legacy applications written in ASP.NET Webforms and the big question has been ‘Should I stick to using Webforms or convert these to MVC?’. It sounds an easy answer but it’s not. If your app is of non-trivial size then there are a number of things to take into consideration.

The first question to ask is ‘Do I really need to convert this project to MVC?’

Software developers want to use the latest technologies. It’s natural to want to, but it’s not really a valid reason to spend umpteen thousands on upgrading the applications just for the fun of it. If you make a good job of the conversion then you may find that your customer notices no difference between the two builds. What’s more worrying is that your boss may realise that you’ve spent a great deal of money and time to produce what is essentially the same product.

If you need new technology and you require a visibly improved product then continue to explore the possibilities and advantages of upgrading. If your product will have a long shelf life then you may need to upgrade it sometime, but Microsoft have made no mention of ending Webforms any time soon and there are still a lot of Webforms applications out there.

Assess and understand the risk

There may be a considerable of work involved, probably much more than work than you think. Not always difficult work, but lots of repetitive, time-consuming tedious work. Webforms have page-events, State and many automatic responses that will need to be re-coded (by hand) to a HTTP Post-style operations.

Don’t forget if you make a visual change on one page (like switching a Calendar Control to a jQuery Calendar) then you’ll have to do it on every page or the user will notice the difference immediately.

This work will need to be followed by a full re-test. Don’t assume this is a trivial task.

Ensure that you can replicate the functionality

This may seem strange as you’re upgrading to a newer technology, but Webforms use object components/controls and some have considerable complexity – and no available source code. I worked on one project that had a customer-supplied security component and we were told there would be no upgrade or replacement specifications available. Are you legally entitled to clone these?

Even innoculas Webform controls can carry considerable functionality and you may have to write back-end code and front-end JavaScript to duplicate the functionality. Razor and/or other JavaScript frameworks may help considerably in replacing these.

Remember you will probably be faced with other older technologies and techniques

Webforms are an old technology and accompanying them is older style thinking. You will probably be dealing with DataSets rather than Lists. We used drag-and-drop; drag a SQL connection, drop a datatable component in there. We then ended up with HTML which used Tables for formatting. At the time we loved the RAD (Rapid Application Development) ideology but now we’ve left a large bowl of spaghetti to untangle. You’ll probably miss the likes of LINQ and Entity Framework.

If you must convert, clean the code first.

When Webforms were released (about 2002), Microsoft talked about separation of concerns and really they did a fair job at achieving this. We had the (near) equivalent of MVC where Classes = Models, Web Pages (.aspx) = Views and Code Behind (.aspx.cs) = Controllers. What we didn’t get was the advice that we should have fat models and thin controllers. Instead emphasis was on click-and-code for rapid development. The result is that we ended up with lots of code in the code-behind pages, and that makes upgrading to MVC a pain.

So before you start converting, I recommend that you clear these pages of as much code as possible and move it to where it should be – in the Models (aka Classes) and ensure it still works as before.

Will an hybrid app be easier?

Microsoft have given us a good option in allowing us to mix Webforms and MVC in a single ASP application. Add a few binaries, modify the web.config and you can run both technologies side by side. However, they don’t entirely integrate. For example, you can share the same Session (which is extremely useful) but you can’t share Master Pages and Layout pages, and you can’t drop webform controls on Views. There may be other ways around these drawbacks, like using jQuery on Webforms to display partial views by calling MVC controllers.

One of the strategies that I have used several times and one that saves lots of work is that if the application has a distinct User side and Admin side then keep the admin side in Webforms and rewrite the main User facing pages in MVC. That way the user sees the new technology and gets an improved user experience, but the admin side is mainly left alone. Admin sites tend to have lots of data tables, queries, editing facilities, graphs and reports that can be tedious to replace.

If you are going do a full upgrade then start with a new empty MVC project.

With experience I’ve found that to avoid any strange glitches and weird compile errors it’s better to start clean and add functionality from the old app. You may find there are parts which are no longer required in the new app. You will get a more incremental build and testing cycle.

Learn your lessons for the next time.

In a few years time you’ll probably be upgrading this new application to the next all-singing, all-dancing technology. Learn your lessons from the problems you’ve had with this upgrade and try to organise the app to make future transitions easier.

In reflection, I can remember converting some of the apps previously, when we moved from Classic ASP to ASP.NET Webforms. Strangely, much of the conversion to MVC is putting the code back as it was! Maybe ASP wasn’t so bad but we just didn’t understand how to write it properly. Now we have a MVC pattern and powerful Javascript frameworks like jQuery, Angular and React. Maybe in the future we’ll return to click-and-code with binary Components rather that Objects.

Whatever the future, you can bet it won’t be the last time we do this.