InnerWorks Logo
Return to main siteReturn to main site
Blogs

When and how should you update a legacy system?

Adam Shallcross • CEO and Founder

from Cogworks • 21 May 2024 • 1 min read

This straightforward guide on modernizing legacy systems can assist you in determining your current setup and what steps to take next.

Legacy systems aren't always a bad thing. Yet, with so many ways to modernise our systems, it can be confusing to find the best foot forward.

What is a legacy system?

Gartner describes legacy systems as an "information system that may be based on outdated technologies but is critical to day-to-day operations".  

In 2023 they’re legacy systems are still a major cause of the blues. A recent Forester report for Hitachi Vantara surveyed 213 IT leaders across North America and Europe. The report exposed legacy infrastructure challenges including:

* Significant revenue loss from technology downtime,
* High total cost of ownership for critical applications,
* Challenges in managing complex cloud environments.
* Significant impact on revenue due to technology downtime.

So how do you prevent becoming disatisfiecd or challenged by once-brilliant technology. The first step, is spotting you have a system.

How to spot a legacy system or technology.

How do you know you've got a legacy system? Some of the signs aren't always obvious:

1. Read-only mode. 


Probably the easiest to spot, this is the "life support" stage of an application or software. 

Organisations might choose to keep EOL (End Of Life) systems on a read-only basis because key users need access to the data for operational or compliance reasons.

Keeping data to meet compliance or retention guidelines can pose a security threat to your business when not adequately integrated with your applications. 

Yet, logistical challenges (like budget) or assumptions about the outcome can be a factor in keeping legacy systems running unnecessarily. 

 

2. Rigid architecture.

Legacy systems are monolithic by nature. 

Programmes with monolithic architecture consist of many components and services, treated as "one" unit within the development process. 

Traditional monitholic systems can be old or new, but due to their inflexible infrastructure, they'll inevitably become legacy systems over time. 

So, why do people still build monolithically? Well. It suits a lot of organisations, especially in the early days. Things can in some cases go south when these startups begin to make their mark in the industry and morph into enterprises. 

When modernisation gets left on the back burner, systems can become a complex collection of thousands of lines of code, making a simple bug fix or website difficult as there are often multiple functions tightly woven into the fabric of the code.

With so many interdependencies running through a monolithic application, it can be challenging to make changes without breaking the whole thing. Not a fun day at the office

However, a monolithic architecture isn’t neccessarily a bad thing, when build in a modular way, there is a lot of evidence that this can be a great step before introducing a microservices architecture.

Check out Adrian Ochmann’s Umbraco community blog on reasons to build a modular monolith first.

3. Outdated programming languages.

For a development language to survive, it relies on the corporations, products and applications that use it.

The 60-year-old programming language COBOL is still reported as active (even though there are arguably many languages more efficient, flexible and better equipped to do the job in 2021). 

Financial services institutions (like the IRS) and other government agencies keep COBOL alive; this fuels the need for skilled developers and education in this area. 

The challenges of migrating a legacy language can also be a factor in stalling the process for large enterprises.

In 2018, Uk Bank, TSB lost £330 million and 80,000 customers when they attempted to migrate their COBOL IT systems. (A comprehensive apology was later issued by the banks' board; it's easy to see why organisations cautiously approach legacy system migrations).

 

4. Poor documentation.

Legacy systems are known to lack documentation; either it's incomplete or doesn't exist. Why? Gerald Weinberg (psychology of programming expert) famously said it best on Twitter "documentation is the castor oil of programming—managers think it is good for programmers, & programmers hate it!"

For digital leaders, managing a team with a poorly documented legacy system can be challenging.. Although it's great for innovation that individuals can view the same product differently, it doesn't always help efficiency.

The good news is not all programmers hate documentation. 

Open source solutions are often dedicated to the constant evolution of their technology and documentation to help developers, strategists, and non-technical people understand how to use and extend the technology available. 

If you're involved in an open-source project, you'll know that the documentation is as important as the code itself and is contributed to by many industry professionals.

There are tons of resources available to help you with documentation; this quick guide from community hub dev.to is a great place to start. 

 

5. Hidden maintenance costs.

Costs often go deeper than a simple license fee and associated staff when running a legacy system.

Hidden costs can also present themselves as:


Frequent downtimes. 

Legacy systems often experience downtime. The average cost of downtime is different for every business, and the cost is not always in revenue. Downtime can contribute to the loss of brand trust and customer retention. 

Training.

Legacy system support and maintenance require specific skills and expertise. While the developers who have built the software might retire or switch to other technologies, it becomes increasingly more challenging to find and retain the right talent. Dedicated staff training might be an even bigger source of expense.

 

