Methodology

Owned by Mark Juras
Last updated: Jun 05, 2023
4 min read

Overview – The Tool-Assisted Rewrite

The Great Migrations Methodology (GMM) is designed to migrate VB6/ASP applications to .NET and do so in a way that is "agile": producing valuable results very quickly and facilitating predictable, incremental quality improvement through an iterative process we call "translation tuning".

(tick) Agile

(tick) Iterative

(tick) Scalable

(tick) Repeatable

(tick) Measurable

(tick) Improvable

Each iteration has the following steps: Preparation, Migration, and Verification.

Preparation means capturing your migration requirements in the tool's configuration. At a minimum, Preparation is three tasks:

  • Specifying the location of the legacy code that you want to upgrade  
  • Specifying the .NET language to which you want to upgrade (C# or VB.NET) -- our default is C#. 
  • Specifying the version of .NET framework and IDE you want to use -- our default is .NET 4.0 and VS2010.

Translation (aka Migration, aka Tool-Assisted Re-Writing) means using the tool to produce an upgraded version of the legacy code that is written in a chosen language and compatible with the target platform.

Verification means determining how well the translation meets your requirements and deciding if you should do another iteration by tool or finish the task by hand.

The Preparation, Translation and Verification steps are done several times each time refining the design of the target application and the conversion process. The process of moving from the proverbial "first translation" into iterative "translation tuning" is a smooth one as the initial preparation work sets up your migration workspace and produces the baseline scripts that you can refine in subsequent tuning cycles.

 Cut-Over means doing your final translation of the source codebase. When the team decides that the conversion process results are "good enough" and the only issues left are those that were determined to be easier to fix by hand, they do a final translation. This is followed by a short Fit & Finish phase to certify the new system and deploy it to production. 

When to Cut-Over?

The impact and cost of using gmStudio in your migration effort can vary widely depending on how you use it.  

Periodically during the migration project, the team must evaluate their situation and decide to do one of two things:

1) stop improving the quality of the translation process and take the resulting .NET code forward "by hand" (i.e., Cut-Over)
or
2) continue improving the quality of the automated translation process to reduce the work needed to finish the job

Optimizing the allocation of project budget used for automation requires considering factors such as the following:

  • legacy system size/complexity
  • nature and pace of legacy system changes
  • acceptable duration of the transition from cut-over to production
  • team capacity and capability to complete the transition
  • productivity gains versus costs of improved automation

There is no mathematical formula for unifying all these factors to predict the optimal investment in translation tuning, I wish there was. And, these factors are very difficult to quantify. What I can say with some certainty is that a team should Cut-Over only when they are confident that the amount of work needed to finish the job by hand fits within the time and resource available.  Said another way, a premature Cut-Over means you will run out of allocated resources before you complete the upgrade project. As long as the work required to finish the job by hand is greater than the time and resources available, the team should continue investing in improving the quality of their migration solution.  In some situations, a team may decide to suspend work on the migration for a few months, then return to it when resources and priorities allow.

A Phased Approach

It is common to divide a tool-assisted rewrite into three Phases: 

  • Standard Upgrade, producing a “direct” translation of the legacy code that builds in .NET that is ready to be modernized and refactored
  • Custom Upgrade, producing a custom version of the translated code that satisfies specific technical requirements and is ready to be debugged and tested
  • Verification, producing a system that is verified to satisfy functional requirements; verification is often done iteratively while fine-tuning technical upgrade features

 

Beyond the Conversion

In practice, a serious .NET adoption effort requires much more than running a tool. For example, preparation typically includes defining architecture and development standards and developing or acquiring new architecture components. Likewise, verification typically includes proving functional correctness (through systematic regression testing), checking conformance to new standards (through code reviews), and ensuring production readiness (through various technical tests). Finally, translation typically goes well beyond the proverbial "straight conversion" to include extensive automated restructuring, incorporation of hand written code, and replacement of legacy APIs and COM components with .NET equivalents or upgrades.

gmStudio was specifically designed to help you go "beyond the conversion" It is flexible and customizable with respect to translation and it is comprehensive with respect to preparation and verification. Our intent is to offer a product that dramatically reduces the cost, risk and disruption of large, technically ambitious efforts to rewrite VB6/ASP/COM software to take full advantage of .NET.