The purpose of this document is to set the context for software modernization work and to help outline the information
needed to plan and estimate a successful software modernization project using Great Migrations (GM) tools and methods.
This document will be most helpful to individuals who are planning a software modernization project. This document assumes the audience is familiar with the Great Migrations methodology and related concepts described in The Great Migrations portal. This document will be complemented by deliverables produced in a Smart Start engagement with Great Migrations.
Contact us to begin planning your modernization effort.
The purpose of a modernization project is to upgrade legacy applications to use new technology. An example of a modernization project would be to begin with an application written in Visual Basic 6 using various COM libraries (VB6/COM) and upgrade it to a functionally equivalent, or functionally superior, application written in C# using the .NET framework (C#/.NET). In this example, we would be completely changing three fundamental foundation technologies:
The programming language dictates how developers can describe data structures, interfaces, and algorithms. The libraries provide services to the program such as data access, communications, and graphical user interface. Tools are the software that developers use to help them organize, access, and modify the system code and to debug, build, and package it for end-users. Together, the language, libraries, and tools create the "development platform". The platform sets the rules and makes the system possible.
Languages, libraries, and tools inevitably evolve and are replaced by next generation technologies. Usually, such changes are localized and gradual with an appropriate measure of backward compatibility so developers can adapt the system through standard maintenance activities. However, sometimes, the platform changes are broad, radical and disruptive. Such is the case with Microsoft ending support for VB6 and upgrading Windows development to .NET.
Failing to adapt to changing technology leaves your systems on an unsupported platform which leads to business problems such as the following:
An effective modernization effort moves your software assets to a supported platform and addresses each of the problems above to produce several benefits:
Modernization benefits are difficult to quantify and their financial impacts will vary across organizations. In many situations, the business case is made on qualitative grounds: The organization has consensus that running its systems on an unsupported platform creates a growing risk to its business. And, they recognize that modernizing the systems, the people who maintain the systems, and the processes used to maintain the systems is a highly effective and efficient means of mitigating that risk while serving a broader application life-cycle management strategy.
The key success factors of a modernization project are listed below:
Moving software from one technology platform to another is potentially the most radical and disruptive type of maintenance an organization can undertake. In order to meet the challenges it presents, a more strategic and extensive approach is needed. Our approach to platform change is the Tool-Assisted Rewrite Methodology.
The defining feature of this methodology is a staged, iterative approach and its use of a sophisticated modernization tool, gmStudio, to help rewrite the legacy source code according to the project team's unique requirements.
A detailed discussion of the inputs, phases, tasks and deliverables of the Tool-Assisted Rewrite is beyond the scope of this document, but additional details may be found in The Great Migrations portal.
Convert or Rewrite?
"Convert or Rewrite?" is an important question that comes up every time an organization is planning a modernization effort. Unfortunately, these two options are poorly understood. The fact is the VB6/COM platform is dramatically different from .NET; and moving functionality from VB6/COM to .NET presents many needs and opportunities for technical rework. So, the question is not "convert or rewrite?" it is "how should we rewrite?" and "how do we ensure success?"
This guide organizes modernization planning information into four areas:
This is an abstract guide to the types of information to gather and the questions to ask and answer. The information used to execute actual migration work will be concrete and detailed and will be organized into separate design and strategy documents, spreadsheets, and/or a formal requirements/collaboration system.
In the following sections, specific information gathering tasks and subtasks are bullets and sub-bullets. For example:
Name of Project
Desired Start of project
Desired Duration of project
The critical milestones of a tool assisted rewrite methodology correspond to periodic, typically monthly, delivery of the new system produced by the upgrade solution and measured according to specific quality metrics. Stakeholders may want to define additional milestone targets and deliverables for the effort.
Table: Milestone Chart
Description / Deliverable
The fundamental functional requirement for a modernization project is this: The new system must be functionally equivalent, or superior, to the legacy system.
In order for this vast, vague requirement to become useful for work management, it must be broken into a finite set of testable functions and organized into an outline.
Function Name The names of the requirements in the following hierarchy: application, major functional area, minor functional area, testable function, alternative scenarios.
Purpose Function Purpose The high-level purpose of the application function.
Objective Migration Objective The new system may omit legacy functionality that will not be carried forward; it may have functionality that is expected to change, and it may add functionality that will be new. Indicate this modernization objective for each function as follows:
Testability Each function must be testable. The test readiness for each function may be graded as follows:
The primary focus of platform modernization project is the technical upgrade. Like the functional requirements, the technical requirements can be organized into a hierarchy of measurable upgrade and redesign features. Technical requirements are organized into several areas:
A framework for technical requirements may be created by an automated process using gmStudio to inspect, interpret, and report on the legacy system. This information may be loaded into a SQL database for additional consolidation, transformation, and analysis. This framework will contain a vast body of detailed information; however, it is only a framework. Additional analysis and creative thinking is needed to add critical information such as: purposes, upgrade strategies, and other insights. Useful technical requirements require subjective input from people who are familiar with the legacy code, the legacy application roadmap, and the organization's rules, standards, and guidelines for building new software on the target platform.
One of the key artifacts used in planning a legacy modernization effort is the detailed As-Is Inventory of the legacy system. These metrics include data about the structure and size of the legacy system. This information produces a Source Structure Model that will help organize other information, and activities like redesign and verification.
Note: the metrics information above can be gathered using the reporting capabilities of gmStudio (even the Trial Edition). We also offer a service, the Smart Start Package, to help teams gather, organize and analyse this information from a system.
One of the most important drivers of effort in VB6/COM modernization is upgrading COM components and controls to appropriate .NET replacements. There are three parts to doing these replacements:
Another important driver of effort in VB6/COM modernization is the intra-dependencies among parts of the applications. This information impacts how the work is ordered and also identifies opportunities to improve how different parts of the legacy application interact with one another.
Entry-point (a.k.a. Win32 SDK) API dependencies are another legacy platform dependency that most teams would like to avoid when upgrading to .NET.
Entry Point-API dependencies vary in if/how they can be upgraded when moving to .NET. In some cases, .NET framework classes are available to provide the legacy SDK services in a managed way; this typically requires some manual rework. In other cases, the new code will continue calling legacy APIs but some adjustments may be needed to ensure those calls work correctly. It is also common for a code to declare APIs and supporting data structures that are not used. If desired, these unused elements may be identified and removed with the help of gmStudio as part of the Dead Code cleanup.
The VB6 language and runtime environment are very different from .NET languages and runtime environment. Most VB6 applications have features that can only be preserved either by redesigning and reworking the application code or by using a VB6 emulation framework to provide backward compatibility. Gathering information on the frequency and distribution of incompatibility issues in the legacy system and formulating upgrade strategies that meet the needs and standards of the organization is an important task in planning the upgrade effort.
List the distribution and usage of various VB6 language features that may require special attention in .NET such as:
App Object, As New, Collections, Conditional Compilation (#if, #else, #const), Deterministic Finalization, Data Binding, Data Designer, Drag and Drop, Dynamic Code (TypeName, TypeOf, CallByName), Error Handling, File IO: text, binary, Gosub/Goto, Graphics Functions (on Form, on Printer), Implements, Implicit type conversions, IsMissing, Null handling, Printing and Printer Object, Property Pages, UserControls, UserDocuments, Weak Types (Variant, Object, Form, Control, Any), and application-specific problems you may know of.
Configuration management relates to version control, builds, and deployments of a system. A large platform upgrade introduces a vast amount of new code to be versioned, as well as new tools and standards to be used for builds and deployments. Consequently, configuration management changes must be defined and planned as part of the project.
Moving an application to a new platform may introduce unexpected changes in performance and scalability. Consequently, performance and scalability requirements must be defined and planned as part of the project.
In addition to the core technical upgrade requirements in a given VB6 to .NET upgrade, there are many potential improvements that organizations may want to include in their project. Including these requirements goes beyond the must-have requirement of making the application build and run correctly on .NET. These requirements move into more subjective value-added, should-have and nice-to-have design features and process improvements. Adding these features to your project may have a big impact on the effort and risk of the project as well as its potential benefits. Some examples of optional requirements are listed below.
Testing and verifying each upgraded application is a critical part of every modernization effort.
Note: Great Migrations offers a UI testing IDE and execution engine that wraps MS Coded UI Test (as distributed with VS2013 Premium). We call this gmTest. gmTest can help the test team develop and use readable test scripts that can automated UI testing during and after the upgrade project.
Please elaborate on your testing requirements and expectations for this project.
Even after the new system has passed all acceptance tests in a 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 careful planning, execution, and 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.
The following roles are typically needed on a legacy modernization project:
Project Manager – based on knowledge of the overall work plan and external factors that might constrain and impact the modernization effort, this resource will coordinate the work, facilitate approval of deliverables, and ensure successful closure of the project.
System Architect -- based on knowledge of the source application and the desired architecture design, standards, and constraints, this resource will help formulate and approve technical decisions, articulate a clear and consistent vision of the desired system/application architecture, and identify and close gaps between current and desired technical design.
Modernization Specialist -- based on knowledge of gmStudio and gmStudio upgrade solution development, these resources will help develop technical requirements and implement, improve, and maintain the upgrade solution over the course of the project.
Application Developer -- based on a strong working knowledge of the existing code and of .NET technology, these resources will facilitate problem identification, analysis and resolution and provide technical requirements and other research needed for the upgrade solution.
Software Configuration Manager -- based on knowledge of the legacy source code structure and version control and a detailed understanding of standard builds and deployments across environments, these resources will provide requirements for and support implementation of builds and deployments of the new system.
Network Engineer -- based on knowledge of the access security, networking, workstations, and servers in the project environment these resources will provide infrastructure and network access support for the project.
Database Administrator -- based on knowledge of the databases and database servers used by the legacy and to be used by the new systems these resources will provide database administration support for the project.
Quality Assurance Team -- based on detailed knowledge of the application functionality and the processes to verify it, these resources will provide the detailed test case documentation, and test scripts needed to setup and conduct comprehensive regression testing of the application.
The expectations for ongoing communication and knowledge management vary from project to project. GM typically sets up a secure WIKI for general document management, and an issue tracker for work management. We use the Atlassian products: Confluence WIKI and JIRA Issue tracker. In addition, GM will typically plan for periodic project status meetings with the project management team and periodic technical meetings with development and technical team; separate meetings for the quality team are also common. The frequency, duration and format of meetings will vary.
Each organization has different conventions and standards for project and technical documentation. A typical project will have overall project planning and estimation documents as well as a variety of technical design, and testing-related documents. Furthermore, gmStudio is driven by various rules files, and many details of the upgrade solution will be documented in those files.
When using gmStudio, the vast majority of the code upgrade is automated and repeatable; however, there may be specific sections of code that are more efficiently upgraded by hand. The products of this manual work may be integrated with the rules that drive the automated processing making those results repeatable and automated as well. For some parts of the application, the decision to use manual rework and development may be known in advance. When this is the case, the plans for manual coding should be documented and considered when planning and estimating the project.
Because the tool-assisted rewrite produces a repeatable solution, it may be applied to a changing legacy system with very little disruption. Consequently, a legacy source code freeze is not required during the project. The Tool-Assisted Rewrite methodology allows for the source code baseline to be updated when the legacy application has a major release to production – typically once every 2-3 months. Some work is needed to set up and verify the source and the upgrade solution each time a new source code baseline is introduced, so it makes sense to describe the legacy application release forecast during planning.
Some organizations prefer to upgrade large systems or collection of applications incrementally, as a series of separate independent upgrades. A typical scenario is to do the smaller independent parts first to gain experience and refine processes before attempting huge, complex systems. This "ramp up" strategy can reduce risk and improve efficiency as lessons learned are accumulated and integrated into the solution for each successive effort. Optionally, separate upgrade efforts may be done in parallel. Working in parallel can reduce the overall duration of the program, but requires more staff and more coordination if lessons learned are to be shared across teams.
One of the most critical aspects of a modernization project is the final acceptance and closure process:
|Table of Contents