Parts of the series
.NET Framework has always been very popular and widely used in enterprise environment. There are tons of business-oriented applications written in .NET.
From its first version, .NET enabled the developers to build both desktop and web applications, and especially at the beginning, it was really easy to use. Amateur developers, students or even kids were able to create a simple Win Forms app and Microsoft tried to make web development as simple as Win Forms or VB6. That’s how ASP.NET Web Forms was born.
Despite the fact Microsoft has moved their attention to ASP.NET MVC years ago, ASP.NET Web Forms is still very popular and there are many web apps using it. They needs to be maintained and extended with new features.
Microsoft has been working on .NET Core lately, but there are not plans to bring Web Forms onto this new platform. Of course, Web Forms is supported as long as .NET Framework is supported, so there is no need to panic, but still…
Everyone knows that it’s time to move on. But where to?
Rewrite? No way!
You suggest that the app should be rewritten on every meeting during last five years, but nobody listens or the answer is always the same - there is no time or money for that. You know that there is a huge technology debt, however the application must survive next 5 years and there is a backlog full of new features and screens to be delivered – and they need them yesterday.
If the application is 10 years old, there is no reasonable chance it could be rewritten in less than half of that time. And of course, no company can stop evolving its business critical app for 5 years while it is being rewritten.
Starting to build a new version in parallel with maintaining the old one can be a way to go, but it is very expensive. The development team needs to be doubled, and it requires a massive communication between both teams as there is typically a huge amount of know-how to be transferred. A lot of time is spent with studying how (or even why) the old code works because its original author now works somewhere else.
That’s why many companies are trying to modernize their solutions. In the ASP.NET Web Forms, there are some ways how to slowly migrate to a more modern stack – screen by screen, module by module. The path is long and sometimes painful, but it allows to keep introducing new features and extend the lifetime of the application, at least for couple of years.
There are several things you can do to modernize your old ASP.NET Web Forms applications. I will try to address these topics and decisions in the next parts of this series, but here is a quick overview:
You can use modern front-end framework for new modules of the application. The choice of the UI framework depends on the type of the application and also on the skills of the team. The new parts of the application can use a completely different UI stack, but if they use the same CSS, the users won’t notice. In the meantime, the old screens may be rewritten to the new technology one by one.
There are many improvements for the business layer that can be done. Of course, monolithic applications cannot be converted to microservices easily, however some parts of the business layer can often be extracted and maybe containerized. The business layer class libraries can be converted to .NET Standard, which will allow them to be consumed from .NET Core.
Moreover, SQL might not be the right store for everything. Most of the ASP.NET web applications store all their data in a SQL database. Sometimes, it is a good idea and the relational approach is necessary, however using another type of storage in some parts of the application might remove a lot of complexity. In addition, there are new laws and regulations concerning data privacy (GDPR for example). You should review which personal data you have and who can access them.
And remember that modernization is an opportunity for refactoring, cleanup and introducing new concepts. If you are not using dependency injection or automated tests, you should seriously think about starting with them now, at least for the new parts of the application.
Also, you should think about the overall architecture of the application. Maybe some parts can be moved in the cloud, replaced by something else and so on. If there is something that doesn’t scale, it should be the first thing to think about. Create a list of priorities and try to address the ambitious plans for next years in the design.