What are Legacy Systems? Why is Upgrading those Systems Required?

Upgrading means more than just making practical improvements to keep things running smoothly. It addresses immediate needs rather than chasing a perfect but impractical solution. The situation could spiral out of control if things don’t function properly in real-time.

One such incident happened on January 4, 2024, when South Africa’s Department of Home Affairs was taken offline nationwide due to a mainframe failure. In simple terms, Mainframe failures in such contexts are usually high-stakes issues because they impact the core infrastructure that supports vital public services. In South Africa, where the Department of Home Affairs handles a range of essential services such as passports, identity documents, and immigration control,  A mainframe failure can have widespread repercussions, leading to backlogs, delays, and potential administrative chaos. The South African Department of Home Affairs provides a clear example of a critical legacy system facing significant risks due to its outdated technology and operational challenges. 

Addressing these issues through modernization and digital transformation is crucial for improving service delivery and ensuring the system’s continued effectiveness and security. One cannot work on migrating the legacy system in one go, as the business and functional side of testing is a must. A planned and systematic approach is needed while upgrading the legacy system.

Question: What is the solution to avoid such a case?
Answer: Modernization of Legacy code.

Legacy code modernization is improving and updating outdated software systems to make them more maintainable, scalable, and compatible with modern technologies. Let’s understand this using Apigee (an API Management tool).

1. Scalability

Legacy system: Legacy systems were designed to provide solutions for the respected tasks but there was no scalability as records used to get limited within Infrastructure for improvements in business.
Apigee: Due to its easy scalability, centralized monitoring, and integration capabilities, Apigee helped the organization plan its approach to business improvements.

2. Security

Legacy system: One of the simplest methods for authenticating users in Legacy Systems was “Basic Authentication,” where the client sends a username and password in every HTTP request. This method was Vulnerable to man-in-the-middle (MITM) attacks if not combined with HTTPS. Credentials are exposed on each request.

Apigee: Using Apigee, the organization can quickly implement modern security features like OAuth, API key validation, rate limiting, and threat protection (e.g., bot detection) without changing the core logic of the APIs.

3. User and Developer Experience

Legacy system: The legacy API lacks good documentation, making it harder for external developers to integrate with it. Most systems tend to have a SOAP-based communication format.
Apigee: Apigee provides a built-in API portal, automatic API documentation, and testing tools, improving the overall developer experience and adoption of the APIs so that integration with other tools can be easy and seamless with modern standards.

There are now multiple ways to migrate data from legacy to modern systems, which are listed below.

1. Big Bang Migration
2. Phased Migration
3. Parallel Migration
4. Pilot Migration
5. Hybrid Migration
and more…

Although these things are known to the legacy system owners, they are very selective and picky when finalizing a migration plan. They are only aware of the short-term goal, i.e., to get the code up and running in production. Because when we are speaking of legacy systems, all there is left is code and a sigh of relief that it is still up and running.  For most systems, there is no documentation, code history, revisions, etc., and that’s why it could fail on a large scale if something goes wrong.

I have found some points that need to be ensured before finalizing the process of migrating from legacy systems to modern systems.

1. Research and Analysis

We need to understand the motives behind the development of the Legacy system since there is no or insufficient documentation.

In the study, we can plan to gather historical data to understand the system’s behavior. We need to dig deeper to find something that could help us understand the system better.

2. Team Management

After studying the system, we can estimate the team size and resource management. Such systems are way older when it comes to the tech on which they are running. So, it is hard to gather resources with such outdated skills. In that case, management can cross-skill existing resources into such technologies.

I believe adding the respective numbers of junior engineers would be best, as they would get exposure to challenges, which can help them improve their skills.

3. Tool to Capture Raw Logs

Analyzing the raw logs can talk more about the system, as this is the way communication is happening to complete each task requested by the system. By breaking down the data into layman’s language, understanding at what time requests are high by timestamps,

What parameter data consists of, and by such information, we can tell system behavior and plan properly.

4. Presentation of the Logs

Sometimes we may need to present the case study to high-level management before proceeding with the plan. So to simplify the presentation, we can use tools like Datadog and Splunk to get data in a format such as tabular, graphic, etc. so that other team members can understand.

5. Replicate the Architect with Proper Functionality

This is the most important part. End-to-end development is the only solution for smooth migration activity. We need to ensure standards here, such as maintaining core functionality, risk management, conveying data pattern changes to other associated clients, and ensuring user access, business processes, etc. The point 1 study can help us understand the behavior of systems to check on what modern tech we can land our migration on.

We can implement and plan using one of the migration methods I mentioned above in the blog.

