What Are Legacy Systems and What Should You Do with Them?
We talk a lot about legacy systems, how complicated they are, and usually how we want them to go away. But what are we really talking about? AS400, SQL and Oracle backends? Or business applications such as SharePoint, Cognos, and SAP? It’s actually none of these.
What Legacy Means
Legacy systems don’t define a stack, they define a hurdle. The hurdle could be a lack of internal support, it could be end-of-life tools, it could just be that the only way to work with the application is Waterfall.
In actuality, the majority of “legacy systems” are home-grown applications whose original developers have vanished, leaving the organization stuck with a massive refactoring challenge.
Legacy does not necessarily mean that the tool is not current. It’s more defined by how the organisation perceives and uses it. They do commonly share the fact that they are:
- Not adaptable
- Built with Waterfall methodology
- Monolithic
Even if it is a tool developed just two years ago, if end users are frustrated but stuck with it, that is legacy.
What’s Wrong with Legacy?
The features of legacy applications limit the mobility of companies in two key areas.
Firstly, it limits innovation. Even patching some legacy applications can be risky (what if it breaks?!), never mind adding the kind of additional functionality that ensures it remains competitive in the external marketplace, or fit-for-purpose internal to the company.
Secondly, it requires a lot of time and effort to maintain, which could be much better spent on activities that actively differentiate the organization in the marketplace, rather than simply maintaining the status quo.
What Does It Mean to Be Modern?
On the other hand, what defines a modern, non-legacy application? These are:
- Adaptable
- Built with Agile/DevOps methodology
- Modular
These are designed to be changed very easily and frequently so that the utility of the application can be constantly kept up-to-date and maximized.
Designing systems with service-oriented architectures or micro-service architectures is key, but also too are designing the ability to automate the deployment and monitor the health of the system. These are all properties that are encompassed in the twelve-factor app methodology, according to which applications should be built to:
- Be deployed on modern cloud platforms, obviating the need for servers and systems administration
- Minimize divergence between development and production, enabling continuous deployment for maximum agility
- Enable upscaling without significant changes to tooling, architecture or development practices.
My colleague Alex Manly introduces how to build 12 factor applications here.
But what do you do with your legacy? How can you turn it from a monolithic, Waterfall beast into a modular app with high release frequency?
Making a Change
Most will agree that legacy systems should be replaced. As one example, there are AS400 systems that you simply can’t touch.
But for the majority of legacy applications, replacement is not the best option. There are better paths forward—ones that allow you to make the most of the investment you’ve already made in legacy applications, without wasting time building alternatives from the ground up.
Those paths are:
- Move to cloud: in the best-case scenario, your legacy application is not custom code, it is a solution from a vendor, and they have created a cloud-native solution with a migration path. This is true with most all of Microsoft, SAP, and Oracle technology. Not only do you have an easier path to adoption, you have someone to complain to if it does not work (unless it has been excessively customized). If it is a custom application, you can move it to the cloud yourself. Here’s how
- Just move it. This is as simple as moving VMs for some cloud providers, or installing the solution on cloud instances. The experience does not change—it’s just in newer, more flexible infrastructure.
- Move and build an API. Take it one step further, and instead of giving users the old platform with the same legacy interface, give them the legacy tool with a modern up-to-date interface. To do this you would need to build an API on top of your existing application. (There is some tooling out there to help with this.) Then your development team moves to creating better front-ends and adding new functionality, instead of maintaining the legacy application itself. They are adding value instead of maintaining operability.
Neither of these approaches are great. Both create a modern version of the same old thing, and just delay the inevitable. But it is a quick path to get started.
- Rip and Replace: again, if there is a vendor who can simply replace your old tool with a newer version that fits modern application development standards, and makes your ability to extend it easier—fantastic! However, if it’s your own custom-coded application, to rip and replace, you essentially need two separate teams, with one maintaining the status quo of the legacy system until a modern version with the same functionality can be built in parallel. The first version of the modern version will have to be developed in Waterfall up to a point, when it needs to move into DevOps/Agile/12-factor development practices. If it doesn’t, it’s just legacy v2.0.
- Adapt: adapting your existing monolith to a modern version brings the advantage of being able to start right away. But end-to-end, it requires as much effort as rip and replace, and has some additional risk. You would choose adapt over rip and replace if you are confident of success, and the cost of historical development cycles has been too high. To adapt, you not only need new infrastructure and architectures, you need internal domain expertise on the existing application.
There are many ways to approach this. You can build an API. 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. This requires that the legacy application be developed in a very modular way via SOAP or similar practices. You can also fully detach your backend from the UI. Modernize the UI in a microservices architecture, and then make some adaptations to the backend. There are tools that will, for example, allow you to streamline schema changes, etc., and fit them easily into a continuous integration process.
This way you can incrementally modularize your previously-monolithic application, gradually making it more flexible and adaptable over time.
Currently, the adapt approach is winning the most mind-share. Companies like Docker are recommending this as the ideal path to move your monolith and then modernize it. It’s a way of moving forward whilst taking upfront advantage of low-hanging fruit that can be relatively easily adapted.
Legacy Doesn’t Mean Old!
Legacy applications are not all twenty years old. They are any type of application that your organization’s end users find cumbersome and that does not meet modern application architectures and expectations. And modern applications don’t have to be brand-new, but rather, modular and adaptable!
