Replacing legacy IT systems

Intro

A few years ago, we came into contact with a customer who was facing the following challenge.

He was running a large application that managed over 10,000 clients in a central platform. The application itself was functionally quite sparse, but managed many transactions and collected considerable amounts of data. The respective connection of the clients to the central platform was mapped via a managed VPN, always encrypted, even for the data connections, which were coupled and managed in a dedicated MPLS network.

The system was old - over 20 years old. It had received regular updates, so security issues were not a priority. One or two feature enhancements had also crept in over the years.

The software used was licensed according to the number of CPUs used and the number of permitted client connections per CPU was strictly limited in the license model. At the time the system was designed, this was probably a good idea to ensure quality even under load ... nowadays, given the number of clients and the improved CPU performance, such an architecture resulted in over 100 servers humming away in complete underload.

Quite apart from the exorbitant (and constantly rising) license costs, hardware operation was also a considerable cost factor. Operating the client connections also put a considerable strain on the budget. Ultimately, there was also a desire to be able to develop the system itself in order not to lose touch with the market - which was impossible with the existing architecture simply because of the license commitment.

3 instead of 100

This is where we came into play. The customer asked us whether we could check whether it would be possible to replace the application with an in-house development at a manageable cost and subsequently with extended options.

Within six weeks, we analyzed the application and the system landscape. We were in regular contact with the customer's various specialists and shared our interim results with the stakeholders every two weeks.

As a result, we presented the following solution: the 100 servers could be replaced by 3 - if they still had to be on premise. The managed VPN, especially with the MPLS component, was a completely oversized solution from a security perspective, meaning that considerable simplifications could be implemented here. The license costs would be completely eliminated.

The whole thing was linked to a multi-stage development and migration plan with various exit scenarios following a proof of concept (PoC) for the most critical paths, a minimum viable product (MVP) 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 on license and server costs) and still be visible in the legacy application as usual. In addition, we presented numerous ideas as to which new service offerings could be implemented in a lightweight manner on the basis of the new platform. We estimated the total investment at twice the annual license and hardware costs. The stakeholders were apparently enthusiastic.

But we also shared observations that pointed to completely different challenges.

Many emotions

In the course of developing the concept, we conducted numerous interviews with employees who were involved in all aspects of the platform on a daily basis - from the local connection and server operation to the management of the customer interface. The employees concerned were spread across three different departments and the stakeholders were the respective department heads.

In the conversations, we sensed a spectrum of moods ranging from sincere curiosity about what modern technology could make possible to hostile rejection and a barely concealed refusal to share information. We carefully reflected this back to the stakeholders during the process, which at least ensured the provision of information at an operational level.

However, at stakeholder level too, it was sometimes clear that the approachability and quiet enthusiasm was driven more by the perceived need to meet a political expectation than by genuine conviction.

The situation escalated shortly before our final presentation of the concept, which was already largely known at this point. The reason for this was an innovation workshop that we had scheduled with a large number of employees, during which we wanted to discuss potential new use cases for the platform to improve the customer experience.

We were met with total refusal, driven by a spokesperson from the client who stated at the outset that the platform could already do everything it needed to and that the next official release would fulfill all further wishes. Why were we even wasting their time? With a great deal of moderate effort, we managed to save the event to some extent. Unsurprisingly, however, the results were very poor, so in the end we had to use our own creativity with regard to the platform's expansion options.

"The major problems of our work are not so much technological as sociological in nature." [1]

This behavior seemed all too natural to us. More than 20 employees were involved in the platform operation in a wide variety of roles, some of whom had been working in these roles for as long as the platform had existed.

The employees were proud of what they had achieved in recent years. They were familiar with the system down to the smallest detail, were unwaveringly linked to shared team experiences and justifiably 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 change was always seen as a risk to the most relevant parameter, operational stability.

Against this background of daily work and people's basic stability-oriented attitude, our proposal was disruptive. It called everything into question: their competence, the procedures and processes, their social integration, their past, their technical convictions and, in case of doubt, even their job.

