Create a separate team for the migration effort

Only very small migrations can be handled without a dedicated team. Your migration needs to coordinate with a lot of stakeholders and needs a voice in the overall program portfolio.

Your team needs a broad set of skills when assigning people.

• Business knowledge of the old system
• Business knowledge of the new system
• Development skills needed to migrate data
• Technical test skills to verify the solution
• A Release and environments manager to coordinate what datasets are used in which context.
• A project manager or process consultant knowing how to orchestrate the migration project both during development and during the actual migration period.

In most cases, your migration schedule is fixed and failure is not an option. This means you should favor over-staffing a migration team and then gradually remove people when the problems are under control.

Be sure to assign people that will speak openly about challenges before problems escalate beyond control.

Be agile

The agile process really shines in the context of migration projects. It is even truer in migrations projects that requirements are only partially understood at the start of the project and needs to be refined over time. At the start of the project you only know the rough outline of the requirements, but over time you will find the anomalies in the data, the corner-cases you had not identified at the start and the oddities of the new system.

This has a couple of key implications

• It is critically important to have business resources allocated to the project during the entire project period.
• Run the migration early and often to enable your business resources the best possible view of the migration result. This will enable them to change the requirements to better suit the business needs.

Create a project room where all members of the team can communicate face to face to ensure efficient communication.

I highly recommend that you brush off your agile mindset by re-reading the Agile manifesto and in particular the Principles behind the Agile Manifesto

Know your project scope and business case

It I deceptively simple to define a migration project with the following words: “The data from the old system must be extracted from the old system, transformed to the new format and loaded into the new system so our business processes can continue in the same way they worked before.”

Framing the task like this will make the project a typical ETL project that IT people can handle.

In most cases, the above statement would be wrong since it is unlikely that the business processes between the two systems are identical. Migrating to a new system is often decided due to lack of functionality in the old system. The new system is supposed to be a new start and not be dragged down by the practices of the old system. A more common description would be:

“The data from the old system must be extracted from the old system, transformed to the new format and loaded into the new system in such a way that we gain maximum benefit from the features of the new system while getting rid of the old problems that have been plaguing us for years.”

Framing the solution like this probably expands your project into 3 sub-projects: an ETL project, a data-quality initiative, and a business development project.

Be sure to know what is expected of your project.