Why you should trash your old software (and how to rebuild it)

Yep, there are many reasons why you should redevelop your outdated software. But this isn’t as straightforward as it sounds. Here are a few tips to avoid some of the common pitfalls in redeveloping software.

But first, why start all over, trash an old system, and redevelop the software from scratch? The IT landscape changes incredibly fast. Faster than most other industries. Just think about the software you were using 10 years ago. Then think about software 20 years ago, you know, 4 years before the first iPhone. Many companies have built great software and have been maintaining and expanding it for years. However, that software is often still based on an outdated foundation. At some point it’s often better to start fresh, and redevelop your software based on current technologies.

Next to outdated systems, there is a whole other category of software that eventually will have to be redeveloped. The in-house-built “temporary” solutions. The quick tool that one of the engineers built to automate some documents, or that temporary Excel sheet that started simple, but now supports major processes of your business. These are great and quick ways to automate or innovate, but when more people start using it, or when the creator doesn’t have time to maintain it anymore, you’ll need a more robust solution.

So, redevelopment it is. You have the old software as an example. What’s so difficult? Well, here are some common mistakes:

“We want it to do the same as the old software.” - Yes, you’re used to the old -comfy- software. But it’s a missed opportunity if you don’t evaluate current features and use the new possibilities of modern technology. Also, your company has probably changed over time, so make sure that the new software supports those changes properly. Your users might have to adjust their workflow a bit, or have to get used to a new interface, but it will be worth it.

“Requirements? Just look at the old software.” – It’s tempting to “save time” and just start redevelopment based on a quick look at the old software. However critical details and use-cases might be forgotten, especially when the development team isn’t familiar with the old software. So take your time to make an overview of the old functionality, and don’t forget to talk to the current users to discover how they actually use it and what workarounds they have in place.

“We’ll demo it to the users later” – Okay, this applies to all software projects, but especially to redevelopment projects. You need to keep the users involved. You’re not just launching a new system. You’re replacing something they are used to. To reduce resistance and to make the new system a success, include the users throughout the project. You’re probably developing Agile anyway, so why not use the feedback.

Over the past years we’ve done many redevelopment projects at SST Software. Even though redevelopment shouldn’t be that different from “just” developing a new system, in reality it is. There are different expectations and risks. When done properly, it’s worth it and will keep you ready for the future.