What defines a legacy application? 

The answer is by no means obvious. The easiest criterion used by most engineers is the age of an IT system. Following this reasoning, we would put the legacy etiquette only on the applications developed long ago.

The practise shows that there are multiple “younger” systems that also fall into this category.

• Some of them were built in languages that are not supported anymore like Cobol. Because of that, no one fixes its bugs or security issues and they stay in your applications.
• Others have no living community around them. Consequently, it’s challenging to find developers to work with such applications. Systems built-in Python 2 are a good example of that.
• The same happens with applications built in over-hyped technologies with short lifecycles. Once the initial hype calms down, developers lose interest in them, and your organization is left alone with peculiar software nobody wants to work with (or even knows how to). That’s what happened with Elm.

All of the above may happen to you if you make rash technology decisions. When a business puts pressure on you to deliver your applications or new features faster, you may use the first technology that comes to your mind. Unfortunately, the first one may not be the best one.

No matter the cause, the effect is the same: legacy applications generate tremendous business problems, and CTOs should modernize them ASAP.

In this article, I explain what pains (not only technical ones) such systems may cause you, and what strategies you may use for your application modernization process. Let’s dive deep!

Biggest Issues of Legacy Applications

In IT, technologies change nearly as quickly as seasons. Every new year brings new versions—not to mention entirely new technologies—which is generally good as they offer more possibilities for developing our applications. It doesn’t mean that you should go crazy and switch to a new technology whenever it appears, but there comes a moment when such an upgrade is necessary.

Your system will eventually get outdated. The technology (or its version) used for developing it won’t be used that much anymore, and you’ll struggle to find developers for further work. The lack of proper specialists on the market and the exorbitant fees demanded by the ones available are the best sign that you should modernize your application. That’s the moment when you start calling it “legacy”.

We talked about the problem of modernizing legacy applications during our 5th CTO Roundtable.

Our guests representing the tech side of finance, business and industry explained why legacy applications are such a bother. They mentioned the following issues…

Technical Difficulties of Legacy Systems

The low comfort of working with legacy systems naturally makes your developers less engaged. It’s no fun for them to play with outdated technologies.

Legacy systems are hard to work with. When the technology you used for building your legacy software is not supported anymore, your engineers cannot work smoothly. They constantly stumble against small technical obstacles.

As a result, they either spend weeks trying to fix rare bugs or doing workarounds. What would take minimal or no time with modern technology, takes them hours with your application?

Also, a typical legacy technology offers limited possibilities. When working with modern technology, you enjoy new libraries and tutorials constantly coming in. Developers take their programming to new levels and build ever more complex applications. With legacy technology, that’s either impossible or at least difficult.

Legacy applications development is a slow process. Solving all of these small issues takes time, and the low number of existing legacy specialists doesn’t help either. You won’t be able to deliver a new functionality each sprint. Development processes will take time.

Lagging, Low-Performing Systems

When technology isn’t supported, nobody fixes its bugs, not to mention security issues. Unlike in modern technologies, no one takes care of your pull requests, and you end up alone with your problems (which is a huge personal cost). When working with such a technology, you constantly ask yourself why the heck you chose it for your system.

You may try to fix it yourself, but it may not be that easy.

If you have an aged technology in your stack, you most likely don’t have its creators onboard anymore. You have no idea who designed the application architecture or why they have chosen a given infrastructure. What you don’t know either are their motives: why they chose a given technology, what business risk they needed to take into account or how these strange pieces of code were meant to work. For you, it may be obvious that it should have been built in a modern cloud environment, but they probably adopted a different approach that excluded using the cloud for a reason.

Legacy systems may be difficult to understand, especially when written by multiple developers. It’s even worse if they have undocumented features (there comes a day when you have to pay for that, as Peter van Dijk from GOconnectIT said). You may end up with pieces of code acting like black boxes: something works, but no one knows how. Your developers are afraid of making changes for fear of destroying it completely, and the status quo is preserved.

