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.
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?
The .NET world is definitely focusing on .NET Core more than it is on the .NET Framework. But thanks to the .NET Standard, .NET Framework 4.6.2 can run most of the .NET libraries out there.
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.
So, while not entirely legacy in this department yet, it looks to me like it will become so in the near future.
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.
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. 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.
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. 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? That depends on the answers you gave to the previous questions.
But let it be clear that most applications will need to be upgraded at a certain point in time. In that case, communicate with your team so that they know that an upgrade is coming (it might prevent them from becoming demotivated and leaving).
Also, create a plan to upgrade. It’s normal that an application still needs new features. Not many companies can afford putting everything to a standstill.
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. This allows these libraries to be run on both the older .NET Framework and on the newer .NET Core. But this technique might not always be an option, depending on the framework or platform you’re application is running on.
So What About .NET?
Regarding the original question: is .NET 4.6.2 legacy (and should I move to .NET Core)? I’d say: not at the moment, but business should start planning a migration. However, this migration could easily be to .NET 4.7 (or the upcoming .NET 4.8) instead of the more fashionable .NET Core. This might not be what the developers want to hear, but it could make business sense. Unless you risk losing all your talented developers, in which case I would recommend looking at .NET Core.