We have an established software stack with regular patching and maintenance practices, but users occasionally request applications that are several years out of date. In our architectural business, some of these tools may be the only ones that meet a particular project requirement, even though the vendor's website is no longer active or the software has not been updated in five years or more. Drivers and legacy dependencies raise similar concerns. How do you decide when to approve, isolate, or reject this kind of request? I'm trying to build a practical risk matrix that considers security, vendor support, business necessity, licensing, and the cost of maintaining a legacy environment.
4 Answers
My normal cutoff is vendor support. If the manufacturer still supports the version, I check its lifecycle, known vulnerabilities, patch availability, and compatibility before approving it. If the vendor is gone or the product is abandoned, I generally reject new installations unless there is a compelling business reason and an approved containment plan. Unsupported drivers should be treated the same way, since they can affect the security and stability of the whole machine.
A simple risk matrix could score business criticality, availability of alternatives, vendor support, age, known vulnerabilities, network exposure, data sensitivity, licensing, and the effort required to recover it. Low-risk or experimental requests can be declined or accepted without support. Critical exceptions should have an owner, a written expiration or review date, a replacement plan, and clear limitations on what the IT team will support.
Start with the business requirement rather than the specific application. If a supported alternative exists, use it. If the old software is genuinely required, get documented approval from the business owner and security or legal teams, then include the full cost of isolating and maintaining it in the decision. That may include licensing, specialized hardware, backups, monitoring, and eventually replacing it.
For software that is necessary but unsupported, I keep it alive in a dedicated virtual machine or on a separate workstation. Take an image or snapshot after it is configured, maintain reliable backups, restrict internet and network access, and only allow the data transfers the workflow actually needs. This is especially useful when an old tool is required to reopen or export files from a long-running project.
Version pinning can be important for projects that last many years. The key is making the old environment controlled, documented, and convenient to restore instead of leaving it installed on someone’s everyday computer.
The department requesting the exception should usually own those costs. Otherwise legacy software becomes invisible technical debt that the infrastructure team has to support indefinitely.