Skip to Main Content

A Proven Framework For Legacy Modernisation


The IT professionals who entered the industry couple of decades ago are proud about their legacy. Systems they developed, when there was no Google or Stack Overflow, are still standing strong, to date as giant pillars, even in some of the fortune 500 companies. As great the pride is, there will be a time, organisations need to consider the continuity of these systems built decades ago. As the technology advances, challenging customer requirements emerges, organisations need to consider introducing new systems, or upgrade the existing systems.

A Proven Framework For Legacy Modernisation

The framework explained in this article will help the organisations, at this crucial juncture to make a conscious decision on their legacy systems.

Part 1: Making the decision

The first part of the framework is to determine whether the system is absolutely a legacy and what options we have. Organisations can use the following “Legacy Replacement Quadrant” to analyse all their legacy systems.

Effort-Cost in a legacy modernisation system

The four quadrants in the above framework should be analysed against the two impacting dimensions, cost and effort. Each functional and non-functional requirements are considered using the framework. These requirements can be unique to the organisation and to the system that needs to be replaced or modernised.

Example for the Legacy Replacement Quadrant

Let’s take an example for using this quadrant. Imagine your organisation runs a system that was developed 20 years ago. this system handles the company payroll. your organisation has now grown with thousands of employees and the HR department has many users who need access to different functions of the payroll system. the payroll system does not have the capability of role-based authentication. Therefore, every user has access to each functionality of the system. You are now at a critical juncture, that you need to enable role base access to the payroll system.

Would you consider building this functionality in your legacy system or completely replace the old payroll system and introduce a new one? Or would you consider a middle ground approach? The legacy replacement quadrant will help you to answer these questions.

If you determine that this requirement falls under the leftmost bottom quadrant with the lowest cost and the lowest effort, replacing the old payroll system with a new one, might make sense. However, there could be other functionalities you may need to analyse together with it before making this decision.

You may explore the possibility of changing the existing payroll system, but it might take quite a lot of effort. Luckily you might still have the developers who originally developed the payroll system and since the users are already familiar with the system cost of adoption will be less. this scenario falls under the leftmost top quadrant.

Another possibility is replacing the legacy payroll with the new system that is very expensive and takes a massive effort to implement. It could be a part of enterprise-wide ERP implementation. This scenario is represented the rightmost top quadrant.

The last scenario to consider is that you decide to keep the legacy system by paying a thumping amount to bring in the role-based authentication functionality. You may have to contract an external development company who provides this legacy technology. The good news is it can be done very quickly. This possibility is represented in the rightmost bottom quadrant.

There is a circle in the middle that intersects all four quadrants. This is the modernisation circle. During the analysis, if you find more factors that are likely to be placed within this circle, you can decide to modernise your legacy system. if majority of the factors are placed out of the middle circle, and concentrated in a specific quadrant, that may give you a better indication for your decision.

Below, is an analysis done for our hypothetical use case of the legacy payroll system replacement.

Legacy modernisation payroll system replacement.

As we can see, some of the crucial requirements fall within the modernisation circle. This allows us to move into the next step to determine how we modernise this system.

Part 2: The legacy modernisation approach

This is where you deep dive into modernisation. based on the analysis done, we now know this modernisation should be achieved using a new identity and access management solution together with a moderate modification to the existing legacy system. You can list down the technical approach to this as in the below table.


Selected approach

Select technology

Need two factor authentication for the user login

Introduce an IAM solution

WSO2 IAM, KeyCloak

Need OAuth 2.0 and OpenID Connect based authentication

Introduce an IAM solution

WSO2 IAM, KeyCloak

Allow self-signup for users

Introduce an IAM solution and integrate into account creation of the legacy payroll systems

WSO2 IAM, KeyCloak, legacy integration

Allow role-based access control

Legacy system must be modified by breaking the modules allowing the users to have independent access to them. Then, the user roles defined in the IAM solution should be mapped back to these separated modules

WSO2 IAM, KeyCloak, legacy integration

Above scenario depicts a very common legacy modernisation use case:

  • There is always a new system or a system component that is introduced with modern functionality.
  • The legacy system would go into a slight modification to facilitate the connection for the new system.
  • Integration between the old and the new system is the key here.

By the time we finish the above exercise, we would have already identified the technical approach and the technologies that we will be using. At this point, we need to determine how is the integration done between the two systems.

 Part 3: Integration between new and legacy systems

In most common cases, communication with the legacy system is done using a flat file with an EDI approach, remote procedure call (RPC) interface or, directly reading and writing the legacy database. The modern applications on the other hand, provides a RESTful API for communication. An integration layer should be implemented in between.

Integration new and legacy system

As elaborated in the above diagram, the integration layer in the middle talks to the legacy system database, RPC interface, or read/write EDI file, with the information received from the IAM solution.On the other hand, legacy system can talk to the IAM system using the REST API through the integration layer. The selected integration technology should be capable of transforming and translating the messages coming from each system to a protocol understood by each system. The system uses are not aware about an integration layer. They would use the legacy system, business as usual together with the new functionality introduced by the IAM solution.


In conclusion, we have now successfully modernised our legacy payroll system. As a part of the solution, users can now sign up themselves using the new IAM system. With the help of our integration layer, their account will be automatically created in the legacy payroll system. The other side of the coin is that users logging into the legacy payroll system will be looked up for the permissions granted to them in the new IAM system. Depending on the permission token received, the integration layer will display the required modules in the legacy system to the user.

It is imperative, we follow a framework as such, first to make the decision of modernisation, and then determined the modernisation architecture. During this process it is also important constantly validate the cost benefit analysis is achieved.

At Chakray, it is our daily job to investigate modernisation problems and provide, integration-driven, cost-effective solutions. if your organisation, is in the process of validating your existing legacy systems, reach out to us. We are certain we can guide you with the best solution.