Replacing legacy systems (Part I)

As a software engineer/software architect I have been involved in projects which focused on replacing large legacy systems. With this post I want to share some of my views on this topic. My hope is that this can help others learn from my experiences and to also get new ideas from people reading this.

The status quo

So you get into a project where you are confronted with a large legacy application:

Your new challenge.

The urge of many, especially less experienced, software developers is instantly to want to do this:

out with the old, in with the new…

Which is understandable, because:

  • Everybody likes greenfield projects.
  • We know how to deal with new shiny technology x.
  • Nobody wants to do with old things that are weird.

But, this typically doesn’t work. Not unless your legacy system is super tiny, which, trust me, it isn’t, otherwise you wouldn’t be in this project but intern #8 would have been tasked to rewrite it.

Also there’s probably a lot more secret sauce & domain knowledge inside the legacy system than you may give it credit for at first. So here are some more things that will probably happen with this naive approach:

  • You will loose lots of (undocumented) functionality that key users have come to know and love in the old system.
  • Your big-bang release where you switch all users to the new system will horribly fail.
  • The outline of your perfect shiny new circle will look very warty within a short time because you have to re-add lots of things that you thought unnecessary which your new architecture can’t support without major changes so you just tack them on so that it works.

Divide and conquer

The approach I like to use and would suggest is the same you would use to break down any complex problem in (software) engineering: break it into smaller pieces.

Step 1: Get the big picture

But don’t just “start somewhere”:

  • Get a good overview of the current system, by talking to the stakeholders: users, managers and original developers (if at all available anymore).
  • If you can talk to the original developers, give them credit for what they achieved! They built a system that helped the company/clients be productive for many years, you on the other hand haven’t done anything yet.
  • Together with the stakeholders identify a part of the system that is sufficiently self-contained to be a first candidate for replacement.

Naturally, the typical software development best-practices apply here: define personas, use some established [agile] methods such as scrum etc.

Step 2: Select your first target

Self-contained in this context does not mean that this part of the code is super cleanly separated from the rest of the application. It also doesn’t mean that this has to be the oldest or trickiest part of the application.

What you should focus on here is that there is a group of users that can spend most of their day being productive within the bounds of this subsystem. That way, when you are done, you have a perfect little subset of users that can already work in the context of the new application.

Step 3: Explore your target

Before you now throw yourself and your team into the first implementation sprint, take your time to get to know your target subsystem from a technical perspective — you hopefully already know everything from the domain perspective from your stakeholders, right ;)

Check which contact points you may have here with other systems, how the roots inside the application look like.Decide where you want to make the cut.

Explore the target subsystem and its roots within the legacy application.

It won’t make sense (or even be possible) all the time to re-implement everything from scratch. And why would you, apart from new and shiny being desirable, but we already discussed that, remember?

A short technical note, since I hear some developers screaming somewhere in the back:
The picture on the side should simply illustrate that you imagine that the target subsystem is no longer there and that you look for technical connections that go deeper into the whole application. I also don’t want to indicate that you simply remove that part of the code and then simply add a new module to the old application. I do not want to go into any specific technology decisions here.
The decision if the replacement system is a new standalone application which only talks over process/machine/data-center -boundaries with the old application or not, is a purely technical one which will be different depending on the specific project.

The next steps

Obviously we are far from done yet, but I want to cap this first post here.
Continue reading part two of the article.


If you have any suggestions, want to share your own experiences and thoughts with similar past/present/future projects, please do so, I am very much looking forward to reading them.