...
We prefer to reduce dependencies on custom runtime frameworks whenever possible. If a customer can afford it, we will generate new code for him/her. 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 and few, if any, custom frameworks can be used on the next project. Custom frameworks can also be built to provide added value.
But make no mistakeBeware, developing custom runtime code 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 ADODB is a very complex API that is full of surprises and "under the hood" so there are still a few gaps. So in our experience, most customers are happy to keep the new code close to the original design and deal with platform differences behind the scenes. in a runtime support layer optimized for their application requirements. I suspect, the people who are not comfortable with this tend to dismiss tools from their upgrade plans and "just rewrite it". My vision The mission for our tool set is one that makes to make it much easier to specify and implement a new target design so we a team can truly live up to the ideals of a "tool-assisted rewrite".