Many organizations have them: old applications written in time immemorial, poorly documented, and with nonexistent tests. Yet, they’re still responsible for holding up key parts of the production environment, even if no one understands exactly how. Venturing into the code can feel like stepping over the threshold of a dragon’s lair: make one wrong step and suddenly your world is engulfed in flames. Legacy application modernization can seem daunting.

But sometimes it is necessary that we conduct development on our legacy applications, and this post will present some guidelines on how to get a handle on a legacy application modernization project and extract some value without burning the world down to get there.

Be Realistic With Legacy Application Modernization

There are no quick fixes for a task like this. An exercise in legacy application modernization is very likely to be a time- and effort-intensive process, so it’s important to be sure that it’s even worth it before you commit to all that time and effort.

Is there an active need to add features to the app, but it’s difficult or impossible to do so because the app’s architecture is antiquated or not well understood? Is the app causing production issues which are difficult to fix for the same reason? Is it running on a framework version that is End of Life and so no longer receiving updates? If the answer was yes for any of these questions, then refactoring the app is probably worth it. But, if none of these applied, then it may not be worth devoting a lot of time to fixing something that isn’t a problem right now.

Some of these steps might still be worth undertaking if there are free resources to pursue them. Especially if the app’s framework is almost at the end of its support.

Test Everything if Decided Legacy Application Modernization is Worth it

If the decision has been made that a process of legacy application modernization is worth it, the very first thing to do is write as many tests as possible. We want to be certain that as we pursue changes to the code in the later steps the functionality of the application isn’t regressing. The more detailed and specific these tests can be, the better, but it’s okay if you don’t understand the app well enough to write specific tests. Any tests are better than nothing, and indeed better tests are the end goal of many of the steps that will follow.

If it’s possible to get a Continuous Integration pipeline running for the application, this is also a great step and will help with catching any functional regression the moment that it gets introduced.

Divide & Conquer

When an application consists of large classes and big code files tightly coupled together, it can be hard to even comprehend, let alone to have any idea where the problems are. Breaking up classes and methods in accordance with the Single Responsibility Principle is a great first step on our road to legacy application modernization. Note that we’re not really touching the guts of the code yet. Our aim is mostly just to move the code around and into a form that’s easier to understand.

This will also have the added benefit of making it easier to write more detailed tests, since the functionality of the application has been broken into smaller classes and methods with well-defined responsibilities. Where possible, we should always seek to add better testing to the application as soon as we can.

Look for Patterns with Legacy Application Modernization

As the work of splitting up the project progresses, it’s likely we’ll start to see patterns emerging between and within the application’s components. These are great opportunities to remove code duplication and to simplify the project’s architecture. If we find a bunch of classes with similar jobs, we can consider unifying those bits of functionality inside an abstract base class.

This is also a great opportunity to impose interfaces between our components and move to a model of dependency injection where possible. Surprise, surprise, not only does this reduce the coupling between components of the system, but it again makes it easier to write more detailed and useful tests.

Be Brave, but Be Careful

The above steps are mostly architectural, seeking to reorganize the code into components which are easier to understand, easier to test, and easier to change without knock-on effects elsewhere. As mentioned above, the “guts” of the application can remain largely untouched through each of the above steps, but now is the time to maybe make those deeper changes. Now that we have robust tests and a clean code structure, we can think about reimplementing a key algorithm or data structure for increased performance or adding new features to the existing application.

All the preparatory work that got us to this point is extremely important, and I want to caution that it shouldn’t be overlooked. It can be tempting to attempt to solve the application’s particular problem in a piecemeal approach, either migrating the framework version wholesale or trying to dive into the one location that needs work at this moment.

If you’re lucky, you might be able to get away with that, but if not, you might find yourself mired in an incomprehensible mess, unable to make changes without breaking other key pieces of functionality. As mentioned at the top, there are no quick fixes here. If you want to do a legacy application modernization job right, you need to put in the time.

Thanks for reading! If you are looking to modernize your legacy applications, get in touch by filling out the form at the bottom of this page. Make sure to subscribe to our blog. We publish technology tips, tricks, and updates every week.  

Discover More