Migrations - A Quick Guide To Success

Migration can be loosely define as "the movement of entit(ies) from one environment to another". In a migration a steps of actions are taken in order to move from one environment to another.

Link to migration scorecard

Types of Migrations

During software development there are many types of migrations, each with a slight different use case:

• Application migration - in the case a team is moving from one type of application to another. This is typically in a customer facing application also known as 'repurchase migration strategy'. Common examples include changing software vendor, or changing a custom solution.
• Database migration - in this type of migration usually a team is moving their database from one database engine to another. For example moving from a Relational Database Engine to a Non-relational Database Engine.
• Infrastructure migration - in this type of migration usually a type is moving their infrastructure from one environment to another. This could be a version upgrade on the runtime environments.

In the next sections I will be explaining the steps you need to follow using references to flight, given the parallels between the migration of animals in the air and the migrations activities during digital transformation projects.

Step 1 - Pre - flight checks

In advance of a plane taking flight, there needs to be a plan which determines where you will be going, what route you will be taken and further considerations which may impact the success of the flight journey.

Likewise in a migration project, you will need to conduct pre-flight checks and define the following in a migration project plan:

• Objective of the migration project
• the 'To-Be" of the migration, what will the future look like post migration.
• Benefits of the migration project.
• Timeline of the migration
• Roles within the migration

A great of tracking this, will be to use a scorecard to track the best practices are being followed.

Step 2 - Take Off

Once the pre-flight checks have been established then and the migration is about to undertake. During take-off the migration plan is implemented and the change will be taking place. The following activities should be taking place:

• Reviewing of the necessary logs for any new components
• Put in place any roadblocks or maintenance messaging for impacted customers (internal or external)
• Review any error and prioritise them. If there are severe errors consider going to the optional rollback stage.

Depending on the migration strategy, Step 2 and Step 3 could overlap. As you may be testing in during the migration. In this manner it is important to have clear validation process in place, to limit the impact of the migration on the production/live environment.

Optional - Rollback

During this 'Take Off' stage of your migration there could be a situation in whcih the logs do not produce the correct picture. There could be instances in which an outage or configuration error can lead to failure of the migration project.

This decision should be taken as early as possible in the error. The rollback will typically involve pausing any migration activity and resume business as usual activity.

After the rollback activity has taken place, there should be a follow up meeting in place to discuss the error that caused the rollback.

A rollback can take place at any point on the during the 'Take off' stage and before the final release.

Step 3 - Post - flight checks

After the flight, there are post-flight checks which take place to ensure the plane can still be used. The post-flight checks in a migration can include:

• The testing of the newly migrated environment manual or automated.
• Implementing any post-migration monitoring to check if there is impact.
• Subject to accepted testing and sign-off, proceed to implementing the release strategy of the migrated project.

Overall, these steps and framework can aid the migration project success, by implementing a clear plan, managing any issues that can happen during the takeoff, and reviewing the post-flight checks to ensure compatibility with the original architectural vision.

So how can you measure the success of these steps, especially across organisations and portfolio's of work. You can use a scorecard such as this one designed by me.