Replacing legacy systems

The market conditions and requirements also change rapidly at companies. Unfortunately, these old systems often manage processes critical to the company. Removing or even flexibly adapting old systems to the new conditions, meanwhile, becomes a special type of challenge.

In IT, the phrase legacy system indicates a comparatively old system which has since become established within the company. Within German companies, such systems may also be referred to as old systems. A legacy system often – but not necessarily – consists of a fixed combination of hardware and software, such as in the special case of room and floor-filling mainframe computers. Legacy systems are usually still being used successfully – true to the motto “never change a running system”. This becomes problematic above all when you consider the speed of development of technologies in the information and communication technology sector.

General properties of legacy systems

The following are considered commonly encountered properties of legacy systems. One thing first: some of these properties are simultaneously enormous hurdles during the project to wanting to replace the legacy system or enhance it with new functions.

• Integrated into the system infrastructure a long time ago
• Organically grown, in many cases the documentation for the legacy system’s functions and interfaces is poor
• The personnel originally responsible have long since left the company; the external service provider no longer exists
• Other external systems are often coupled to functions of the legacy system
• Legacy systems have high implementation costs and increasing maintenance costs
• The end-of-life cycle has already been exceeded by the manufacturer
• Legacy systems often have non-standardized interfaces
• The data exchange (within the company/externally) runs through these interfaces, often via proprietary formats

Depending on how pronounced the points just mentioned are in specific cases, a legacy system can become a really difficult legacy – an inheritance you really don’t want to accept. At the same time, these legacy systems usually complete their work in a reliable manner. The difficulties for legacy systems are also well-known – there are workarounds for routine tasks and corner cases. Unfortunately, however, market requirements cannot be met with the legacy system.

You can use the following three signs to check whether your legacy system is waiting to be replaced.

• Falling productivity: Productivity is among the KPIs (key performance indicators) for every company. Typically, even the smallest changes/adjustments to a legacy system entail a disproportionate level of organizational and administrative effort. That means small changes become extensive projects; deadlines and project runtimes cannot be kept to, etc. A legacy system is noticeable even in everyday working life. Newer business processes are often only possible by using “workarounds”. As these cases resolved by “workarounds” only appeared after the introduction of the system, users have created a real smorgasbord of how-tos, notices, documentation, process graphics, etc. over the course of time – unfortunately, these are scattered across many places in the company. The result being that no one individual has an overview of what thwarts daily work anymore.
• Insufficient flexibility: Many legacy systems have a monolithic design and can only be reached and used at one central location, the company’s headquarters. Mobile access regardless of location is not possible. This certainly represents a hurdle for modern users, especially those needing remote access – whether they’re working from home or whether they want to access company data while on a business trip.
• Conflict with user requirements and habits: What was considered state of the art with regard to user interfaces and user experience at the time the legacy software was introduced is subject to constant change. In addition, new functions may have been integrated into a legacy system in a sub-optimal way. In the present, this can lead to users not fully understanding legacy systems – the result being that they lose enormous amounts of time while searching for specific functions. Should this be the case, it is urgent that you give serious consideration to replacing your legacy system. Also consider employee motivation, which is negatively affected by obsolete legacy softwar

Taken into consideration together with the general properties of legacy systems (see above), legacy software gives the impression being complex, inflexible and difficult to maintain. Unfortunately, legacy systems provide great business value in many cases. If legacy systems were easy to adapt and expand to incorporate new functions, there would be no reason to consider replacing a legacy system. The opposite is the case. That means action is required.

Migration strategies – away from the legacy system

The five-phase approach according to Bisbal, Lawless, Richardson et al is still thought of as a universal, generic model for replacing a legacy system.

• Phase 1: Justification
• Phase 2: Understanding the legacy system
• Phase 3: Developing a target system
• Phase 4: Testing
• Phase 5: Migration

Obviously, phases 1 and 2 are the basic requirements for all the rest. It’s only once the reasons “why” are clear and once there is full understanding of the legacy system that the next steps can be taken. Concrete plans for a migration strategy and for replacing the legacy system can then follow. The migration strategy must always be planned with the specific case of the legacy system in mind. A one-size-fits-all strategy quite simply does not exist for all the differences in system architectures.