First things first, a legacy system is not just an old piece of software. It could be a paper-based system which you are looking to replace with online forms, or a program which is only a few years old but was poorly made. This article refers to the scoping of any system, digital or not, which you are recreating or modernising.
When it comes to scoping out a replacement for an existing system, the simple answer is yes, it is different to scoping out a new product. However, it still follows the same basic principles of scoping, only with a different focus; rather than validating whether your idea is sound, it instead focuses more on understanding the existing system and ensuring what you build replaces it effectively. It provides the team with a chance to both improve the current system and solve any problems it may have.
Some product owners come into this sort of scope with the mindset of “Scoping isn’t necessary, we will just rebuild it on a new tech stack, maybe with a nicer logo”; the general idea being that they will just recreate what is already in use, maybe with a few minor tweaks but essentially the same at its core. Perhaps they may even quote the well-worn phrase “if it ain’t broke, don’t fix it.”
However, we have yet to see or hear of a system which is being migrated which doesn’t have a large range of flaws. In fact, most of the flaws have become well documented to the point where all the users know that if you want to do X, first you must do Y and Z in the correct order. Perhaps there is even an employee who has been using it a long time who is considered the “wizard” of using the app, and only they can help you do all sorts of weird things that no-one else understands.
It is for this reason that a legacy migration should not be considered as a recreation, but instead as a chance to modernise and transform the system. Going into the scope, you should be talking with the wizards and users, conducting user interviews and gaining a thorough understanding of the system and its flaws.
Since it is still a scope, this article will follow the same How can I use Design Thinking to scope products? we use here at Codebots, but detailing how that stage may differ for a legacy migration.
Understand
This is the most important step when you are conducting a legacy migration: understanding the existing solution and the problem(s) it is trying to solve. In a standard scope, this is normally dedicated to discovering what problem the concept is addressing. This helps ensure the team is on the same level as the Product Owner, and gains a better understanding of the motivation behind their work.
For legacy systems, this stage is a chance for the team to dive into the current system and “understand” what it does and how it works. This may involve interviews with subject matter experts, reading the documentation which comes with the app, and gaining access to the system so you can click around in there yourself. If you find yourself asking why something is done a certain way, make sure you ask that question and write down the answer. This is your chance to learn from past mistakes or uncover extra requirements which haven’t yet been thought of.
If you discover there are other systems which you need to integrate with, this is also the opportunity for the developers in the team to start tech spiking. They can look at how it is currently done, how it would be done in the new system, and get an idea of how much effort would be involved to implement it. Similarly, they can also start considering how the new product would integrate with the legacy system, if that is going to be required.
This stage should be absolutely full of documentation. Since you are working with an existing system, you will be getting knowledge coming at you from every angle. It is very important you record every meeting and upload every document to your knowledge base so everyone can find the information and none of it is lost. This is a mindset which you should retain throughout this whole scoping process.
While you will be focusing on the knowledge dump in this phase, it is also important that you don’t forget its core value: understanding the problem which you are trying to solve. You don’t just want to know what the system is doing; you need to know why it is doing it. If you can understand the user’s motivations, then you can build a better product and deliver the most value.
Observe
Once you understand the system and its goals, it is time to start observing how people actually use it. You don’t want to rely on the system’s help documents or how the manager tells you the system is used. If there is one thing which is accurate about legacy systems, it is that the users never use it exactly how they are supposed to.
This is also the bonus of working with a legacy system: unlike brand new app, you already have a set of users who you can interview.
One of the best things you can do is ask a few users what tasks they do on the system, then ask them to demonstrate each of them for you. You could also ask them what their favourite parts of the system are, along with their least favourite, or what was the one thing they wish the system could do. This is your opportunity to learn even more about the system and gain an understanding of the user flow and pain points.
Again, you’ll need to make sure that you are taking ample notes and recordings of the meetings.
Ideate
The ideation stage can be a bit difficult when it comes to working on a legacy migration. There is a very strong tendency to recreate the existing system, even if it is not deliberate. Lean heavily on the brainstorming and other activities which encourage creativity and out of the box thinking. This is your chance to change things for the better. That being said, you also don’t want to avoid an idea just because it resembles something from the existing system. What you want to find is the best possible solution for the problem, which is probably going to be a mix between both.
When it comes to legacy systems, the desire to diverge is lower. It is easy to get stuck into a solutions headspace because there is already a solution there. It is important to keep in mind that people can also get scared of change, and thus different solutions, because they have already spent time learning the old system.
However, it is vital for the team to successfully diverge their thinking here so they can come up with different solutions (and not just get stuck rebuilding the same thing). That is why it is so important that during the Understand phase you don’t just learn what the system does, but why it does those things. Understanding that, and then building a new solution based on that, allows for a more human-centred approach.
While ideating, the team should not be looking for wild ideas which change the game. Instead, you should be looking for improvements which still follow the natural flow of the users. If you come up with a solution which technically solves the problem, but requires users to do something which is wildly different from normal, then it will still fail despite it solving the problem. You can take this opportunity to tests concepts and workflows (not prototypes, you don’t want to waste time) with your users to see whether they would work well.
Prototype
Prototyping is when you take the best ideas you came up with during ideation, and turn them into something you can test with. Here is where it is a bonus for you to be working with a legacy system: you have a bunch of users who you can test with. Make the most of them, ask plenty of questions and get as much feedback as possible.
You will need to look out for some pitfalls though: some employees may be so overjoyed at a nicer version of the system that they turn a blind eye, while others may be confused and expect things to work exactly the way that they used to. Make sure you take all feedback on board but with a grain of salt. If you feel like one of those scenarios may be true for the person you are testing with, make sure you dive in deeper with them to ensure that you are actually getting their true opinions.
Requirements and Prioritisation
Once you have completed your prototyping, it is time to commit and document the requirements. Once you have your initial list ready, there is one activity which you can do which is unique to scoping digital legacy systems: creating an entity/requirements traceability matrix. This creates a map between the existing database and the new list of requirements. You can match up requirements and entities to check whether there are any entities which are not covered, thus identifying holes in the requirements list. While this is not perfect, it can help spark conversation and unearth larger gaps in the requirements.
Once you have the list, you will need to analyse your options and start to prioritise the work. Prioritisation is not too different for legacy systems as you still have very similar considerations, though there is one main question which needs to be asked: Are you building the entire system and replacing it all in one go, or will you be doing a gradual build where you transfer piece by piece?
At Codebots we recommend a gradual build, despite the small amount of extra work, as it gives you the opportunity to learn as you build. This follows a more agile approach to development, and typically gives you a far superior product at the end because you were able to learn and adapt as you went. As you prioritise, you will need to consider those integrations to join old and new, as they may affect the order in which you develop and your estimation.
Conclusion
Our scoping process is deliberately relaxed and high-level to make it as easy as possible for it to be applied to a large range of projects. While scoping a legacy system is not entirely different to a normal scope, there are some pitfalls which should be kept in mind, along with some additional activities which can be done to help capture knowledge. If you are interested in scoping out a legacy application, we highly recommend you take a read of our Bots the Code Playbook. It goes into the problem of legacy systems, how a company can reach a state of continuous modernisation, and includes a large range of activities which can assist in that process.
Written by Tessa Mylonas
Head of Support and Education
If Tessa isn’t busy answering support questions or educating you about the Codebots products, she is typically found putting together flat-pack furniture, playing with her chocolate Labradors or hoarding houseplants.
