If the original requirements are available, this is the best starting point. Many times the requirements will not be available. This is very unfortunate, but after the design is extracted from the code, the requirements can be reverse engineered, but at a cost.
Whether planning to automate a translation from MUMPS to another language, or re-implementing the system with updated requirements, it is informative to see the as-is desgn. Many times, the design, like the requirements are not maintained throughout an applicaions life.
If the original design is available, update it using the as-is design, use the updated requirements to check the design for consistancy and testability.
In all my years, there has never been a language that is best for every system. I use C++ to do the automated translation only because it seemed to be the only viable solution. I might have been able to use JAVA, then I would only be replacing one interpreted language with another. Also, I needed the flexibility of C++.
Test plans and test procedures should be treated as part of the design process. Often times, they are left until the system is coded. Lack of planning is the cause of too many systems being thrown "over the fence".
Once the design is ready and the implementation language is choosen, the system can be implemented. This process can be very smooth if the design was done well. I have often frightened some of my management because I delay coding for what they feel is too long. They are relieved to notice that when coding begins, it is a no-brainer and goes extremely fast. Not only does the coding go smooth, but testing goes smooth as well, since the test plans were designed along with the code.
With the test plan complete before we need it, testing can be performed quickly.