...
The Users, the QA team, and the support teams need to should be able to routinely complete a fully documented, successful, automated regression test of the legacy app before they try testing the new app. That will keep them gainfully busy for quite a while, so we can focus on getting them a solid runnable, testable new app for testing. And it will help us maintain momentum once testing starts. Beware: The customer might decide to cancel the project before it starts if they realize they cannot rigorously test what they already have.
<soapbox></soapbox>
One more comment: one way to mitigate testing pressure is to break the codebase into smaller parts that can be upgraded, tested, and deployed independently. Some codebases allow for this and some don't. This approach makes for a longer, more complex transition where the customer exists in a hybrid state using and maintaining a mix of old and new until the last component is upgraded. Some customers are already in this state; so, they may be more accepting of it. The gradual transition approach can make re-engineering more complex because the new codes might have to integrate with old components in production.