Legacy Systems in Software Engineering: Definition, Problems, Assessment and Migration Strategies

"What is a legacy system? Explain the problems of legacy systems and the strategies for dealing with them" is a standard question in the Software Evolution unit of the TU BSc CSIT Software Engineering paper (CSC375) and in the BIT Software Engineering paper (BIT302). It is usually worth 5 marks on its own and 10 marks when combined with re-engineering or software maintenance.

This article gives the definition, the components of a legacy system, the problems, the assessment method and the four strategies, in the order a full answer should use. The unit notes and solved past questions are on the Software Evolution notes page.

Definition

A legacy system is an old software system that is still in use and still important to the business, but that was built with technologies, languages or design approaches that are now obsolete, and that is difficult and expensive to change. The term does not mean "useless". A legacy system is usually the opposite: it runs a core business process so well, or so inextricably, that nobody dares replace it.

Typical examples are a bank's account-processing system written in COBOL in the 1980s, a government records system built on a discontinued database, or a university's examination system that only runs on a specific server version.

Why legacy systems are kept

Organisations keep legacy systems for sensible reasons, and a good answer states them:

• Replacement is expensive and risky. The cost of a full rewrite is large, and new systems often fail to deliver all the behaviour of the old one.
• The business rules are embedded in the code. Years of changes mean the system is the only complete specification of how the organisation actually works, and the original documentation is missing or out of date.
• The system is stable. It has been tested by years of real use, and users trust it.
• Replacement disrupts operations. Migrating data, retraining staff and running two systems in parallel all carry risk.

Components of a legacy system

A legacy system is not just old code. Sommerville describes it as a socio-technical system with several layers, and examiners like this diagram-in-words:

A change at any layer tends to force changes at the others, which is the root of the difficulty.

Problems of legacy systems

1. Obsolete technology. The hardware, operating system or language may be unsupported, with no vendor fixes and few people who know it.
2. Poor documentation. The design records are missing or no longer match the code after years of maintenance.
3. Degraded structure. Repeated patches have eroded the original design, so a change in one place has unexpected effects elsewhere.
4. Lack of skilled staff. Programmers who know the original technology are retiring, and new graduates are not trained in it.
5. High maintenance cost. Each change is slow and risky, and testing requires special environments.
6. Integration difficulty. The system cannot easily exchange data with modern web, mobile or cloud services.
7. Data problems. Data is stored in old formats, with inconsistencies that accumulated over decades, and migration is itself a project.
8. Security exposure. Old platforms do not receive security updates and were designed before modern threats existed.

Assessing a legacy system

Before deciding what to do, the organisation assesses the system on two axes: business value and system quality.

Business value asks how much the organisation depends on the system: who uses it, how often, how critical the business process is, what would happen if it stopped, and how much data it holds that cannot be regenerated.

System quality combines technical quality and business process quality. Technical quality looks at the number of change requests, the maintenance cost per change, the test coverage, the documentation, the age of hardware and support software, and the availability of people who understand the code. Business process quality asks whether the processes the system supports are themselves still good, or whether they only exist because the system forces them.

The two measurements are plotted against each other, and the position of the system suggests the strategy.

The four strategies

For the high-value, low-quality case, the usual choices are:

• Software re-engineering: improve the structure and understandability of the existing system without changing its functionality. Techniques include source code translation to a modern language, reverse engineering to recover the design, program structure improvement, modularisation, and data re-engineering to clean and migrate the data. Re-engineering is cheaper and lower risk than replacement because the behaviour is already known and the existing system keeps running during the work.
• System replacement: build or buy a new system and migrate. This is chosen when the technology is so old that re-engineering is not practical, when the business process itself must change, or when a suitable off-the-shelf system exists.
• Wrapping: leave the legacy system in place but put a modern interface around it, such as a web service layer, so that new applications can use it. This is a short to medium term option that buys time.

Migration approaches

If replacement is chosen, the migration can be done in several ways, and a 10-mark answer gains from naming them.

• Big bang: switch off the old system and switch on the new one on a single date. Simple to plan, but any failure affects the whole business at once.
• Phased or incremental migration: replace the system one module or one business function at a time, with the old and new parts communicating through interfaces. Lower risk, but the integration work during the transition is complex.
• Parallel running: run both systems for a period and compare the outputs before retiring the old one. The safest approach for data integrity and the most expensive in staff time.
• Data migration: whichever approach is chosen, the data must be extracted from the old formats, cleaned, transformed and loaded into the new system, and verified. Data migration is routinely the part that takes longest.

Model answer outline

For a 10-mark question on legacy systems:

1. Definition with one concrete example (two sentences).
2. Why organisations keep them (three or four points).
3. Components of a legacy system (the table or a labelled list).
4. Problems (six to eight points, each one line).
5. Assessment on business value and system quality, with the four-cell strategy table.
6. Re-engineering versus replacement, with the migration approaches in two or three lines.

For a 5-mark question, write points 1, 4 and 5 only.

Related topics

Legacy systems belong to the wider topic of software evolution, which also covers Lehman's laws, the maintenance types (corrective, adaptive, perfective and preventive) and the evolution process. Those sit in the same unit of CSC375 Software Engineering. BIT students find the equivalent material in BIT302 Software Engineering. Software re-engineering as a process of its own, with the reverse engineering and restructuring stages, is a separate 5-mark favourite and worth preparing together with this one.