We have an established software stack with regular patching and upgrade practices, but users sometimes request applications that have not been updated in five years or more. In our architectural business, a particular project may genuinely depend on an older program, even though the vendor's website and support appear inactive. Similar questions come up with outdated drivers and legacy dependencies. Where do you draw the line, and how would you build a risk matrix for deciding whether to approve, isolate, or reject these requests?
5 Answers
For software that is essential but cannot be replaced, isolate it. A dedicated virtual machine with an old operating system, restricted network access, no general internet access, and reliable backups is usually safer than installing it on a normal workstation. Keep a tested image or clone so the environment can be restored when the hardware fails.
Not every old application is automatically unacceptable. Consider whether it has known vulnerabilities, whether it handles sensitive data, whether it needs network access, how often it is used, and how critical the business function is. A rarely used legacy tool with no network connectivity may be manageable, while an internet-connected application with known flaws should be rejected or replaced.
A practical policy is: supported software gets normal support; unsupported software is approved only for a documented business requirement; and abandoned or nonessential software is declined. Make it clear that unsupported applications receive limited or best-effort support, and record who accepted the risk and what replacement plan exists.
For long-running projects, preserving a fixed software environment can be the right approach. Keep the application, plugins, drivers, and configuration together in a controlled VM or archived environment so old project files can still be opened years later. That should be treated as a managed exception, not part of the standard desktop build.
Start by looking for a supported alternative. If the vendor no longer supports the product, the default should be not to install it. If the software is genuinely required for an important business process, get documented approval from management, security, and legal, and make the requesting department accept the cost and risk.
The isolation and maintenance work should be included in the total cost. An unsupported application may require special hardware, licensing, backups, and ongoing administration, so the business owner needs to understand the full price rather than treating it as a free exception.