Knowledge of the tools and frameworks that will be used in a project is often poorest at the outset. The same often goes for the team's knowledge of the legacy system. If it is not possible to identify a reasonably small MRP for the first release one should consider a delaying tactic. Develop a peripheral function that can be used both with the legacy system and the system to be. This will give the project time to learn more about the tools to be used and legacy system and thereby come up with better strategies to reduce the MRP.
The biggest problem with a delaying strategy is selling it to the customer's management. They will have very strong incentives to start immediately with the core parts of a new system. The value of building a peripheral function is primarily indirect (risk reduction). The costs on the other hand will be up front since development of the most valuable functionality will be delayed. There is also a cost associated with developing a function to work with the legacy system and later modifying it to work with the new system.
The case for delaying is very similar to that of refactoring. Both entail an up front cost that brings long-term benefits.