Methodology

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”.

:check_mark: Agile

:check_mark: Iterative

:check_mark: Scalable

:check_mark: Repeatable

:check_mark: Measurable

:check_mark: 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:

stop improving the quality of the translation process and take the resulting .NET code forward “by hand” (i.e., Cut-Over)
or
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.

Going End to End

The discussion above is very focused on technical code transformation, but there is a lot more to an upgrade project than just rewriting code for a new platform. Specifically, testing and devops processes also require a significant definition, validation, and implementation before the new system can move into test and production environments. Our full project methodology is organized into five “super-tasks”: Initiation: gathering and analysing information on the AS-IS, TO-BE, and HOW factors for the upgrade project and preparing a new system blueprint and project plan that documents scope, schedule, resources and tasks.

Application Testing: documenting and validating setup, deployment, and testing procedures for required legacy functionality. The legacy system is used to help document the expected results and validate all test procedures providing a finite functional scope for the project and providing opportunities to practice and measure the work of a comprehensive Regression Test.

Application Transformation: developing technical requirements and implementing an Upgrade Solution that transforms the legacy functionality to a form that is ready for testing on the .NET platform. In addition, this super-task includes developing the DevOps procedures and installers for reliably and efficiently building and deploying new system releases into Dev and Test environments.

Refinement: using the testing and DevOps procedures developed in prior tasks, incrementally **** verifying, fixing, and optimizing the legacy code to the point where it passes all documented and validated test cases in new environments. The deliverable is a “Beta-Ready” version of legacy as well as all development and delivery processes that are ready to support productive, efficient user acceptance testing in customer environments.

Transition: assisting **** Ardent in publishing legacy to user environments and providing support as needed.

Initially run in parallel, the Application Testing and Transformation tasks merge and continue in a Refinement task. This up-front preparation helps to ensure that the work of verifying and optimizing functionality with the new system proceeds efficiently. When the new application is certified for production use, it will be published to users in the Transition Task.