The CTOs Guide to Modernising Legacy Systems

Legacy systems aren't always a bad thing. Yet, with so many ways to modernise our systems, convincing the right people of the best way forward can take time.

In this guide we'll explore:


1. How to spot a legacy system or technology
2. The importance of regular technology reviews.
3. Legacy system modernisation approaches.

1. How to spot a legacy system or technology.

Gartner describes legacy systems as an "information system that may be based on outdated technologies but is critical to day-to-day operations".  But how do you know you've got a legacy system? Some of the signs aren't always obvious:

- Read-only mode.
 

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

Organisations might keep EOL (End Of Life) systems read only because key users need access to the data for operational or compliance reasons. Of course, this can drain IT budget and resources, but in a recent survey, 89% of UK enterprises continue to maintain legacy applications running to maintain the data. 

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. 

- Rigid architecture.

Legacy systems are monolithic by nature. Programmes with monolithic architecture consist of many components, modules and services, treated as "one "unit within the development process. 

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 only start to go south when these startups make their mark in the industry and morph into enterprises. 

Ever heard the saying, "If it ain't broke, don't fix it"? (we can blame Bert Lance for that saying). As cliche as it is, it's still a cliche. It's a famous phrase. So, it's not surprising that this attitude echoes through many organisations. 

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 multiple functions are often tightly woven into the fabric of the code.

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

- 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 factor in stalling the process for large enterprises.

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).

- 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 a nightmare. 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. 

Great documentation standardises the development process and maintains an efficient workflow. Without documentation, efficiency can take a hit when teams take the long (or wrong) way to perform tasks like bug fixes or deployments.

There are tons of resources available to help you with documentation. We like this rather vintage-looking documentation guide from Peter Hilton.

- Hidden maintenance costs.

When running a legacy system, costs often exceed a license fee and associated staff.

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, finding and retaining the right talent becomes increasingly more challenging. Dedicated staff training might be an even bigger source of expense.

-Lost business opportunities.

Investing in legacy software support and maintenance leaves 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 dominate your market share.

 
3. The importance of regular technology reviews.

Once you've decided to prioritise using modern technology, it's important to keep tabs on your system's "sell-by-date" at regular intervals to help you identify the right modernisation technique, whether using APIs to modernise or moving to the cloud. 

Source: TechTarget, 2021

4. 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 you can discuss with your technical partner.

Modernisation 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 data management is your problem, moving to the Cloud can help 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.

Some of the main players you will probably have heard of are Microsoft Azure, Amazon AWS and Google. 

Our projects often include Microsoft Azure and Umbraco mainly because they're both ASP.NET applications, a framework we have specialised in for over 12 years. 

- Utilise API integrations to achieve a specific goal.

APIs (Application Programming Interfaces) essentially 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.

Modernisation 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! You don't need a complete microservices overhaul to adapt, but moving one element of your application or all of your appliocation 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 technology, 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. 

Modernisation option 3: Replace. 

This is what it sounds like—replacing the whole thing. Or re-platform, rebuild; there are many ways to say it.  

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 translating the source code into another programming language, reorganising a database (or its transfer), optimising software architecture, adding new features, and integrating 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. 

The goal is to move the technology toward a more composable stack so your business can quickly adapt to new circumstances, whether a change in the economy, a global pandemic or customer needs.

Get in touch if you'd like to chat about the best option for you, or look around our LinkedIn profile to see what we're talking about this week.