As a  result, organizations afraid of code refactoring or any other application modernization processes keep using software with poor performance and bugs. When it’s a tool used internally, it’s semi-bad. Their business processes are ineffective, but they can live with that. But if their legacy application is sold externally… Let me say it, it’s a real disaster.

Digital products such as enterprise SaaS applications need to evolve together with their users. Every bug that stays there decreases user experience. Similarly, if you cannot add new functionality requested by users, they’ll probably jump to software that already has it.

Such systems are neither stable nor secure, no matter if they’re hosted in the cloud or elsewhere. Selling a digital product whose code you don’t understand is a great business risk. One day, it may stop working, and you won’t help it. That’s why the modernization of your IT system is so important.

Difficult, Long Recruitment Processes

Recruiting software specialists is generally difficult, but hiring legacy technologies experts is a real challenge.

When a technology used for building your systems gets outdated, developers don’t want to work with it anymore.

Primarily, because it’s difficult. Then, because it doesn’t pay off—they spend time on learning a legacy technology, but the demand for it is low. Finally, because it’s not interesting. Don’t underestimate this one: professional growth is a priority for them. They avoid engaging in projects that don’t develop them or at least give them some fun. Legacy development doesn’t fall into these categories.

Now, the willingness to work with legacy applications is one thing. The competencies necessary to build such a system are another one. The problem with legacy technologies, especially the aged ones, is that people don’t have the knowledge necessary to work with them. It’s usually passed within modern software development communities, but if there’s no community around a legacy technology, it gradually disappears. 

Due to that, you may be able to hire senior developers but definitely not juniors or interns. Depending on your HR strategy and budget, it may be an issue or not.

The result of all that is a low number of engineers specializing in legacy applications development. The cost of recruiting them as well as the time necessary to do it is already a good reason for starting your legacy systems modernization.

The Big Cost of Legacy Applications

Hiring legacy software developers is not only difficult but also expensive. To find them in the sea of Java, Python or Rust enthusiasts, you’ll probably need to rely on the support of an HR outsourcing agency. Your recruitment is bound to take plenty of time, which increases its cost. You’re also likely to end up hiring the most expensive engineers on the market. Pure economy: low supply triggers high cost.

Of course, recruitment processes are not the only cost to include in your business plan. You’ll also need to put salaries in your balance sheet. The economy works here again: the low number of legacy software specialists translates into astronomical salaries. Otherwise, what would motivate them to work with legacy systems?

Let me say it again: you won’t find interns nor juniors for legacy applications modernization projects. It’s quite likely that you won’t find regulars either.

Programming newbies don’t want to learn legacy technologies for the reasons mentioned before. Apart from that, the more outdated (= the older) a system, the older its specialists. These developers naturally have more years of experience, which already makes them senior.

Before You Modernize Legacy Application

Once you know what technical and business risk legacy systems pose to your business, it’s time to ask yourself the following question: which application modernization strategy should I go for?

You shouldn’t make any rash decisions here. Your modernization approach should be based on data, not intuition or advice from colleagues (your legacy developers will have their opinion too). There are several legacy application modernization strategies you can take, and to choose the best one for your business, you should take into account two major factors: the existing code and your business needs. You may use external consulting services for that to save time.

Modernization Due Diligence Step #1: State of Existing Code

Before you start your legacy application modernization, take one step back.

During our 5th CTO Roundtable, Peter van Dijk from GOconnectIT strongly advised us to “freeze everything” and focus on analyzing the current code. As he put it, “you need to be sure what you’re improving”.

Once you identify the issues of your legacy applications, visualize them. A clear roadmap for your application modernization will be a great support when you’ll be choosing the right modernization approach. Remember that you won’t be fixing everything in your system at once.

Another factor to take into account is the digital transformation risk. You cannot avoid it, but you can calculate it based on data. Having figures before your eyes will help you decide whether the ROI of your legacy modernization process will compensate for the business risk it entails.

