This is a good post on how to improve the chances of success when doing a major re-write of software:
Some thoughts to add:
Don’t try to add new requirements during the re-write
The functionality of the existing system is often not exactly what the users and product owners want. A re-write gives them an excuse to fix all the past wrongs. There’s just one problem: trying to re-write and change the functionality in the same step is orders of magnitude harder than replicating the existing functionality, testing that it worked, and only then changing functionality later. This is for two reasons: the users are going to think any differences mean the new system is wrong and if the existing functionality is replicated then much of the testing can be automated. Computers are good at detecting differences. They are bad at knowing if those differences are good or bad. If it does turn out a difference is due to a bug in the old system and replicating the behavior would be costly, consider fixing the old system so that the output going forward will match. For example, if something is failing due to an integer overflow, it is probably best to fix it rather than propagate it to the new system. However, if the difference is that the old system runs in daily batches and so takes 24 hours to propagate, don’t try to make the new system real-time before first replicating the batch functionality.
The existing system is an executable spec. Use it!
Have you ever wished the product team could give you an executable spec that was defined so precisely a computer could understand it? That’s exactly what the old system is. It may be ugly and hard to understand, but it is more precise than any set of requirements could ever be. A product person or business analyst might want to write a spec for the new system. Instead, if there is any question about how something should work, don’t ask how it should work, consult the existing system.
Who wrote the first system?
One of the more common times for a re-write in my experience is an MS Access or MS Excel application written by a non-developer domain expert has outgrown its original purpose, become critical to the business, and now needs to be re-written as a “real” application by the IT organization. There are many legitimate reasons that this is a good idea, but beware thinking that since the first app was written by non-developer so now that you’re doing it “right” with professional developers then it will be easy. Can you learn his/her domain faster than he/she can learn to program? Is it better to have 20 years understanding the business and 1 year teaching yourself to program or 10 years learning to program and 1 month learning the domain? The answer depends on the people, but it is definitely not an obvious win for the programmer. Often times the hardest part about implementing a system well is understanding the business domain. During the re-write, the most important person to have committed to the project is that original author. Remember, that person understands the domain so well they can teach it to a computer. The original system may not be sufficient to support the business going forward, but it is good enough that it is supporting a business valuable enough to justify investing in a new system. If the original author is not committed or has already been burned by a previous failed re-write, try really hard to get them on your side.
The existing system can be changed
Change the old system if it helps. Yes, even if it is an MS Access application. Until you turn the old system off, there isn’t really an old system and a new system. There is one giant system with multiple languages and technology stacks and redundant code. It might help to add some new logging to the existing system to allow automated comparisons between the old system and new system behavior. Or a new data snapshot function that can be used to help tests migration scripts. If you treat the old system as that “icky thing written in a language I have no interest looking at” then you are doing yourself a disservice.
There are a lot of things that can go wrong during a software re-write, but it has some unique aspects that can be used to your advantage. If you have a project like this, you’ll need every advantage you can get. Good luck!