Challenges when replacing legacy IT systems
A field report on the replacement of a legacy IT system with observations beyond the technology
A customer was faced with a major challenge: for 20 years, it had been operating a client system that managed 10,000 clients and countless transactions for these clients. The clients’ respective connections to the system were mapped via a managed VPN with MPLS routing. The licensing of the system was based on the number of CPUs used, with the number of accesses per CPU being limited, which of course increased the number of CPUs. At the point of system design, this was probably a good idea to ensure access quality even under load; nowadays, such an architecture leads to 100 servers getting bored in complete underload due to improved CPU performance. In short: an outdated system with exorbitant licence costs and considerable hardware costs.
This is where we came in. The customer asked us whether it would be possible to replace the legacy IT system with an in-house development with manageable costs and extended options.
Technical alternative. Or from 100 to 3.
Within six weeks, we analysed the application and the system landscape. We were in regular dialogue with various specialists at the customer and shared our interim results with the stakeholders every fortnight.
In the end, we presented the following solution: the 100 servers of the legacy system could be replaced by 3. The Managed VPN with the MPLS component was a completely oversized solution from a security point of view, so that considerable simplifications could be realised. Licence costs were completely eliminated.
The whole thing was linked to a multi-stage development and migration plan with various exit scenarios following a proof of concept for the most critical paths, a minimum viable product phase in parallel operation and a subsequent successive migration.
We had designed it in such a way that individual clients could have been migrated to the new platform (saving licence and server costs) and still remain visible in the legacy application as usual. In addition, we presented numerous ideas as to which new service offerings could be implemented in a streamlined manner on the basis of the new platform. We estimated the total investment at twice the annual licence and hardware costs. The stakeholders seemed enthusiastic.
Observations beyond the technology
In addition to the technical alternative, we also shared our observations beyond the technology with the client.
In the course of developing the concept, we conducted numerous interviews with the employees who were responsible for the platform in all its facets – from the local connection and server operation to the management of the customer interface – on a daily basis. These employees were spread across three different departments, whose managers acted as stakeholders.
In the conversations, we experienced a wide range of sentiments: from sincere curiosity about what modern technology could enable, to hostile rejection and outright refusal to share information. We carefully reflected these reactions back to the stakeholders in order to at least ensure the operational provision of information.
At stakeholder level, too, it was noticeable that the enthusiasm shown was more the result of the need to fulfil political expectations than of genuine conviction.
Shortly before our final concept presentation, the situation escalated. The occasion was an innovation workshop that we had scheduled with a large number of employees to discuss new use cases for the platform to improve the customer experience.
We were met with total refusal, led by a spokesperson from the customer who stated right at the beginning that the platform could already do everything it needed to and that the next official release would fulfil all further requests. So why waste their time? With a lot of moderation, we managed to salvage the event to some extent. However, the results were poor, so we ultimately had to use our own creativity to develop expansion options for the platform.
“The major problems of our work are not so much technological as sociological in nature.” – To DeMarco¹
The behaviour of the employees seemed all too understandable to us. Over 20 employees in various roles were involved in the platform operation, many of them since the launch of the platform:
- The employees felt pride in what they had achieved over the past few years. They were familiar with the legacy system down to the smallest detail and it was closely linked to shared team experiences. They rightly claimed absolute expertise.
- All processes and roles were well-rehearsed, everyone knew what they stood for. There was no culture of learning, because learning would have implied change. And change was not desired, as it was seen as a risk to the most important parameter, operational stability.
Against this backdrop, our proposal was disruptive. It called everything into question: their expertise, the procedures and processes, their social integration, their past, their technical beliefs and, in the worst case, even their jobs.
Even though we sought discussion when we presented our findings, it was not clear whether the stakeholders really recognised the implications of the situation. It seemed as if they saw themselves as victims and were therefore unable to support their employees in the process and provide them with the necessary psychological security.
We urgently recommended that all further steps should also be accompanied on an interpersonal level as part of a conscious transformation process.
Change support for the replacement of legacy IT systems
What is very clear from this example is something we encounter time and again. There are many reasons for overhauling legacy systems:
- The familiarisation period for new employees is too long,
- the systems are no longer secure
- the licence costs are too high,
- further development is no longer possible,
- the necessary hardware is getting old and expensive,
- technical experts for the technologies used are dying out.
The list is long and not exhaustive.
Whatever the reason, a lot is demanded of the employees involved. They have to leave their familiar paths, learn new things and, in the worst case, do so in an environment that does not even give them the certainty that there is still a place for them in the changed world. What managers perceive as a “blockade” is as human as it is understandable in the organisational context.
The uncertainties that these frictions bring to the company jeopardise the success of efforts to replace legacy systems, which are often only driven by technical considerations. It is therefore advisable to implement conscious change support for employees and managers alongside the technical IT project, taking into account at least the following aspects:
Establishing an organisational vision
Early on in the process, a picture must be developed of the implications of replacing the system at role, team and process level. Even if the legacy system performs exactly the same as the new one, there will almost inevitably be changes, as our example shows. However, new systems often offer the opportunity to implement genuinely new, improved processes – and this opportunity should be utilised and supported accordingly.
Managers as allies
Managers in particular need to understand which process changes affect their areas, how interfaces are shifting and that they need to help shape this process. To this end, it is necessary for managers themselves to develop an early understanding of their future role. Only from their own position of security are they in a position to convey security and make a meaningful contribution to the change process.
Recognising and supporting the need for change
Personal needs for change that are required by the new environment must be recognised and supported at an early stage. Employees must be given the opportunity to continue to take on an expert role in the future, albeit a different one. This process requires the kind of individual, personal leadership that we unfortunately see far too rarely in regular organisations.
Recognising and discussing contradictions
It is often the case that the aim of replacing legacy applications is also to reduce staff. Guiding people to make their own jobs redundant in their usual form is only successful if the recognisable contradiction is identified and future options for action are worked out together. The biggest mistake managers make is to believe that they can cover up the obvious with a cloak of silence.
We recognise that it is almost always about more than just a “change”. When replacing legacy systems, we are confronted with a transformation. The difference is that it is about more change than just a superficial reorganisation of processes and procedures. Rather, the implicit assumptions, principles, values and beliefs of the people in the organisation are also affected.
Once this is understood, one might think that professional transformation support is all that is needed. The old system is replaced, the new one is in place, processes and workflows are recalibrated and people settle into the new environment. But unfortunately, our world no longer works that simply.
Stabilising the change
In fact, we are increasingly recognising that applications can no longer “age”. Twenty years ago, it was still conceivable to specify, develop and implement a system and then – in extreme cases – operate it to this day (as in the example above). For a long time, such an approach seemed more like sensible investment protection than strategic nonsense.
Today, the pendulum is swinging in the direction of strategic nonsense. Information technology is already the basis of almost all business models. Shutting oneself off from its rapid further development is tantamount to a death sentence, even if death comes only gradually.
The renewal of legacy systems is therefore actually about two challenges: It is not just about the replacement itself, but at the same time about creating the parameters to ensure that the new system does not quickly become the legacy system again.
The associated change requirements go far beyond simply replacing the legacy system. Rather, the organisational conditions must be created so that the organisation can perpetuate the change process that was initiated with the replacement of the legacy system. Unfortunately, this stabilisation did not take place in our project. We were able to implement the proof of concept with a significant delay, but for reasons of corporate policy, the project was then transferred internally to other hands and ultimately cancelled, much to the dismay of our stakeholders. The platform is still running today…
Notes:
Please get in touch with Dr Stefan Barth if you want to talk to him about technology-driven change or if you need specific support. Stefan Barth is easy to reach on LinkedIn.
[1] DeMarco, Tom; Lister, Timothy, “Peopleware – Productive Projects and Teams”, 3rd Edition, Addison Wesley, 2013
If you like the article or would like to discuss it, please feel free to share it in your network.
Dr Stefan Barth has published two more articles in the t2informatik Blog:
The desire of managers to create
Away with the budgets
Dr. Stefan Barth
Dr Stefan Barth is COO of Qvest Digital AG and is driving the agile transformation of the organisation. Previously, he worked as a consultant, start-up co-founder, member of the management board of a TecDAX company and sole proprietor. Initially coming from the world of classic leadership, he changed his attitude and gained experience in agile transformation processes and the management of agile organisations through various mandates. He shares his expertise in consulting projects, lectures and articles.