Legacy Software – The Big Rebuild
In our last post we talked about what legacy software is, why it exists, the risks in using it and a quick overview of options to move forward. In this post we are taking a deeper dive into one of those options, the complete rebuild.
When Should You Consider Rebuilding?
- When you do not have access to the underlying code base.
This happens a lot, especially when you think you are going to be working with a developer forever. If your developer has the only copy of the source code that you own then it can be lost if they go out of business or if there is a complete breakdown in the relationship. Not having access to the source code is especially an issue with languages that are compiled to run.
- When the original language has not been updated.
Just like your software can become legacy so can the underlying coding language. This is fine in the case where that language has continued to evolve into newer versions but there are estimated to be about 9000 programming languages that have been used and only about 500 – 1000 that are in use today. That is a lot of dead ends.
- If only a small percentage of the software is being used
Maintaining overly complex software where only a small percentage of the functionality is actually used can be overly expensive. It is often worth exploring the cost of starting again as it will normally work out cheaper.
- If it is simple
Simple can often mean only a couple of functions are needed. There is probably no point in trying to incrementally bring it up to date when the redevelopment time can be measured in a few weeks work.
- If it is critically broken and cannot be fixed.
Sometimes software breaks and either the resource to fix it is just not available or the cost of fixing it is too prohibitive.
The Big Plan
All software development needs a plan but with legacy software you are often looking at a lot of moving parts. The best approach for your business will vary from others but nearly always a full system audit is needed. We like to start with:
Users Audit:
Who they are and what they do with the software
Software Audit:
A full review (at the code level if possible) of every feature in the current system.
Comparison:
Using the above, work out what is going to need to be redeveloped, what can be archived, and what can be removed.
Critical Issues:
Features that can be improved, fixed or created that would have a significant impact on the usefulness of the software.
Data:
What data needs to be migrated to the new software and what can be safely archived. It might be the case that a small bit of software is needed if you need access in the future of archived data but it almost certainly should be separate.
That covers the basics of what will make up version 1 of the rebuilt software and form the foundation of writing the Software Requirement Specification. In this part you would add in stakeholders, budgets, timeframes etc, much like any new development project.
In fact, the development and testing phase is the same as any development project. The remaining big difference with a rebuild is how to start using the new software in a live environment. You can have a date where you stop using the legacy software and start using the rebuilt version. It can be very effective if the testing has been rigorous, the users have been trained on the new software and the developers are on call to fast fix any issues that may come up when the software is made live.
The two popular alternatives are to either release the new software to a subset of users and slowly add in the rest of the users as the software is shown to be working. The other method is to run the legacy and rebuilt software side by side for a period of time.
There are pros and cons to each release method, but normally your developer will have a good idea on which approach to take.
Summary
Starting again is a very popular approach and in some cases the only one available to you if you want to move from using legacy to best practice modern software. The positives are that you are not really starting from scratch with a blank piece of paper, you have something and you know what works, what could be better and what needs to be removed. The negatives are all the extra planning involved.
In our next post we will look at an alternative, the incremental improvement method, which can reduce the negatives. In the meantime, if you have legacy software that you need help with then please contact us.
