Feature

Analysis
The purpose of the analysis phase for a migration is to more rigorously understand the requirements and the problems that you will face during the migration. Some examples of analysis tasks include:

• Elaborating the details of the application functionality that will be migrated.
• Identifying specific language incompatibilities between the source and target platform that will have to be solved and addressed throughout the system wherever they occur.
• Identifying legacy APIs that must be replaced with new APIs throughout the system wherever they occur.
• Identifying source code that has technical problems that must be addressed in order to provide correct results.
• Identifying features of the new platform that have sufficient ROI to warrant an investment in rearchitecting some or all of the applications to use them.
• Identifying software development, config management, and testing and deployment processes that will have to be changed to work better with the new platform.
• Identifying the system boundaries that can be used to group legacy components into "migration sets" and processed in a series of migration phases or over a series of release cycles.

In general, the analysis phase of a tool-assisted migration project will be the same as one that will be done by hand. The main difference is that an in-depth elaboration of application functionality is not done because the legacy code will be used as a detailed functional/technical spec. Also many of the technical problems will be routed to the translation-tuning team so they can be handled by the translator instead of being passed off to developers for manual work.

Design
The purpose of the design phase for a migration is to solve the problems identified in the analysis phase.

• Designing detailed solutions for replacing language program structures.
• Designing detailed solutions for replacing legacy APIs and class libraries.
• Designing detailed solutions for improving portions of code that have to be redesigned and rewritten.
• Designing software development, config management, testing and deployment processes for the new platform.

The design deliverables for both a tool-assisted migration and a manual migration are the same: documents that describe how migration problems will be solved. However, the format and usage of these documents in the two approaches are very different.

For a manual migration, designs are in higher-level documents. They are verified by developers as they are used; recurring problems typically go unreported as most developers choose to implement solutions and move on rather than try to get the documents changed. Deviations from the published standards may be addressed after the fact, if code reviews are done and followed up on; otherwise different developers will solve the same problems over and over again.

In the GMM, the design docs become the translation configuration (see sidebar: Translation Configuration). The configuration is written in a formal XML-based notation that controls the translation toolset. The configuration is verified by an iterative process called translation tuning. Translation tuning uses manual and automated code reviews, builds, and a variety of runtime tests to identify issues in the translation and address them in the translation configuration. (Sidebar 4)

Construction
The purpose of the construction phase for a migration is to implement the new application on the target platform. Migration projects often require a tremendous amount of construction work because they have to deliver a mature business system that evolved over many years to provide many functions. Even if a translation tool is used, there may be a fair amount of original coding needed to create the architecture components required for the foundation of the new application. An additional type of construction typically done for tool-assisted migrations is the construction of small test codes, built on the legacy platform, and used to provide isolated tests of specific translation problems.

The majority of coding, however, is automated - the conversion of application business logic is handled by the tool. Promula Technology allows you to translate an entire migration set - often hundreds of thousands of lines of code in a matter of minutes.

Testing
The purpose of the testing phase for a migration is to verify the new application on the target platform. The testing activities are normally the same for manual and tool-assisted migration work. In the GMM, the new application will be up and running earlier in the project. This is important because runtime testing is a critical source of tuning information. Also you will be leveraging the tested legacy code as a design, and testing begins and runs throughout translation tuning, so few defects should be found after cutover.

Warning: With a manual migration you will have much more original work: new requirements were gathered, new designs were created, and plenty of new code was written by hand. As a result, you are likely to face a higher than usual number of defects, and you should plan for a longer (more costly) test phase. (Sidebar 5)

Cutover
Cutover is when the migration team takes on the tasks of finishing up the system and getting it certified for deployment. With a manual translation, this begins after design and runs through construction and testing. A manual cutover usually takes a very long time because there is so much new code to refine, build, and test. Because of its long duration, the legacy system will have to be maintained in parallel with the cutover effort - probably including merging changes.

The GMM also has a cutover, but it occurs only when the team is satisfied with the quality of the translations and is confident in their ability to quickly take the system to production and support it. To do a cutover, the latest, verified production source code is translated one final time. From that point forward, the application will only be maintained, tested, and deployed according to the rules of the new platform. The tuned translation should be very near production-ready, which allows it to be deployed soon after translation. Some post-cutover construction tasks may be needed but they are identified and planned during translation tuning, so there are no surprises. In fact, much of the work can be done and verified in advance. Translation tuning means the work is done up front so you can enjoy a quick and easy cutover.

Key Point: No need to freeze - with few exceptions, the legacy code base continues to change until right before cutover. A copy of the latest, verified production code base is usually used.

Deployment
The purpose of the deployment phase for a migration is to put the new application into a runtime environment for testing or use. This phase is essentially identical for manual and tool-assisted approaches. The one difference is that in a tool-assisted approach, the new code base will be ready for testing sooner and thus build and deployment processes can (and must) be designed and refined sooner.

Maintenance
The purpose of the maintenance phase for a migration is to get back to the business of enhancing and evolving the system - and, of course, demonstrating to your users that you are much more productive because of the new platform. In general, maintenance is maintenance whether you did a manual or tool-assisted migration. But there are a couple a subtle differences:

• In a tool-assisted migration, the new code is derived from the legacy code and so it will be familiar to the legacy development staff. This flattens the learning curve so the staff can become productive with the new system sooner.
• In a manual migration you will be running on more new work: new requirements were gathered, new designs were created, and plenty of new code was written and some details probably slipped through the cracks. As a result, you are likely to find a few more defects as the system settles under the load of production use.

Summary
A technology platform change can be extremely disruptive. No matter which approach you take, your organization will be expected to master new paradigms, change processes, learn new tools, and implement new technologies. As you plan and execute your migration, remember that although migration is extremely technical work, in the final analysis, preserving functionality is paramount. (Sidebar 6)

References

The Wikipedia Refactoring: http://en.wikipedia.org/wiki/Refactoring

Valdes, R.; and Driver, M. A Cost Model for .NET Code Conversion. Gartner Group, COM-16-1385.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...