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.
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.
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.
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.
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.
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
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.