6. End-to-end Testing

Once the legacy system is replicated to Modern Tech, we need to ensure that we have a User Acceptance Testing (UAT) environment to perform the system testing. It could be challenging if the respective legacy systems didn’t have a testing environment back in the day. We may need to call mock backend URLs to mock the behavior of services.

7. Before Moving to Production, do Pre-production Testing Properly

Only after successful UAT testing one can ensure the functionality and may think to move changes to production hassle-free. However, some points must be ensured, such as following standards and maintaining documentation. In standards, we need to ensure that no risk may lead to the failure of services in modern technology and that they are compatible properly.

In the documentation, we need to ensure that all service flows are appropriately documented and that testing is done according to the requirement gathering.

Legacy systems and their workings are among the most complex and time-consuming topics. But to make the job easier, one must put effort into it.

Did you ever feel tense while taking your exams? Or you must have watched the Olympics or other sports events like cricket, football, etc. When you focus on national players during significant events, you can observe stress and anxiety in performing at that level. Similar is the situation of an IT professional during a production deployment call. This moment is crucial because it represents the end of months or years of effort, the results of which will be evaluated by those involved. The stakes are high because the quality and success of the deployment can have a huge impact.

Teams follow a multi-step process called the SDLC (Software Development Life Cycle) model to manage this stress and increase success. These standards provide a framework to guide process improvement, reduce risk, and streamline deployment. The team’s goal is to follow this process and deliver quality software that meets the needs of stakeholders.

Some of the major SDLC models are:

1. Waterfall Model
2. V-Model
3. Incremental Model
4. RAD Model
5. Iterative Model

Each SDLC model is suitable for a certain type of project. We can take the example of the Waterfall Model.

The SDLC Waterfall Model

1. Requirements Analysis: Gather and document what the system should do.
2. System Design: Outline the architecture and design specifications.
3. Implementation: Write and integrate the code according to the design.
4. Testing: Evaluate the system to ensure it meets the requirements.
5. Deployment: Release the system for end-users to use.
6. Maintenance: Address any issues or updates needed after deployment.

Structured approaches like SDLC emphasize planning, alignment, and risk management to ensure successful deployments. However, gaps can still lead to failures and negatively impact the client’s perception.

It is always a hassle when it comes to production deployment. It is simply your code for a service that will run as you developed it but in a different organization or environment. So, what’s the drill?

I can answer this by noting down some of the points I have understood from my IT experience.

1. Insufficient Requirement Gathering

Sometimes, demands are not appropriately explained in the documentation, stories, or any part of requirement gathering, but for some tasks, we just don’t have standards to track but understandings. If the process gets carried on, we may face delays in production planning or issues in production if deployed in such a case. Also, it can cause recurring problems in production.

For example, in one of the requirements meetings, we asked the client for the parameter’s details, but the client had no such information, which caused a delay in deployment.

2. Incorrect Dev/Sandbox Testing

Developers often test the service until a successful response and move it directly to production by getting approval. For TL/Manager, it is a win-win situation because service is delivered before the deadline until clients start playing Russian roulette.

Your (developers) poor approach is exposed now, and fixtures are happening live now in production. This affects the value of the business and the relationship with the client.

3. Inconsistency Between the Code in Lower Environment and Production

Most of the time, developers have to make changes to production services due to certain reasons, whether by team or client. At that time, it is necessary to have those changes tested in the Dev Organization/Environment first. Directly implementing those in production because of short-term liberty and approvals may do justice with the client and TL/Manager but not with your junior folks. They may not understand why code differences are there.

4. Improper or incomplete testing by the client

Note: This may be more for the production manager type of folks.

I have been through some of the developments and have reported the same behavior from some people that sometimes clients also rely on the developer in the testing part. The client knows the end-to-end project, and the developer is responsible for some part of it. So, the client side of testing is essential.

5. Pre-production testing

In most cases, the client doesn’t have test data for Pre-production to confirm the end-to-end working status of the service. This may cause failure of service. Always ask the client to do pre-production testing with real-time data and confirm the status of the service.

6. Load testing

Often, load testing is avoided when requirement gathering itself. It is necessary to have the service go through load testing so that if, at the production level, services start to receive more traffic than usual, we can trust the service’s capability to handle such cases.

That’s a wrap!

These gaps or processes need to be properly followed for a successful and hassle-free production deployment.

Perficient + Apigee

At Perficient, we create complex and robust integration solutions in Apigee, which helps our clients address the full spectrum of challenges with lasting solutions.

Contact us today to learn how we can help you to implement integration solutions with Apigee.