Does anyone know what this thing even does? : Strategies for effectively managing legacy systems

Any organization that has been around longer than a few years will have accrued some "legacy" IT assets. Systems are always expensive to develop and implement; replacing a legacy system is no different and can even cost more due to the need to phase out an old system. But why does a system become legacy in the first place? What does the word "legacy" even mean? Usually the quality of a legacy system has degraded to such an extent that it needs to be replaced, or that the cost of change is so high that replacement is preferable to updating the old system. Legacy can also mean that the platform--either software or hardware--on which the system is running is old and no longer supported. Legacy systems are not just associated with a high cost of change but also with significant business risk if they were to fail.

In these lean economic times we need to maximize the value of our investment in IT systems. Organizations often focus most of their attention on creating systems, but 70% of the cost of a system is incurred after it goes live. Legacy systems are often associated with high support costs and slow response to business change. The replacement efforts often fail spectacularly, wasting huge amounts of time and money.

This ThoughtWorks technology briefing will discuss how and why IT systems earn the dreaded "legacy" moniker, what you can do to avoid systems becoming legacy, and how to improve the way you manage a system once it becomes legacy. We'll describe how to evaluate assets in your portfolio and developing a plan for each one. We'll talk about platform strategy, a plan for evolving a system as well as just operating it, and maintaining quality through a healthy codebase. We'll look at life-expectancy as a stated project goal, choosing not to replace a legacy system but to work effectively with it, and structuring a successful replacement project when a replacement really makes sense.