The Life Cycle of a Migration Project

Why?

A migration project, as most things related to Software, is not a trivial undertaking. 

It is true that migrating an application has several advantages over a green field development project where "everything goes" or even a rewrite project where it will be very hard to prevent the scope creep and the typical risks of a software project, however there are still several steps that need to be included in a migration project to ensure its success.

Having executed hundreds of these projects for over a quarter of a century, we have a very well defined methodology that ensures the success of these projects.

This is an overview of the methodology.

Getting Started

The first thing to do when you're thinking about modernizing your application is talk to us. You can see the initial call as a free consultation where you tell us about your modernization needs and we validate that our technology is a good fit for your problem and suggest options to take advantage of it.

Once we talk we'll probably ask you to execute our assessment tool on the code you want to migrate to gather some metadata about your application, give you some additional recommendations for the project based on those results and give you some ballpark pricing.

This ballpark pricing is a free quote with no commitments on your side that will give you an order-of-magnitude estimate of the cost of whatever options you wanted based on our initial discussion.Once you see this pricing and realize how much the migration project will save you when compared to a manual rewrite, the next step is to work on some formal planning for the migration project.

This article assumes a Functional Equivalence engagement and the way we would execute such a project. We have other delivery levels where we can be less involved and your team can complete the projects (see my posts on Compilation and Visual Equivalence). The methodology should be very similar for those scenarios.

Migration Blueprint

This is the first paid engagement for the project and typically involves one of our Solutions Architects visiting your team and working with them for a week defining how to approach the migration project.

Here you can read a more detailed description of everything involved in the Migration Blueprint.

After this detailed analysis we will provide a detailed document on all the strategies chosen for the migration and a fixed price for the migration project.

Starting the Project

After the Migration Blueprint we'll work with your team to get an agreement on place for the delivery level that you chose and we'll get the project started.

Mobilize.Net will assign a migration cell to work on the project and the first milestone of the project will be the project kick-off, the teams will beet there and we'll need a full development environment for the source application provided by your team. 

During the kick-off we'll define the project framework and define some miscellaneous information like the points of contact, escalation paths, initial project plan, collaboration site and other important elements.

Automated Migration 

When the project is started, the team might implement some enhancements or customizations in the migration tools (based on the discoveries or recommendations from the Migration Blueprint). This can take from a few days to a few weeks. 

After the tools have been improved, the migration cell uses them to convert the source code to the target platform. Typically this is part of a cyclic process where they will review the generated code and identify additional enhancements and places where the automation can be increased.

The code that comes out of the migration tool before any manual changes is what we call "green code". We will typically deliver this to the Client and will begin some manual code changes and the validation of the application.

Manual Changes

Not everything can be automated by the migration process and for those elements the migration cell will begin changing the migrated code to achieve functional equivalence. The manual changes are typically very concise and focused just to tackle differences in the source and target environments.

It is still possible for the migration cell to identify places where the tool can be improved or customized and an additional cycle of tool enhancements/automated migration might be executed. The new version of the "green code" will then be merged with the code that has been manually modified. We call this process continuous migration.

The manual changes will continue improving the migrated code and we will reach a couple of project milestones with code deliveries during this phase: Compilation and Visual Equivalence.

Validation

Once the Visual Equivalence is achieved in the migrated application, it's the turn of our QA team to validate the behavior of the application and ensure it works just like the original application. This is probably the most important part of the project because even though the migration process is automatic and the business logic will be maintained by the migration tools, the entire codebase was re-generated and it needs to be tested.

Our QA team requires some inputs from your team to be able to validate the migrated application. These inputs can be in the form of:

• Functional test cases
• Automated test scripts
• Manuals and documentations
• Training videos
• Training sessions

It's possible to accept a combination of these elements and it is recommended to ensure all the modules of the application are included in these materials to ensure the application is stable before delivering it to your team.

The first milestone during this validation process is sometimes referred to as "Test Case Equivalence". This will be delivered by our team when the provided Functional test cases pass. These test cases will also be automated by our team using a set of proprietary libraries (that are available for you to continue using after the migration project as part of an optional maintenance agreement).

Once this is completed, both Mobilize's team as well as your team can work on identifying additional migration bugs (i.e. differences between the source and target applications) and the migration cell will fix them as part of the Functional Equivalence Warranty. Any such bugs will be fixed even if they aren't covered by the test cases (or any of the testing inputs provided by your team).

Once all these steps are completed you should end up with a fully functional application ready to take advantage of all the new features in the target platform.

Summary

A typical migration project will have the following activities/milestones:

• Ballpark pricing
• Migration Blueprint
• Project Kick-off
• Green Code delivery
• Compilation 
• Visual Equivalence
• Test Case Equivalence
• Ad-hoc testing and Functional Equivalence Warranty

As mentioned above, we can help you as little or as much as you want and will work with you in defining what the best model for your project and team is.

Reach out to us if you have any questions or want to get started with your modernization.