Here is a small checklist about how to migrate a legacy migration and to ensure its success.

This article is part of my work to explain my knowledge about Software migration in the company Byoskill.

First measure your project according the changes involved by the migration :

• The organizational changes
• The process changes
• The technological changes

The organization

You will have to think about each person involved in the Software that is going to be migrated. Which skills are required to develop, test, maintain, support the Software. How will you manage the brutal disrupt in their daily work and motivate them to embrace the change ?

I recommend you to have a clear picture of the team and not underestimate the needs of training, evangelize, and change management.

Changing technologies or framework, even without any feature changes may impact severely your end-users, the support and maintenance teams and the integration engineers.

The processes

An automated migration differs from a classical IT Software project by adding a certain disruption in terms of time and practices. Since the migration has to be hastened (thanks to the usage of specialized tools), the success of the project requires a high level of software development practices. Usually, the legacy software are still hitting the wall in terms of agility, silo breakup, continuous integration, test automation practices.

The legacy project migration requires to have a clear state (and view) of the following processes :

• SDLC : Software development lifecycle.
  • What is the current process ?
  • Is their any traps or caveheats to be aware of ?
  • How much time does it take to push a new feature from the specification to the production ?
• Test automation : You will have to answer many questions who are associated to well identified risks.
  • How the application is tested ?
  • At which levels ?
  • Are the tests automated ?
  • What is the coverage (estimated and measure) ?
  • What are the requirements to set up a new test environment ?
  • How much does it cost ?
  • Is test data available ?
  • How accurate is the test data ?
  • Which tools are required to execute the tests ? The licences
  • What would it take to obtain a sufficient coverage for the migration project ?
• Continuous Integration : 
  • How the software is built ?
  • How much time does it take to produce a new release ?
  • What are the steps ?
  • Which parts are tricky or manual ?
  • What are the components to be built ?
  • How many individual parts composes the software ?
  • Which tools are used ?
  • What would it take to obtain a complete CI/CD  for the migration project ?
• DevOps : 
  • Logging and Monitoring support :
    • Will the tools still compatible are the migration ?
  • Automatic deployment
    • What are the changes required to maintain (or obtain) an automatic deployment of the solution
  • Error and Exception handling
    • Detect and document any regressions in the current way to catch and handle the errors during the run
  • Performance testing
    • Does the software have any automated performance tests ?
    • Will they still be compatible ?
• Release Management :
  • How many active versions for this Software ?
  • What is the branch release model ?
  • Versions to maintain and port
  • Frequency of releases and year schedule / roadmap

The technologies

A good legacy migration project is preparing a clear state of the perimeter to be migrated as well as the targeted solution.

It comes in a  three phase steps.

• The actual picture
• The definition of the target
• The migration in itself

Drawing the current picture

The initial software assessment does really mater. Indeed an solution architect will detect any caveats and flaws in the current architecture that may critically slowdown the migration project.

Such assessment usually requires :

• a technology survey : which technologies are used in the software, licenses issues, exact version and possibility of upgrade
• an architecture assessment : will be controlled in priority the physical organization of the project (folders, files), the logical structure (components, package, functional and technical layers) and the dependency matrix (cycles, code weaving, code smells)
• an automated test assessment : code coverage, tests documentation, test robustness/fragility, main complex components and their level of testing.
• a code quality assesment : a quick review to identify in priority the main risks (reliability, security, maintainability)

The definition phase

This phase has four objectives :

• Get a understanding of the cost and time of the migration project
• Evaluate with the customer, the ROI of the operation
• Eliminate the main technical  / functional risks of the migration
• Communicate to the customer, the organization and process changes to be operated.

To achieve that, a main document (or specification) has to be produced, the migration guide.

This migration guide will expose the targeted solution, the way to achieve it, the necessary steps, a risk analysis and RACI, the cost and estimation of each tasks.

This definition phase may be accompanied by a Proof Of Concept(POC), a short term development performed on the current solution to assess the feasibility of the targeted solution and to allow any necessary test to be executed. It will be critical to pay attention to any functional regressions and performance regressions in this POC.

The migration

The migration is not a Big Rewrite. 

It’s an incremental, well-defined process where the automation is removing the main source of failure of migration projects : the time of execution.

Indeed longer the migration process is taking, more dangerous will become the project, debated and finally rejected.

A good migration project usually has the following qualities :

• Incremental : in some way it’s possible to have the two technological environments living as room mates in the Software
• Fast : The amount of rewriting, manual fixes and iterations to obtain the targeted solution have to be small.
• Cost effective : The volume of manual operation cost should be significantly be smaller thanks to the automation
• Critical : No legacy migration finds its justification without a real concern (Security, Investment, Scale up operation, Business loss or expectations)