Lost business opportunities.

By investing in legacy software support and maintenance, you leave less room for innovations. Instead of adopting new technologies and business models, you are stuck with your old software, letting new opportunities in your industry go unnoticed. This leaves competitors more openings to outperform you and take over your market share.

Legacy system modernisation approaches.

If you've inherited a legacy system and are ready to extend it, you may have encountered resistance to modernisation because of time, money or alternative viewpoints. Legacy systems in digital are often ingrained into daily operations, which can be one of your biggest challenges in the business.

Why do organisations keep legacy systems? 

Here are a few common reasons:

  • They still fulfil a business need or are "mission-critical".
  • It's a large technological investment still in arrears.
  • Unclear advice on how to update.
  • The company lacks the IT skills to migrate the legacy system.
  • The organisation doesn't want to change.

There is no "one size fits all" approach for everyone. To help you decide, here are a few modernisation approaches:

Option 1: Patch.

Investing in intuitive "patch" solutions may be the ticket to suit your business goals. Here are a few common ways to modernise this way:


Move to cloud architecture.

If inadequate data management is your problem, moving to the Cloud can help to reduce costs and improve flexibility and performance! Although the vendors you work with will have an easy upgrade path to the cloud that isn't limited to your current vendor, always research before you leap.


Utilise API integrations to achieve a specific goal.


APIs (Application Programming Interfaces) define how software talks to other software, allowing businesses to express themselves exactly how they want to.

APIs offer deeper personalisation in response to users' rapidly changing expectations. The possibilities with APIs are limitless; that's the beauty of them.  Large organisations that rely on data for compliance reasons often use the API modernisation approach to extend the life of legacy applications, like, Document Management Systems. Adopting APIs is a great way to modernise when you want to replace only some of the system. 

By 2023, Gartner predicts that 30% of commerce companies will need a dedicated API product manager in their organisation to handle the modernisation of commercial applications and the underlying architecture!

In short, this is a great option to make your legacy system appear new.

Option 2: Adapt.

A gentle transitional approach to modernising your legacy system from a monolithic architecture to microservices.

Move from monolithic to microservices.

Moving from monolithic to microservices or "going composable" is to gradually make your monolithic application more flexible and adaptable! To adapt, you don't need to do a complete microservices overhaul, but moving one element of your application or all of your application architecture is a great way to build a smarter future-proof product. 

You can start building services for aspects of the application using microservices, where each microservice replaces one small component of the monolithic legacy app, but in a modern way. 

You can also fully detach your backend from the UI, modernise the UI in a microservices architecture, and then make some adaptations to the backend.

Composable technology is the future of business. CIOs and CTOs have known about things like APIs for some time. Still, a paradigm shift is happening. 

Businesses are looking inward as a whole, seeking more autonomy in not just technology but business thinking and architecture.

The MACHAlliance, a not-for-profit body, is working to support this shift by advocating for an ecosystem that provides a flexible, truly open and future-proof architecture.

Adopt agile.

When your business needs to react to changing market requirements quickly, stepping away from waterfall principles and moving towards agile practices in your digital projects can help. It doesn't matter if you're patching, evolving or replacing your legacy system; a simple focus on Agile methodology and Continuous Integration (CI) in your development cycle (often referred to as DevOps) can help you build quickly without limitations and provide your organisation with a wide range of choice as to what vendors and microservices you choose.

Option 3. Replace.

This is what it sounds like—replacing the whole thing. 

Legacy software re-engineering is a less risky approach to software rebuilding; this option requires thorough preparation and planning with your digital partner.
Technically speaking, replacing the software requires the translation of the source code into another programming language, the reorganisation of a database (or its transfer), the optimisation of software architecture, the addition of new features and the integration of third-party APIs! 

It doesn't sound very easy, but it can be.

Reinventing your entire technology stack can be gradual or instant; it depends on your time and budget.

The takeaway. 

In conclusion, the aim is to transition the technology towards a more adaptable stack, empowering your business to always be ready; be it shifts in the economy, global crises like pandemics, or changing customer demands. 

Acknowledging the hurdles posed by legacy technology and strategically prioritizing them, organizations should incorporate software classification into their product lifecycle. Regular evaluation of the technology landscape is imperative, enabling informed decisions on the most advantageous modernization approaches!

Community tech aid

Innerworks and Cogworks are proud to partner with Community TechAid who aim to enable sustainable access to technology and skills needed to ensure digital inclusion for all. Any support you can give is hugely appreciated.