June 29, 2021

The ABC's of modernizing a legacy system

Modernizing a legacy system can feel like an overwhelming project. But don’t worry, after reading this article you’ll have a clear direction to head in.

The ABCs of modernizing a legacy system

Modernizing a legacy system can feel like an overwhelming and perhaps even impossible project. It can be difficult to predict costs with certainty, and starting the project may feel like a challenge: Where do you even begin?

If this all sounds familiar, don’t worry. Even these projects can be handled with style, and after reading this article you’ll have a clear direction to head in.

In this article, our senior developer Jan Ruusuvuori explains how to start a modernization project. Jan certainly knows what he’s talking about; he has been building, disassembling and modernizing legacy systems for work since 1995.

What we talk about when we talk about legacy systems?

What actually is a legacy system? Unofficially, the term was first used in the 1970s, but there is no official definition for the term.

“A legacy system usually refers to a system or software that has ended up in an undesired state over time. It may have become challenging to develop or have no responsible owner. And this doesn’t always apply to software; sometimes the problem is hardware that can no longer be updated or for which no spare parts are available. In some contexts, legacy is also used to mean untested code, but that’s a very narrow definition,”

Simply put, the term “legacy” refers to a system that you are stuck with in some way. Either you can’t make any progress with it at all, or doing so would be very expensive with an unreasonable cost-benefit ratio.

How should you start a modernization project?

1. Determine the core and value of the system that requires modernizing

The first stage is to consider the advantages provided by the system and who the system serves. You should also consider the following questions: What are the system’s external features (features that are visible to the user), and must they remain unchanged? What other things must absolutely be kept? And above all, what are the system’s future development needs, and what is the desired state of the system?

Unnecessary functions are a feature of most legacy systems. These functions were developed as part of the systems over the years, but no-one remembered or had time to delete them. It’s worth thinking what functions you will actually need in the future.

The first phase can be thought of as a conceptualization phase: If the development team were given completely free rein, what kind of system would it build?

2. Map the data stores of the system that you want to modernize

The aim of the second phase is to map where all of the data is. What data is stored in the service, and how? Is the data still useful, and do we need it? Do we need to modernize data models?

3. Specify integrations for the system you want to modernize

The third phase charts other external systems, data models and their connections that impact the system you want to modernize: What data does the system retrieve from other systems, and what state are these integrations in? What interfaces does the service require in order to function correctly, and which integrations are unnecessary? What resources will we need to maintain these external systems?

4. Reorganize the blocks

Once you’ve carefully thought about the three aforementioned points, you can begin to disassemble the system into suitable building blocks.

By following this order of work, you’ll be able to see the system boundaries, where to build interfaces, and how the smallest components are built. This means that you can build the new system in the best possible way to serve your organization’s needs.

But is modernization of any use?

“Disassembling and modernizing a legacy system should be thought of as refactoring the system’s architecture. It allows you to divide the system into smaller pieces which are easier to manage, and this in turn makes it possible to update and scale the system in a more agile way,” Jan explains.

According to Jan, modernizing a legacy system - that is, dividing it into smaller pieces - is comparable to replacing a broken pipe in a house. “Think about how difficult it would be to repair that one pipe by replacing all of the plumbing in a house at once. But if you could separate different parts of the plumbing, it will be much easier to deal with one part at a time.”

There are also pure business advantages to modernizing a legacy system: a system that is divided into several parts is simply easier and quicker to modernize and maintain. This is clearly visible in development costs.