Support Statement: Target Architecture Changes

Incorporating new code and new 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 the engagement with you. 

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 designs.  The thing that limits a new design is the vision, capability and capacity of developers creating the new design. 

Some source codes require a lot more transformation to fit the desired design.  However, we have found that given fixed capacity and resources, teams can complete a more ambitious upgrade if they use our tools and methods than if they work only manually (for more discussion, see this: http://www.greatmigrations.com/en/resources/myth-busters.aspx).

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.  

Beware, 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 ADODB is a very complex API that is full of surprises "under the hood" so there are still gaps.   So in our experience, most customers are happy to keep the new code close to the original design and deal with platform differences 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".  The mission for our tool set is to make it much easier to specify and implement a new target design so a team can live up to the ideals of a "tool-assisted rewrite".