I used to think that - at least sometimes - redeveloping something from scratch is a good idea but in the last couple of years I realized that this rarely if ever the case. The problem is that you will introduce a lot of new bugs and reintroduce bugs that got fixed long ago. There is no good reason to believe that you can develop a piece of software without making hundreds of the common small mistakes that just happen - off by one, switched sign, missing null checks, you name it. And even if you have to deal with one of the worst code bases you have ever seen, the developers will already have spent countless hours wiping out such problems. Starting from scratch not only means getting rid of bad code, it also means throwing a lot of useful work overboard.
So if I have to deal with The-Worst-Code-Base-Ever™ I create a new project and copy the code into the new project file by file in the order you would develop from scratch and clean it up before moving on to the next file. Improve the naming, split large functions, extract common code, unify similar code, look for and fix bugs, improve algorithms, comment out code that references code not yet in the new project or code not yet used and when there is a good opportunity improve the architecture - given that you already understand the code base well enough. It takes time, you touch some files a hundred times and move around bits and pieces seemingly forever, but I am pretty confident the result is better than rewriting everything from scratch. All this might be not such a good idea without good tool support, but if moving and renaming things or changing function signatures project wide is just a matter of seconds, there is real value in doing it incrementally instead of trying to do and get it right all at once.
Starting with tests is usually a better first step. Mostly functional tests are easiest to write.
If you can find parts to replace into separate services, that is best. So you can slowly migrate the system, whilst gaining the benefits quickly for the new code. That way, if the project takes a year, bug fixes can happen in the new code. Also features can be added to the new code.
Also, if after a year and the old system is still being used, then valid questions may be asked about what use the new system is.
So if I have to deal with The-Worst-Code-Base-Ever™ I create a new project and copy the code into the new project file by file in the order you would develop from scratch and clean it up before moving on to the next file. Improve the naming, split large functions, extract common code, unify similar code, look for and fix bugs, improve algorithms, comment out code that references code not yet in the new project or code not yet used and when there is a good opportunity improve the architecture - given that you already understand the code base well enough. It takes time, you touch some files a hundred times and move around bits and pieces seemingly forever, but I am pretty confident the result is better than rewriting everything from scratch. All this might be not such a good idea without good tool support, but if moving and renaming things or changing function signatures project wide is just a matter of seconds, there is real value in doing it incrementally instead of trying to do and get it right all at once.