Incorporating new code and components is a common aspect of our methodology. New components can come from various sources, including finishing generated code. Furthermore, integrating generated code and new code on a broad scale is typically done by the tool. We already did both of these types of tasks, as planned, in your engagement.
Your upgrade project should take you where you want to go; you need to minimize total cost of conversion during the upgrade and then total cost of ownership after. Towards this end, GM sells and supports a programmable software re-engineering tool and related services. We help our customers re-implement large, complex business applications in .NET according to their new design. The thing that limits the new design is the capability and capacity of resources available, and the time constraints, not the tool.
Some source codes require a lot more transformation to fit the desired design. However we have found that given fixed resources, teams can complete a more ambitious upgrade with our tools and methods. Please consider this: http://www.greatmigrations.com/en/resources/myth-busters.aspx
We prefer to reduce dependencies on custom runtime frameworks whenever possible. If the customer can afford it, we generate new code that does not need them. Unfortunately, the deep transformations needed to rework application code to fit a completely different API can be hard to generalize. Rework requires more project-specific analysis while least custom frameworks can be used on the next project. Custom frameworks can also be built to provide added value. But make no mistake, developing custom runtime can be very difficult. For example, we have been developing an ADODB replacement using System.Data over the course of several projects. It is near complete and well tested, but it has been full of surprises and there are still a few gaps.