If the technology your system is built on no longer has support, yes, it's dangerous to stay there. But let's keep the danger in proportion: nothing crashes the day support ends. Your system wakes up working exactly like it did yesterday.

That's where the risk starts, and it's why it's so easy to ignore. Nothing breaks, nobody complains, and the system keeps falling behind without anyone noticing.

An example happening right now: .NET Framework

Every system is built on a base technology, and that technology has an expiration date. Plenty of business systems run on Microsoft's .NET Framework, and there's a lot of confusion around it: it doesn't have one end date, each version has its own.

Version Microsoft support
4.0, 4.5, and 4.5.1 Ended January 12, 2016
4.5.2, 4.6, and 4.6.1 Ended April 26, 2022
4.6.2 Ends January 12, 2027
4.7, 4.7.1, 4.7.2, 4.8, and 4.8.1 Follows the support of the Windows version it's installed on

If yours isn't listed, check Microsoft's official lifecycle page. And if your version depends on Windows, check the server too: Windows Server 2016 loses support on that same date, January 12, 2027.

Why it matters if the system works fine

At Monobits we worked with .NET Framework for many years and it served us very well. It's not bad technology. The problem is that new vulnerabilities are discovered every day, in every technology. While a version has support, the vendor fixes them. Once it doesn't, they keep getting discovered, but nobody fixes them anymore.

Think of it as the lock on your business. One day someone discovers a trick to open it without a key. As long as the manufacturer is still servicing it, they replace it and you're done. Once they stop, the trick keeps going around, anyone can learn it, and that same lock is still on your door. The door closes like it always has and nothing looks different from the outside, but it's no longer protecting you.

It used to be good practice. Today it's security

For years, updating a system's technology was good practice, and you could put it off. That has changed. Vulnerable systems turn up every day, and with the artificial intelligence available now, finding and exploiting weaknesses in websites, servers, and passwords keeps getting easier and cheaper. Nobody has to pick you specifically: it's enough that your system has a door people already know how to open.

That's why our position is the same for any technology, not just this one: your system should be on a supported version, whatever it's built with.

When can you actually wait?

Not every case is urgent. You can plan this calmly, without leaving it open-ended, if all of these are true:

  • Its base technology and its server are still supported. For .NET Framework, that means version 4.7 or later on a supported version of Windows.
  • Its third-party components are still getting updates.
  • The system isn't open to the internet, or it doesn't handle sensitive data or payments.
  • Someone is maintaining it and applying security updates.

On the other hand, move it up your priority list if the version has already expired, if it's publicly accessible, if it stores personal data or takes payments online, or if nobody is maintaining it anymore.

One important thing to clear up

Updating the base technology on the server helps, but test it first in a separate environment, and know that it only protects the base. It doesn't fix third-party components bought ten years ago or the system's own code.

A few years ago a client asked us to continue a system they already had, on an old version of .NET Framework. They told us it just needed to be carried forward, that a programmer had built it. We later found out it had been an intern. The entire codebase had security problems; honestly, it was a disaster. We chose to rebuild it from scratch instead of patching something that wasn't done right from the start.

So before you decide whether to wait or migrate, have someone check what's underneath. Sometimes an update is enough, and sometimes there's nothing worth saving.

What to do this week

  1. Ask what technology and version your system is built on. Both the version it was built for and the one installed on the server.
  2. Check the server's operating system and when its support ends.
  3. List the third-party components and check whether they still get updates.
  4. Confirm you have the source code and backups that can actually be restored.
  5. Decide with that information: wait with a plan, update, or modernize.

If you can't find anyone who can answer these questions, that's already an answer.