Notes from Microsoft Dynamics GP 2010 Implementation: Say no to parallel testing

I’m working my way through the ebook version of Victoria’s Microsoft Dynamics GP 2010 Implementation book (and Clancy’s Dead or Alive and Bogle’s Enough all at the same time).

I know that it’s hard to stuff all of the things you want to say in a book so as things struck me, I thought that I would add some emphasis to some of her points.
While working through the section on whether or not to run two systems in parallel, I felt the need to add my own opinion. Just say no. Victoria does a good job of discouraging it but I’m going farther. Just say no to parallel. In addition to Victoria’s reasoning as to why parallel is not a good option (you’ll have to read the book to see those) these are my thoughts :

• Companies regularly find that when there is a discrepancy between the legacy system and GP, the legacy system has been wrong for a long time and GP is correct. No one really wants to hear that.
• To manage the workload, companies often bring in contractors or temps for some portion of the testing. This short circuits the learning process for employees and often leads to missed items by non-employees who don’t have the necessary organizational knowledge.

The better way is transactional testing. Test transactions that have been completed in the legacy system by passing them through GP. The expected outcome is known and there is no reason to think that the 1,000 posting of a type of transaction will be different from the first 25 that were tested.