Maintaining Legacy Applications

Maintaining a legacy application becomes more and more challenging as time goes by. Some reasons for this could be:

1. Losing resources that were there from the beginning and who knew the system inside out;
2. The application was built on outdated and / or obsolete libraries and frameworks;
3. Lack of code coverage.

People resign and it becomes a challenge to find suitable replacements when trying to recruit new developers to maintain a legacy application. Even more so when a legacy system is based on an obsolete framework or running on libraries which are not maintained anymore. Younger developers build their knowledge on the latest technologies that are currently in demand and rightfully so.

It may be a question on how to apply the knowledge of the new generation developer to help the rebirth of an ancient application. (Most will probably run away screaming when hearing the word LEGACY!)

What if both the interests of the company and the developer can be satisfied – if the interests and skills of new recruits can be used to assist in evolving the system using new technology? In exchange this will help grow their knowledge on architecture, system design, business knowledge and how that is (was) transformed into program design and implementation.

As far as the business goes, there will always be certain obligations towards a client that a company have to maintain:

1. Continuous production support of the application;
2. Maintenance of the application;
3. Resolving bugs;
4. Improvement of the user experience;
5. Implementation of new requirements;
6. Adherance to changes in legislation;
7. … etc.

All these are valid reasons as to why it can be difficult to refactor the existing code without disrupting the status quo. There may be even more reasons to why this can be challenging, such as:

1. People’s resistance to change;
2. Clients’ investments in such systems over the years,

to name but a few.

Attempting to renew the application while production support continues without interruptions, is the same as peeling away the layers of an onion. This sounds like the StranglerApplication by Martin Fowler. I think more of it as something between StranglerApplication and Backends for Frontends.

Below is a picture of a very simple representation of the legacy application on the right and a bridging layer on the left. It just so happens that this legacy application has a lot of history. In this case it was migrated off the mainframe, rewritten in some or other framework and was later migrated again to Java 1.4. Now may be the right time to take a step back and rethink and redesign the API.


In my example of how to address this in practice, I will take a top-down approach of completely rewriting the UI and build on the new enterprise API which will communicate with the legacy application. Firstly, I am hoping to minimise the impact on production and continuous delivery of the system to the clients. Secondly, once the new UI is delivered we will be able to gradually migrate the old services on the right over to the left in a StranglerApplication way.

(To be continued …)

In my next post I will give a code examples of a simple legacy implementation and explain why it needs a new API. Then start to progressively renewing the system by introducing a new UI layer and work my way down until we have the final product.

Jannie Louwrens is a Technical Team Lead at OPENCOLLAB.


Some advertising for @sakaiproject and @tsugiproject at #ela18 in Rwanda at the end of September!…

Last week



Belvedere Office Park, Bella Rosa Street,
Rosenpark, Bellville, South Africa
Phone: +27 21 970 4000
Fax: +27 21 914 3098
Qmuzik building,
cnr of Leonie and Von Willich Streets
Doringkloof, Centurion, South Africa
Phone: +27 12 640 3517