I recently received a question from a former colleague regarding the .NET Framework they were using for their application. The question was: should we regard .NET 4.6.2 as legacy? The question that follows from this is: should we make the effort of moving to a newer version or to .NET Core?

Even if you’re not using .NET, this post may still be relevant to you, because you can apply the thinking to your application and framework.

The Support Lifecycle

One thing any company should check is the support lifecycle of the framework they’re using. This is important as the framework might stop receiving important updates for performance and security improvements. There might not be anymore bugfixes or the framework may even stop working on modern hardware or operating systems.

In the case of our question, we have to look at the lifecycle for .NET Framework 4.6.2. The start of the lifecycle is fairly recent (2016), but the end depends on how you look at it. Microsoft has a mainstream support and an extended support.

When mainstream support ends, Microsoft no longer enhances the product. Seeing as this is the .NET Framework at a specific version, we can more or less safely ignore this. It also means there won’t be any bugfixes anymore. This can be more of an issue to you.

When extended support ends, we have an entirely different situation altogether. When Microsoft ends extended support, it stops releasing security-related fixes. This is a more critical issue.

If you’ve gone beyond extended support, I’d recommend you check your options or have a very good reason not to update.

The support lifecycles of the .NET Framework are tied to the corresponding Windows OS. .NET Framework 4.6.2 was released as part of Windows Server 2016 and Windows 10 v1607.

  • The mainstream support for Windows Server 2016 is scheduled to end in 2022.
  • The extended support will end in 2027.
  • The client Windows OS support has already ended.

Assuming you’re running .NET Framework 4.6.2 on Windows Server, you still have a few years or support ahead of you, especially if you’re counting on the extended support.

Conclusion: You still have some years of extended support

The Community

This is a hard one to measure, but it’s important nonetheless. If your application is running on a (version of a) framework that no longer has any support or enthusiasm from the online developer community, your team will find it increasingly difficult and frustrating to maintain the application.

When developers implement a feature, they very often look for resources online:

  • documentation of the framework
  • libraries that help implement the feature
  • articles on how to code certain features

If this information is hard to find, they will be wasting time, and money. They might even be forced to implement features themselves, when existing solutions for newer frameworks exist. This is a risky situation, because a vibrant community will definitely be able to create a better solution: more secure, more performant, and with more frequent updates and bugfixes.

So, does the .NET Framework 4.6.2 lack an active community?

More and more, this is the case. Many open (and closed) source libraries are focusing their efforts on .NET Standard 2.1 which has no support for the .NET Framework.

Documentation-wise, my experience is that you will still find more than enough information on .NET 4.6.2, especially because so many remains the same between .NET versions. But it can become harder to find, because .NET Core is gaining traction so much. Many online searches will return .NET Core results that won’t always be applicable to .NET Framework.

Conclusion: community support for .NET Framework is diminishing

Your Team

Now that I mentioned the developers looking up online resources, it’s time to take a moment and look at your team.

Working with an aging framework has consequences. Not only regarding the online community and the amount of help your team can find online. An aging framework is also usually less fun to work with for developers.

Good developers like to learn new things. They like to apply what they’ve learned. This can clash with the risk-adverse nature of a business, but a balance can be found between the two.

However, when you keep programmers working with things that feel out-dated to them, they will leave. This is apparent in the 2019 StackOverflow Developer Survey. When asked what the most important factor is to choose between two jobs with the same compensation, benefits and location, developers had a large preference for “languages, frameworks and other technologies [they] would be working with.”

To make it worse, those that stay aren’t always the most talented developers. And given the current market circumstances, finding new developers is extremely hard.

You want to avoid losing developers as much as possible.

Conclusion: Remaining on .NET Framework will make it harder to find and keep developers

Your Application

A final but important aspect in the decision of whether or not you should upgrade to the newest framework, is your application.

If your application is running along nicely, isn’t mission-critical and needs little to no maintenance or change, then you have a compelling case not to upgrade, as long as there is support by Microsoft. It simply doesn’t make business sense to invest money and take a potential risk of breaking things for the small added value that you will get out of this effort.

If your application is making use of very specific API’s that are only available on this specific (version of the) framework, then you might not even be able to upgrade. Ask your developers if this is the case for your application.

the application is the factor that decides when you upgrade, not if you upgrade

There are all kinds of possibilities here: mission-critical applications that don’t need maintenance, non-critical apps that constantly need attention, apps that run on a system that is losing support from the vendor, etc.

So this is a clear case of it depends. Though you could say that the application is the factor that decides when you upgrade, not if you upgrade.

Conclusion: At a certain point in time, if the application is still necessary, any application deserves an upgrade.

Upgrade or Not?

So should you upgrade or not? In the case of .NET Framework, I would say yes. Unless it’s a non-critical application that doesn’t need a lot of attention. In that case, you can wait until 2022.

But for any application, critical or not, you should start planning an upgrade.

Communicate this to your team so that they can stay motivated.

One possible approach could be to start splitting off functionalities into separate applications (i.e. microservices). But maybe your application isn’t too large and you can invest a reasonable amount of time into upgrading it in one go. Or you might want to extract all non-framework-specific code into separate libraries first (i.e. libraries that work on both the old and the new platform).

You probably will have to invest a reasonable amount of effort into it. That’s the nature of the IT industry. Companies, communities and vendors move on. You don’t want to be left behind because your risk issues like:

  • reduced security
  • missing out on bugfixes
  • lower performance
  • reduced developer motivation

Pitfalls When Upgrading

A word of warning: when upgrading, try to focus on the upgrading. Don’t think: “oh, while we’re at it, we’ll move to an event-based architecture and change our underlying data store.” This just increases the risk of things going wrong.

Reducing Risk When Upgrading

How to upgrade is worth a separate post entirely, and is very much a technical concern. But you’ll definitely want to reduce the risk.

One way to gradually upgrade could be to extract specific pieces of functionality into smaller services and move those to the newer platform. This allows you to evolve towards the newer platform and possibly towards a microservice architecture, which could be an extra benefit.

Another recommendation is to extract pieces of your application into libraries that are more framework or platform agnostic. In the case of .NET, you will want to ask your team to port code to separate libraries that target the .NET Standard (2.0 or lower). This allows these libraries to be run on both the older .NET Framework and on the newer .NET Core and .NET 5. But this technique might not always be an option, depending on the framework or platform you’re application is running on.

Start Planning

When I originally wrote this, my advice was that it could be OK not to migrate to .NET Core but that business should start planning. Today, this is still true, but the urgency has increased. Don’t wait until 2022, because you don’t want to rush this.

Start planning a migration to .NET Core and skip any later releases of .NET Framework (like 4.7 or 4.8). It’ll ensure your application can move forward to .NET 5 and on.

Leave a Reply