Modernization Due Diligence Step #2: Business Needs and Risk

Another thing to consider before choosing your modernization approach is the business side of the process. The modernization of your systems is not meant to make your code pretty.

Your digital transformation should be done for a reason: eliminating ineffective enterprise processes, boosting the user experience of your services, reaching more organizations with your digital product, etc.

Based on that, you’ll identify the component of your application that needs modernizing. You may not need an inside-out modernization. In most cases, other options like code refactoring are sufficient.

Here, the advice is the same: hold your enterprise processes on and analyze your current business situation. Are you able to operate with the current state of your application? Is your organization ready for the transition period? Does the current application still address your business needs?

Think about the business risk of your legacy modernization project. What will happen if your application stops working? Will security be endangered? Will you keep your enterprise processes uninterrupted?

If the whole functioning of your organization is based upon your legacy software, the risk is significant. The same applies to digital products sold externally that are based on legacy code. On the other hand, if your legacy system is just a digital tool used internally by one team, your organization won’t collapse if you shut it down.

You can mitigate the business risk of your project by choosing a proper modernization approach. What you should remember, though, is that business risk calculation comes before adopting the modernization strategy, not vice versa. That’s what the famous data-driven approach is about.

Strategies of Legacy Application Modernization

Once you know:

• why modernize your legacy system (= business needs),
• what to modernize (= current state of code + scope of modernization),
• what to take into account before modernization (= business risk),

It’s time to choose the best modernization approach for your project.

On the general level, you may do two things: replace your application with a new one or fix the current system. You may do it with your in-house team or using outsourcing services. Let’s start with the first process.

Modernization Approach #1: Replacing Existing Application

You may modernize your legacy software by rewriting or replacing it with ready-made applications. It’s an extreme approach (a revolution rather than an evolution) which is not very common (companies prefer to re-platform or re-factor) because of the following disadvantages:

• it’s expensive,
• it takes plenty of time,
• it entails business risk,
• developers don’t like it.

As Remco Jorna put it, “the people part is the most difficult one”. Imagine the reaction of your engineers when they hear about writing a new application from scratch. I mentioned that they don’t like working with legacy code, but rewriting the whole system is equally pleasant for them.

In most cases, the above disadvantages strike this approach out. However, there are also several advantages:

• you’ll fully understand each functionality of the new software,
• its overall performance is going to be much better now and in the future,
• you’ll avoid future problems with adding new features, migration, architecture redesign, etc.

There are several situations in which this extreme approach will make more sense than fixing strategies such as re-platform or re-hosting. Imagine that you’re modernizing legacy applications in PHP such as your website. It’s an important marketing asset, but the overall business risk of such a modernization process is low. You’re not storing confidential data there, and it’s not the foundation of your business model. If your application crashes, the consequences won’t be that serious.

One may also look at the risk factor from a different angle. Replacing a legacy application may be necessary when updating the current code entails too much risk. This may be caused e.g. by security issues. If modernizing selected components may lead to data breaches or system downtime, the extreme approach may be the only option.

Replacing may also work if your legacy systems stop being useful. The business processes they used to support are not there anymore or you have pivoted (hello, startups!). In such a case, it makes no sense to fix the current code as no one will use it.

Given all the cons of this approach, most companies choose to update their legacy software rather than shut it down.

Modernization Approach #2: Updating Current Application

In this approach, you modernize only selected components of your application. Actually, it’s a group of strategies that don’t involve building an entirely new system rather than a single method.

There are diverse stages of updating a legacy application, and organizations usually do it step by step. This way, they avoid a shock that usually appears after introducing major changes at once. This allows their enterprise clients or team members to familiarize themselves with the new setup and gradually adjust their work to it.

This modernization approach has a number of advantages over replacement:

• it’s cheaper,
• you can plan it and execute it faster,
• it doesn’t entail so much risk,
• it’s less disturbing for clients.

