Several years ago, 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)? While it has been several years, this article is still one of my more popular ones, making me think still a lot of teams are struggling with this question. Which is also why I keep updating it.
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 lifecycle started in 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. 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 ended 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 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?
Today I would say yes, that’s the case. Many open (and closed) source libraries are focusing their efforts on .NET Standard 2.1 or later, or .NET 6. And this means no support for the .NET Framework.
Documentation-wise, Microsoft has a rich set of documentation on its older products, including .NET 4.6.2. But documentation of non-Microsoft .NET products have become harder to find in some cases. And many online searches will return results that are no longer applicable to the older .NET Framework.
Conclusion: community support for .NET Framework is all but gone
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.”
In the 2022 StackOverflow Developer survey, you can also see that developers love newer .NET platforms (.NET Core, ASP.NET Core), while they dislike the older .NET Framework platforms.
To make matters worse, developers that stay at your company 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, isn’t publicly accessible (security!) 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 now 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.
But due to the aforementioned factors, you should know what you’ll be doing with the application in the future. Either you stop using it or you upgrade it. In both cases, you need to plan accordingly.
You could say that unless you no longer need the application, 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? If you’re still running on .NET Framework, yes. Definitely yes. Not all is lost, but 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 (check out the Strangler pattern). 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.
What you definitely should do is invest time in automated tests and monitoring.
Start Planning
Start planning a migration to a supported version of .NET. This can be the latest .NET Framework version or better yet, the latest .NET (Core) version. It’ll ensure your application stays healthy and reliable.
If this frightens you or you think all is lost, give me a call or contact me. I love this sort of work!