The Devcontrol’s way to migrate your existing Visual Basic applications is not only a set of software tools. It is a complete process with well-defined deliverables; they all are used as a template for your migration project. We call it the Devcontrol Migration Process (DMP). We can evaluate each transformation project at its start, provide clients with a fixed cost proposal, and deliver a successful conversion at a fixed cost and delivery date by utilizing Translation Studio, and in particular, its finely-tuned Migration Methodology. This text briefly describes the DMP in terms of its organizational roles, activities and deliverables.
The DMP defines a set of activities with incoming and outgoing objects. The units which perform the activities are: the Project Team and as we call it the Task Force.
The Project Team is staffed with members who perform the migration of an application. This unit ideally consists of resources skilled in the platform to be migrated from, i.e. Visual Basic, as well as skills in the target platform such as .NET or Java and J2EE. It has to be one Project Team per each application to migrate.
As shown in Figure 1, to the right, the Task Force is a centralized cross-project unit that has a coordinating and a problem-solving role, i.e., a large migration effort may include many migration projects but only one Task Force.
 |
Figure 2, to the left, illustrates the Devcontol Migration Process. The process is grouped into four phases:
|
Each phase has its own focus and goal and holds a set of activities performed by the Project Team and the Task Force. Within each phase the activities are performed in a highly iterative manner thus the DMP is not a waterfall process.
Note that the DMP does not define all the activities needed in a large migration project. It only defines the activities that are directly related to the migration of the source code. The DMP could easily be used together with established software development processes, such as the Unified Process or DSDM. The phases of the DMP could for example easily be mapped to the four phases of the Unified Process.
The goals of the Analysis Phase are to define the scope of the migration effort, to estimate project time and costing and to plan the migration project based on these facts. The phase includes two activities:
- Application Analysis performed by the Project Team
- Analysis and Design performed by the Task Force
During the Application Analysis in the Translation Studio suite the Project Analyzer and the Application Analyzer tools are used firstly to derive statistics based on the application source code and, secondly, to create listings of all situations that must be handled manually.
The Project Team also defines the scope of the migration project in terms of a use-case model and a use-case specification for each use-case to migrate. These use-cases are later used to plan to project and to create test cases from.
The listings reported by Translation Studio are used by the Task Force to analyze and design solutions to these different situations. For example, the Task Force may design a new component for the target environment or prepare for reusing an existing component. These deliverables are the macro targets that must be brought in on time and on budget. Understanding that these deliverables are the "finish line" of the project, a careful plan is then developed to define each step in detail.
The migration of the source code is performed during the Conversion Phase. The goal of this phase is to create a first non-customer-specific version of the migrated system.
During the Conversion Phase the Project Team uses either the VB2ASp.NET Compiler or the VB2Java Compiler in the Translation Studio suite (or any of the other cross compilers in the suite). This is the heart of the DMP.
The Compiler is the highly automated, compiler-like translation engine that captures and converts the business rules inherent in Visual Basic applications without any human interpretation, guaranteeing an accurate transformation of all business logic with significantly minimized risk. It produces either Java equivalent application of the original Visual Basic application in terms of look and feel, functionality and application design or it creates a web-architecture multi-tiered application based on either ASP.NET or J2EE and Java Server Faces.
The Task Force is contacted to solve any problem that emerges during this migration. It can happen that the Task Force may already have a solution to the problem based on another migration project or it may decide to incorporate a solution to the problem in close cooperation with Devcontrol’s representative into a customer-specific ad-on to the Compiler.
The activities in this phase are performed in an iterative manner until a stable converted system is reached.
The goal of the third phase, Refactoring and Test, is to create a migrated system, adjusted to your enterprise platform and tested for deployment. Refactoring might for example include repacking of the Java source code, or introducing the use of java-specific patterns. The activities in this phase are done in iterations. The number of iterations is based on the size of the migrated applications as well as the number of customer adjustments to be incorporated. The input to this phase is a number of situations from the listings of the Analysis Phase that the Task Force has decided to handle as a customer adjustment.
The Task Force defines customer adjustments, which the Project Team incorporates with the migrated system. Examples of such adjustments are adherents to existing organizational guidelines and templates, integration of security mechanisms such as single-sign-on, or logging.
The result is a fully customer integrated and migrated .NET or J2EE system. However the migrated system needs to be tested. Extensive testing is critical to the success of the project. Extensive testing includes pre-delivery testing, system and business-flow testing, automated test scripts and more. Ideally, fully automated test cases are created from the use-case model for both the existing system and the migrated system enabling the same test cases to be executed “side-by-side” on both systems. Additionally, we work with clients to ensure that their test plans and scripts exercise the target applications sufficiently to ensure there are no surprises once deployed to their user community.
Lastly the tested migrated system is to be deployed on to your specific deployment platform. The project team deploys the system and works in parallel with any specific system documentation. If the project is a first pilot project for a more large-scale migration effort, this documentation may also include collecting and reporting key metrics used for estimation of the complete effort.
Using the Translation Studio together with the Devcontrol Migration Process adapts to meet your unique business and technology requirements and ensures that your migration projects will succeed without fail – on time and on budget, with full data integrity and application logic retention, minimal downtime and maximum end-user transparency. The company's growing roster of satisfied customers acts as a testament to the power of the solution.
