The essential objective of a Windows Application upgrade to .NET is to rewrite a legacy system for the .NET platform so that its functionality is preserved and its code can be maintained and further developed on the .NET platform. The resulting system will be a collection of .NET projects, expressed in C# (or VB.NET) and using the .NET Framework. The .NET code will meet the technical and functional requirements developed by an Upgrade Team composed of people from the client and Great Migrations (GM).
Our Agile Tool-assisted Rewrite methodology is founded on the following two principles:
The approach yields meaningful, reproducible results soon after project initiation and continues to deliver results of measurably increasing quality through a process of recurring release cycles – until all the requirements set out by the Upgrade Team are satisfied and the final deliverable is produced. Progress is visible, measurable and verifiable by inspecting, building, and testing the new application.
Figure 1: Upgrading Windows Legacy Applications to .NET using the Tool-Assisted Rewrite Methodology
The Tool-Assisted Rewrite Methodology upgrades a legacy system from a source platform to a target platform through a series of increasing-quality milestones:
Source Complete, Ready to Translate
Translate Complete, Ready to Assess and Prepare Re-engineering and Verification Plans
Build Complete, Ready for Re-engineering
Re-engineering Complete, Ready for Debugging and Optimization
Upgrade Complete, Ready for Cut-Over and User Acceptance Testing
Verification Complete, Ready for Transition and Deployment
|6||Transition||Deploy Verified System to Users|
Progress through the six quality levels is measured according to specific technical and functional criteria, as defined by the Upgrade Team, and achieved using a custom Upgrade Solution. Each Upgrade Solution is an original work embodying both the state of the legacy system and the desired end state of the target system.
The Upgrade Solution is a comprehensive framework that integrates new designs, manual work, and automated software transformation. As a framework, the Upgrade Solution supports the continuous improvement of all the artifacts comprising it:
Though continuously improving during the course of the project, a typical implementation of the Upgrade Solution has two phases of development:
Figure 2: Two-Phase Approach to Software Modernization using gmStudio
Reproducing functionality is the most critical objective of upgrade project work. In a tool-assisted rewrite, meeting this objective requires carefully comparing the behavior of the new system to corresponding behavior of the legacy system. This is referred to as Parallel Testing (aka Side-by-Side Testing).
Figure 3: Parallel Testing
Parallel Acceptance Test (PAT).
A critical body of documentation needed to complete the Parallel Testing is the Parallel Acceptance Test (PAT). The PAT consists of a finite number of reproducible test cases (inputs, steps, and outputs) and also the detailed – preferably automatic, if available – procedures for running the application, gathering results, and comparing results to verify functional equivalence between the legacy system and the new system.
GM has an automated testing tool, called gmTest, which the Upgrade Team may consider using in complementing any manual, script-driven testing procedures – when available.
The results of our work (project deliverables) will be produced by the Client in a series of regular deliveries (monthly or more frequently, if necessary), subject to a predefined schedule. The upgrade solution evolves in a number of release cycles – each cycle producing a release package that contains the following work products:
This project will be a collaborative effort between the Client and GM. GM will offer expertise and labor to implement an Upgrade Solution that meets the Client's requirements, but doing this will require input, support, and feedback from the Client to define and verify the results and to facilitate transition and closure of the project.
The Client may achieve the objectives of this project in close collaboration with GM, based on the Client's requirements and preferences. A joint GM/Client Upgrade Team may be formed to conduct all aspects of the planning and execution of the project, as desired by the Client.
In most cases, GM's role on each project is to assist with configuring and operating gmStudio or to train and support others to use gmStudio themselves. GM team members may also assist with project planning and management, technical design, and implementation of new code to be integrated with the upgraded system.
The Client staff resources are expected to contribute in the following roles:
The goal of the Standard Upgrade is to rewrite the VB6/COM Source Baseline to a .NET Baseline that builds without errors. The major tasks of this phase are as follows:
In this task we extend our understanding of the legacy application, establish a Source Baseline, and develop an Upgrade Plan for the project. For this task, GM will do the following:
In this task, the Source Baseline will be translated in order to produce a complete, first-order .NET translation. For this task, GM will do the following:
In this task, the entire Source Baseline will be translated to C# projects that build without errors on the .NET platform. For this task, GM will do the following:
At this stage, each .NET project corresponds to an application VBP and will be self-contained and independent of the others. Each .NET project will reference two types of files:
The purpose of this task is to generate a .NET Codebase that is integrated in Visual Studio .NET.
At this stage there will be two types of projects:
The .NET projects cross-reference each other based on their inter-dependencies. In addition, GM will generate a Visual Studio solution file that integrates the generated projects and allows a full build.
At the end of Phase 1, the Upgrade Team will have a clean, complete, and internally consistent .NET version of the legacy code and its COM dependencies. The .NET project files will be integrated and organized by a Visual Studio solution (.sln file). The new code will not run because the legacy platform dependencies are only satisfied by stub assemblies. The Team may decide to use the new application code as a resource to be manually "harvested" and reworked to a new design, or they may flow into Phase 2 and continue improving the upgrade solution until it produces results that closer to the required design.
The goals of the Custom Upgrade are two-fold:
The major tasks of Phase 2 are as follows:
As part of this task, the Client and GM will do the following:
As part of this task, the Client and GM will implement a Technical Upgrade process using gmStudio to integrate manual and automated code transformation rules to generate the required .NET code. For each technical upgrade requirement, the process includes the following steps:
As part of this task, the Client will do the following:
As part of this task, the Client will execute the Functional Verification Plan and Procedures. GM will assist the Client in iterating through "upgrade-rebuild-test-fix" cycles improving the Upgrade Solution as needed. Implementing the Functional Upgrade includes the following tasks for each requirement:
At the end of Phase 2, the Upgrade Team will have a clean, complete, and internally consistent .NET version of the legacy code and its COM dependencies. The .NET project files will be integrated and organized by a Visual Studio solution (.sln file). The system is verified to meet specific technical and functional requirements.
At this point the new system may be ready for user acceptance testing and transition to production or it may go on to additional manual technical and functional enhancement before release.
The Upgrade Solution developed for this system may be applied on other similar legacy systems in the enterprise, yielding significant economies of scale.
At some point during the Custom Upgrade, the new system will be sufficiently upgraded to allow functional testing to begin. Upgrade Project testing is normally done by comparing results gathered by rigorously operating the legacy and new systems side-by-side. Prior to performing the tests and recording results, the project team must define test procedures, prepare test data and environments, and install the old and new software in those test environments. We call this work the Verification Phase of the Upgrade Project. Verification is most efficiently done by an organization that is very familiar with all aspects of operating the application and working with its data. A practical discussion of Verification is beyond the scope of this document, but it will typically involve Side-By-Side Testing as shown below:
Even after the new system has passed all tests in a carefully controlled test environment, it must still be systematically and carefully distributed to users. Packaging and distribution are the primary tasks in this final phase of the Upgrade Project which we call Transition. Whether the Transition is done all at once, or incrementally over time, it will typically require care planning, execution, monitoring, as well as extra support for users. Transition is most efficiently provided by the organization that is very familiar with the application and its user base. A practical discussion of Transition beyond the scope of this document.