Legacy System Modernization

6 min readMar 18, 2021

What is Legacy System Modernization?

When you are a long time employee of a start-up or a tech company, you have probably already touched upon modernizing a legacy system without you explicitly knowing the term for it.

Basically what Legacy System Modernization means is upgrading / changing a big part of the current running system mostly on the architecture level down to the coding level, in order for the system to keep functioning like it is now and is able to handle the new work load / users on the system without having a big risk of shutting down.

A good example of red flags when you know its time to modernize is from a former start-up I used to work at. This was my first real job as a software engineer so I still had little experience in the field and didn’t really know what the best way was to tackle such problems… Now that I look back we could’ve done things a whole lot different with less complications. Let me explain.

When I joined the company we were with a total of 3 developers working on the platform. They were the more “Senior” so I was mostly learning from them and the practices they had picked up.

When I was working there for about a year I started to notice a lot of bad practices and bottle necks since I was also constantly learning in my free time. A couple of those bottle necks were:

Unclear and a lot of duplicate code on a lot of places
No documentation
No tests
Limits of server
Limits of database
No image optimizations (the company relied heavily on images)

Some of these bottle necks have a lot to do with careful project planning and using good programming principles. But the ones I wanted to touch on in this article are mainly the Limits of the server and Limits of the database.

These 2 are good examples of a legacy system that needs modernization in order to keep running the way it’s suppose to run. Because if we do not carefully plan this out and modernize it. It will have disastrous consequences

What are we going to talk about in this article?

Detect a need for modernization in your system
The smallest thing we can do
Edge cases
Coordinate

1) Detect a need for modernization in your system

When detecting a need for modernization its often times better to notice this before it actually becomes a problem for the users. The whole point of modernizing a legacy system is so that the users experience no flaws or degradations in their flow in the system.

One of the best ways to detect a need for modernization is to keep close attention to the monitoring services of your system (I hope you have those in place). These monitoring services will tell you:

How fast or slow certain parts of your system are
How they behave
What the current work-load on your external systems or services are

By keeping track of these metrics and comparing them with past times to see how they are changing over time. We can detect a need for modernization long before any users start to feel the consequences of our system hitting its limits.

Another way of detecting a need for modernization is internally by the engineers working on the system.

When changes to the code-base become hard to implement because we do not have the overview anymore as to what modules in the system a particular change affects or when the code becomes so complex we do not completely understand what it does anymore. It is time to start considering a change or a refactor of old modules

2) The smallest thing we can do

Let’s say we have detected a need for modernization in our database system. Currently our system runs on 1 database, but we are experiencing the limits of this database like hitting request rate limits and timeouts.

Before jumping into a solution, changing the database and all modules attached to it. Let’s think about this for a moment.

If we immediately start working on a solution and changing all modules that are attached to the current database we run into a couple of roadblocks.

We have to change every part of the whole system that is attached to the old database. Resulting in a major PR
We have a high risk of running into unforeseen bugs and errors
We have a high risk of the system crashing on users because of edge cases we did not see / discover

What we can do to omit most of these roadblocks is looking for the smallest possible way we can introduce this to our system and gradually moving forward in small steps instead major steps at a time.

We can for example connect the system to two databases instead of one. Only changing one model to use the new database. Making sure that it is working as expected while keeping the rest of the modules using the old database.

This makes sure the whole system keeps working like its suppose to work while also introducing a new database to the system.

Another pro of implementing everything in small steps is the ability to revert PRs. When we do everything in 1 major or several major PRs it is harder to revert them and let the system run in the old way.

I also wanted to touch a little on refactoring. Often with a new piece of technology in the system also comes new functionality. It might be tempting to start using these new technologies right away and start benefiting from them. But it’s probably better if you wait with that a little longer and just make sure the new technology behaves exactly or as close as possible to the old technology. This way the risk of something going wrong is less since we are basically mimicking the old ways of handling the data.

Later on when all the work in done and runs smoothly on the new technology. We can start implementing the new functionalities gradually and make it run even better!

3) Edge cases

To fall back on the database example. When we gradually start implementing these modules that work on the new database. We most likely also start to discover certain edge-cases and differences in the functionality of the new database opposed to the old database.

The plus side of us doing everything in small steps is that we start to discover those cases early on in the migration process.

Make sure that when working on a project like this to take a little more time going over certain edge-cases and functionality changes. This might seem like you are wasting your time at that moment. But I promise you that it will pay off in the end.

It’s better taking some time to tackle these things right now. Then to lose a lot of time and money fixing bugs and problems in the codebase that you did not foresee at that time.

4) Coordinate

When introducing a change like this in your system its very important to coordinate everything in a good way with your team and managers. Since almost all the tickets you will be working on will include breaking code changes.

These are a couple things you can do to let things run more smoothly

Keep everyone up to date with the progression you are making on your current ticket
When running into roadblocks, make sure to let your fellow engineers now
When you have question about a certain area of the project / ticket. Make sure to ask, instead of assuming things are suppose to be done a certain way
Make sure to lay out a roadmap of the whole project with their respected ETA to let others including your managers know how long this change is approximately gonna take

Remember big steps might seem good and effective, but they will set you up for a lot of unforeseen difficulties and roadblocks.

Conclusion

When modernizing a legacy system we have to make sure we get all the facts together as to what actually needs changing, how big the change is, what modules it affects, what edge cases can we run into, etc… When we have that on paper. We need to create a plan on how we can implement this in the smallest way possible with the smallest steps we can take.