What to do with .Net Framework

I’m going to discus this in 4 parts. The problem, a resolution, a strategy and the future and it’s problems.

TLDR

• .Net framework is increasingly hard to hire for and many open-source packages are no longer supported
• Upgrade is hard and re-writes are risky and have a large impact on the businesses ability to generate value
• The Microsoft incremental upgrade guide makes wise use of a reverse proxy to enable a modernisation plan rather than a wholesale re-write
• A Modernisation plan should be driven by measurable business benefits and never end no mater the age of the software
• Upgrading, testing, building, releasing and monitoring ALL software on a regular cadence keeps it fresh in the team’s memory and avoids a situation where upgrades and maintenance cause fear

The problem

.Net Framework was very popular resulting in many large, complex, revenue making applications that depend on it.

.Net Framework is still supported by Microsoft but the industry is moving on, hiring developers is getting harder, and it takes senior developers to navigate the application and add new features. Many of the open-source libraries consumed by these applications are no longer in active development meaning bugs and vulnerabilities will not be fixed. In a recent review of a .Net Framework application I found one third of the dependencies were no longer supported, many more did not explicitly say it, but had not been changed in 5 years.

Due to their age, size and dependency on Microsoft Windows features, an upgrade to .Net (Core) is very difficult, but a system re-write is off the table due the enormous effort and risk.

The resolution

Microsoft understands the issue and have created a guide called the incremental upgrade. This approach makes use of YARP (Yet Another Reverse Proxy) to create an invisible gateway between the user and your web application. This provides a configuration layer in front of your application giving you flexibility on how and where you process incoming requests. Now if you have a desktop application, this isn’t much use, but by inserting similar seams that can be unpicked, the rest of the solution will apply.

You can now exploit this gateway to replace your authentication, or upgrade or replace your application incrementally without an expensive and risky re-write. The Microsoft solution migrates the libraries into .Net Standard using the helper classes they have provided, then moves your User Interface layer into the YARP gateway eventually replacing it. I think you should go beyond this. The gateway gives you immense flexibility beyond replacing like for like, you can split bits of your application off into their own services in any language, or re-architect your API and use the YARP layer to ensure requests are correctly routed.

Using a method like this gives you control over how much resource you dedicate to upgrading your application over a timescale that suits your business.

The Strategy

Many businesses disproportionately focus on building new features to add value rather than ensuring their software remains current which is a large part of why they still have a .Net Framework application. A change in culture and approach is required, starting with modernisation plan to replace the .Net Framework application.

Once the YARP gateway is in place, review the software against company performance and goals, where is the software letting the business down? What could be changed that will prove a benefit to the company beyond simple replacing .Net Framework? What can be done quickly with low risk? These problems are easier for the business to understand and build confidence in a modernisation plan. Don’t start with a 2 month change that will enable future improvements but is only understood by the engineers. Your modernisation plan should continue to make incremental improvements at a rate acceptable to the business that still allows value adding features to be built.

Really, there is no an end point to this. Software requires constant review to understand where business requirements or aging technology mean the original solution is no longer correct. An understanding of the impacts of software and modernisation is something that all businesses should undertake, not matter the age of their software.

The Future

The word of .Net (Core) is not all glitz, glamour, smooth sailing and fast feature development. The release cadence of .Net (Core) and other modern languages/frameworks is faster than .Net Framework and the length of support for LTS (Long Term Support) versions is much lower. You should expect to be upgrading every year or two. But, as discussed, the reason businesses have got into a bind with .Net Framework is they haven’t focused enough on maintaining their software. In her book Kill it With Fire, Marianne Bellotti discusses a point at which a piece of long running software flips from something businesses love for it’s stability to something they fear because they no longer know how to fix it if they need to. Upgrading, testing, building, releasing and monitoring ALL software on a regular cadence keeps it fresh in the team’s memory. Regular releases and an understanding that software architecture needs to evolve will guarantee technology remains current and maintainable.