Some time ago, I helped a British company to
prepare and plan for their in-house migration project. One of the first things that we checked were
the project effort estimates, so we could build a work breakdown structure
based on the estimated effort for each activity; both the company’s developers
and ArtinSoft’s had made separate estimates for the project so we could compare
and discuss them.
To my surprise, the company’s estimates were
significantly lower than ours, so we started digging into the details to find
where the biggest discrepancies were, and realized that their estimate
consisted of developer effort only, with no testing or administrative work. They were so focused on manual changes,
Upgrade Warnings and compile errors that they omitted the QA process necessary
to validate that the application is stable and working as the original
one.
As with other development projects, migrations
do require a full testing of the converted application before it is released to
production. You may find less bugs than
you would if you were coding from scratch, but the complete QA cycle is vital
in order to ensure stability and Functional Equivalence. Also, don’t forget to include effort for
administrative tasks as well as other activities that you may have in your
projects, depending on your project management methodology.