Even though we sought discussion on this topic when we presented our findings, as previously indicated, it was not conclusively clear whether the stakeholders were really aware of the seriousness of this situation. It seemed to us that some of them saw themselves as victims and were not in a position to support their employees in the process and provide them with the necessary psychological security.

We made the urgent recommendation that all further steps should also be accompanied on an interpersonal level as part of a conscious transformation process.

Not an example, a pattern

What becomes very clear from this example is something we encounter again and again.

There are many reasons why old systems may be touched. The training period for new employees is too long, the systems are no longer secure, the license costs are too high, further development is no longer possible, the necessary hardware is getting on in years and is becoming absurdly expensive, technical experts for the technologies used are dying out ... the list is certainly not exhaustive.

Whatever the reasons may be, the employees involved are being asked to do a lot. They have to fundamentally 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 potentially perceive as a "blockade" is as human as it is understandable in the organizational context.

The frictions in the company that these uncertainties bring with them fundamentally jeopardize the success of efforts to replace legacy systems, which are often only driven by technical considerations. In addition to the technical/professional IT project, it is therefore advisable to implement very conscious change support for employees and managers that takes at least the following aspects into account:
 

Establishing an organizational 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 old system performs exactly the same as the new one, changes are almost inevitable, as our example shows. However, it is much more the case that new systems also bring with them the opportunity to implement genuinely new, improved processes - and this opportunity should not be missed, but used and supported accordingly.
 

Managers as allies

Managers in particular must understand which process changes affect their areas, how interfaces are shifting and that they must help shape this process and not oppose it. 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 will they be able to convey security themselves and make a meaningful contribution to the change process.
 

Recognize and support the need for change

Personal needs for change that are required by the new environment must be recognized 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 organizations.
 

Recognize and discuss paradoxes

It is often the case that the aim of replacing legacy applications is also to reduce staff. Guiding people to work towards making their own jobs superfluous in their usual form is only successful if the recognizable contradiction is identified and future options for action are worked out together. Managers make the biggest mistake when they believe they can cover up what is obvious to everyone with a cloak of silence.

We recognize that it is obviously almost always about more than just a "change". When replacing legacy systems, we are confronted with a transformation. The difference I see is that it is more than just a superficial redesign of processes and procedures. Rather, the implicit assumptions, principles, values and beliefs of the people in the organization 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 procedures are recalibrated and people settle into the new environment. But unfortunately, our world no longer works that "simply" ...
 

Stabilization of change

In fact, we are increasingly realizing that applications can no longer "grow old". Thirty years ago, it was still conceivable to specify, develop and set up a system and then - in extreme cases - operate it to this day (as in the example mentioned). For a long time, such an approach seemed like sensible investment protection rather than strategic nonsense.

These days, the pendulum is swinging in the direction of strategic nonsense. Information technology is already at the foundation of almost every business model. Sealing oneself off from the rapid further development of this technology is tantamount to a death sentence, even if death may only come gradually.

This means that the renewal of legacy systems actually poses two challenges: It is not only about the substitution itself, but also about creating the framework conditions to ensure that the new system does not quickly become a legacy system again.

The resulting change requirements are much greater than simply replacing the legacy system itself. Rather, the organizational prerequisites must be created to ensure that the organization can sustain the change process once it has been implemented to replace the legacy systems.

And this brings us to a point where we are actually talking about nothing other than agile transformation.

PS

... and what happened next with the consulting project? We implemented the PoC - with significant delays, but still. As far as we know, there was no transformation support. For reasons of Group policy, the project was then passed on internally to other hands and ultimately scrapped, much to the chagrin of our stakeholders. As far as we know, the platform is still running ...

Source reference

[1] DeMarco, Tom; Lister, Timothy, “Peopleware - Productive Projects and Teams”, 3rd Edition, Addison Wesley, 2013