What are the best strategies for dealing with legacy systems that cannot be updated?

The initial stride in navigating the labyrinth of legacy systems lies in a judicious assessment of risks and benefits. Scrutinizing the potential pitfalls and advantages ensures a nuanced understanding of the landscape. This strategic appraisal sets the stage for informed decision-making, guiding organizations through the intricate process of managing systems that resist contemporary updates.

My thoughts, you need to have a holistic view, right from the operating system all the way to the main application as to how far behind the system is with respect patching, this will determine the scope of work for securing the system, and I can assure you that it will be a gloomy one.

It always is best to assess the risks. Start by compiling a list of dependencies. If it's an application what does the application rely on? Web server? If so, is it version dependent? Openssl? The same? Is its dependency on a version that has a known vulnerability? If so, can you upgrade the dependencies without breaking the application? Yes? Then your battle has become a little easier. If not, then you must assess the value of the application and if you are able to achieve an ROI from the man hours needed to isolate it, purchase and engineer an virtualization platform (if one doesn't exist). Due diligence and project planning with cost and time implications must be performed.

An instrumental facet in the art of dealing with unyielding legacy systems involves the implementation of patch management best practices. This tactical maneuver, akin to a skilled conductor orchestrating a symphony, involves meticulous planning and execution. By seamlessly integrating patches, organizations erect a resilient defense against vulnerabilities, ensuring the continued functionality and security of their entrenched systems.

I think this question does not belong here and it is mistakenly asked. The main question emphasizes: " legacy systems that cannot be updated." that implies you cannot patch it at all! The best practice to follow here is to either upgrade or replace the legacy system in question and no other option unless it is for personal use, but if it makes revenue for an organization then it must be prioritized or better, it must be treated as an emergency and must be upgraded/replaced. Just imagine, some legacy system running windows 2000 and requiring protection in 2024! so one spends capex/opex to protect a literally dead system? instead of replacement, surely that goes against system engineering and life-cycle management principles.

In the dynamic realm of technology management, isolating and fortifying legacy systems emerges as a strategic stronghold. This approach encapsulates the essence of shielding entrenched systems from the ever-evolving threats in the digital landscape. Just as an ancient artifact is preserved in a controlled environment, isolating legacy systems allows organizations to safeguard critical functionalities without succumbing to the pitfalls of obsolescence.

I did express my views on obsolete systems on 2. Nonetheless, if a legacy system has to run on a production system, then "Virtualization" is the saviour of the day. Quite often legacy systems suffer unprecedented failures to such a degree that there is no way of bringing them back to operation due to the hardware platform being obsolete or not available on the market, for instance one might have an application that is heavily dependent on windows vista upon failure of the hardware platform, the replacement ships with windows 11 or some Linux distro, this then prevents the utilisation of the application as was the norm. With virtualization the application can continue to operate with its host OS and the segementation policies thereof

The decision to modernize or migrate is a pivotal crossroads in the management of unmodifiable legacy systems. Modernization entails infusing contemporary elements into existing systems. It's about giving a fresh look and enhancing functionalities without entirely discarding the familiar setup. On the other hand, migration involves moving away from the existing system to an entirely new platform or technology. This strategic choice requires a thorough understanding of the organization's goals, budget, and long-term vision. It's about striking the right balance between preserving what works well in the legacy system and embracing innovations that align with evolving business needs.

Yes, this question should have replaced question 2 as it is more in alignment with the primary question. Systems should be modernized or migrated way before they reach obsolescence state whilst on commercial operation. when the system is purchased, the life cycle is well known, this talks to operations, maintenance and engineering perspectives, if these are well managed, a system at year 8 must be different from the same system when it was 2 years old, of course, this is due to the evolutionary character of the system (NB: I am referring to OT/IT Systems in particular) and obsolescence should not catch any one by surprise (please note that the previous statement might be suggesting that there should not be any legacy system in operation!)

Architecturally, it is recommended to separate the layers of a system. An excellent example of such an approach is explained in the "API-Led Connectivity" article by MuleSoft. It suggests having three layers: experience, process, and system. It is advisable to access the legacy component via a separate wrapper service that provides a modern API for internals and takes care of rate limiting, circuit breaker, etc. Organizationally, legacy systems usually come with outdated practices and habits, like changing the database schema manually directly in a prod environment. These habits should be upgraded first (by introducing modern database migration approaches, for example).

Cybersecurity and Obsolescence are tantamount to water and oil; they simply do not mix. You can have one, but both cannot co-exist.