Suppose you had to move a very large amount of data from one database to another. And lets make it interesting: although the general conceptual data model and details must be carefully preserved, some of the old data is somewhat dirty, and it is in a different form and structure from the desired database: different tables, different fields, different constraints etc. Now suppose someone tells you: "It is impossible to convert the data using tools, you will have to reenter it all by hand!". I suspect you would think they were a bit crazy (or getting paid by the hour to reenter the data). You would not do a data conversion by hand, right? You would analyze the source and target data models, build a conversion process and test it carefully. You would very likely build and test several versions of the conversion process until you were certain the results were both faithful to the original data and conformant to the specifications of the new data model.
I admit, this is an extreme analogy, but the reality of large software conversion is that tools and automation are extremely useful because they let you fully leverage the legacy codes.
Face it: the source code is the an extremely accurate, formal, and complete specification of what the system does and how it does it. 99% of the time the source is the only detailed specification available. Doing a rewrite
from scratch means ignoring the existing source and it means the team will have to rebuild a mountain of functional and micro-level technical requirements manually. Functional requirements gathering will end up taking the majority of your resources. Or does "from scratch" mean reading and recoding 100s of thousands of lines of VB code? That is a recipe for failure. This is certainly NOT where you want to spend most of your migration project budget. Leveraging tools to help you do the job, particularly when facing huge systems, allows the team to spend their resources more effectively.
Both tool-assisted and manual migrations demand a lot of analysis and design work to define how you will effectively take advantage of .NET. The difference is in how you spend the rest of the migration project resources. With a manual rewrite from scratch, you will spend most of your resources re-gathering functional requirements, manually typing in code, and fixing the defects that come along with massive amounts of new manual effort. With a tool-assisted rewrite, you will spend more time evaluating technical redesign options and tuning the translation tool to produce codes that faithfully reproduce the results and behavior of the original application while fitting into the design. I am not suggesting a tool will produce 'perfect' codes right out of the box -- people do not write perfect code manually on the first try either. I also am not saying that all new code should start from a translation; of course select parts of the new system will be redone from scratch. What I am saying is contemporary software analysis and reengineering tools will help you plan and ultimately implement an efficient conversion process that balances manual and automated work to deliver a higher quality result more efficiently.
A detailed discussion of this topic is here:
http://www.greatmigrations.com/resources_articles.aspx[
^]
Submit an article or tip