Modernizing your application this way usually doesn’t involve major changes in user experience and doesn’t pose such a threat to data security. If you asked your clients, they would probably opt for this one.

On the other hand, this modernization approach has a number of drawbacks:

• it heals the symptoms rather than remove the root cause,
• your developers are likely to keep coming across similar problems in the future,
• it doesn’t solve the problem of hiring and maintaining legacy systems specialists.

Given that, you should now understand why analyzing your business needs and software problems is so important. Without due diligence, you won’t be able to choose the best strategy for your project. Data is king!

Now, let’s see how to modernize legacy applications using this approach.

Modernization by Fixing #1: Re-Hosting

Arguably the simplest of all modernization options involves migration to new infrastructure (a physical or virtual one). With this strategy, you leave the application architecture mostly unchanged and don’t make significant changes to any functionality.

Here, the most popular option is migration to the cloud. Choosing one of the big cloud providers (like Amazon or Microsoft) guarantees to keep your infrastructure up to date as there’s an army of developers taking care of it. It’s one of the reasons behind the rising popularity of the cloud.

Modernization by Fixing #2: Re-Platforming

Another digital transformation option is to re-platform, i.e. move your legacy application to a new runtime platform to provide a new environment in which it’ll be running. With this strategy, you make minimal changes to the code itself while leaving your application architecture and features unchanged. The only changes you make are meant to guarantee that your application will run in the new environment.

Companies that re-platform usually do it together with the migration to the cloud. It’s a kind of compromise between re-hosting and re-architecting which are much more complex processes.

Modernization by Fixing #3: Re-Architecting and Re-Factoring

You can do re-architecting and re-factoring together or choose one of these options. When the migration to a new server or runtime environment is not enough, it may be necessary to optimize your existing code. Mind that this strategy is not meant to develop a new system but only upgrade the current one.

Switching to a new application architecture just like optimizing the existing code is a great way to improve your system’s performance without spending hours on writing a new app from scratch. Your developers will be grateful for it.

Update Modernization Strategy #4: Rebuilding Selected Components

This strategy focuses on identifying the key legacy components that need modernization and building them again without changing the application scope. It could be, for instance, a specific functionality or a set of elements creating the user experience.

Unlike with re-writing the entire application, you can implement this modernization process relatively quickly. As a bonus, your developers will be much more engaged in it. It’s a good choice for enterprise SaaS providers who cannot risk confusing their clients by launching a completely new application written in modern technology. Re-building the legacy components functionality by functionality will help end users adjust their work mode to the new features.

Legacy Application Modernization in a Nutshell

Legacy software generates a couple of enterprise problems in areas such as engineering, recruitment processes, staff retention or daily digital operations. Altogether, they translate into an unnecessary cost in terms of money and effort and hamper your company’s growth.

To avoid legacy technology issues, opt for well-tested modern technologies with a living developer community. Don’t make rash decisions nor choose new, hot and trendy technologies. If you feel temptation, think about whether you really need them (why choose a blockchain if an ordinary database will do?). To make sure that you’re making the right choice, consult with experienced software developers.

Start your legacy application modernization with a solid analysis of your needs. Inspect your current code and identify which areas need digital transformation. First, think about separate components. Plan the modernization of the whole application only if the partial approach won’t work for your system. Also, analyze your current business processes. Calculate the risk of your digital transformation based on data. 

Once you have data, select the best legacy modernization options for your business needs. You can either rewrite your current application or use one of the fixing options. 

Rebuilding is a costly and prolonged process entailing significant business risk. Use this extreme strategy only if fixing the existing system proves impossible or pointless.

You can choose one of many updating options. These are migration to new infrastructure (typically cloud-based), migration to a new runtime platform, designing new application architecture, refactoring the existing code or modernizing selected components. They involve diverse degrees of changes in the application architecture, scope of features, etc.

Above all, remember that legacy application modernization is a strategic process that entails significant risk. Proper due diligence before choosing the best method for your project is the key to a successful digital transformation.