Often introduced decades ago, so-called “legacy systems” often become an impediment for the company over time. Once considered “state-of-the-art” for the task to be accomplished, today that is no longer the case. A lot has changed with regard to the technology used since the old system was implemented. 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.
Replacing a legacy system – a suitable migration strategy, flexible with EASY ApiOmat
Of course, we also use EASY ApiOmat for phases 1 and 2 of projects to replace legacy systems. We’ll usually then concentrate on one to two prioritized business processes and then move on to phase 3. This approach ensures that business processes can be reviewed again with the client – always asking the questions of which processes are absolutely necessary and which processes are no longer required or should be changed. Together with the client in question, we can then start to implement the business processes from the front end. Thanks to the EASY ApiOmat Platform, we can start working on the front end at the same time as back end development. Not using data from real processes, but from data based on them. The benefit is that this way we can get user feedback quickly: resulting changes, bug fixes and wishes are reimported again and again. That way we get front ends with “UX appeal”, and front ends the way the users actually want them.
At this point, we’re still in between phases 3 and 4. Meanwhile, back end connections and the rest of the processes are implemented repetitively. This enables to implement the new solution while the legacy system is being replaced and alongside the existing system. That means we’re able to input the feedback from the users during development. A selection of users can use the new platform for the successive processes already implemented – that way we can receive feedback and reactions over a long period. The complete transition from the legacy system to the new one takes place during phase 5 – following the completion of the development work, detailed tests and, finally, successful UX/UI approval.