Setting Boundaries

In my previous post I began discussing some of the details around determining the scope of the migration.  Once that is done the final step is to determine the interdependencies based on how your customer breaks out the IT work, and building the proper support team to handle what will become a coordinated effort.  When I mention interdependencies I am talking about the technical and non-technical things that will make up the full migration process.  To give an example, in a typical company there will be a team for each of the following tasks:

v  Mail Servers

v  Infrastructure

v  PKI Certificates

v  UNIX services

v  Account Operations

v  Help Desk

v  Communications with users

v  Storage Subsystems

v  Network Subsystems

Given that many of these groups will have some responsibility in the migration it is important at this stage to get them to the table.  The goal is to define clearly where the areas of responsibility lie so that issues can be sent to the proper source for resolution.  Ultimately all of these factors contribute to the success or failure of a migration.  However, as problems arise and need to be resolved it will be critical that areas of responsibility are established and pressure can be applied to the proper place.

Migration Team

Most organizations have already established a group of individuals to handle all of the things mentioned above.  They may have collapsed a few together to handle things that are common depending on the size or focus of the IT group.  However, it is very rare to find an organization that already has a formal migration team.  This will pose a challenge to you as a migration engineer.  As covered previously migrations are built around the same principles as all things in IT:  Money, Time, Resources.  So with this is mind it’s time to start building a team of resources.  These are typically borrowed from other groups.  If this is the case it will be critical to ensure they are dedicated to the migration and not wearing multiple hats during this time.  During a migration it will not be possible for a person to have to field a trouble ticket call or be pulled onto something else, for this reason resources must be clearly defined and linked to the migration team as a full time position.

Migrations also take time to get initiated.  Often there are many decisions that shape the choices made and process as a total.  It is important that someone responsible for migrations understand all of these and how it all works together.  Most of this is common sense,  but the reason I wanted to mention it is to illustrate that once a resource is assigned to the team and has integrated themselves into the process and the decisions made it is critical that they stay involved.  This is an area I have had difficulty with in the past.  Management will often see the migration team as something that must be manned at the night of migration and thus will sometimes add and remove people on the team as needed.  Because there is more going on the night of a migration than just performing the technical steps, when a problem is encountered the inexperience of the team members becomes a major issue.

For these reasons I recommend that forming a migration early on and allocating as many people as needed from the start has value.  If this is not possible than at least two people be assigned as the lead and support engineer.  This will allow for the loss of the resource without a major ramp up time or lack of understanding the history behind decisions made.  Determining the right number of people for the final team will be covered later, as the technical solution and environment will directly influence this.

Support Teams

For supporting the migration the concept of a virtual team should be looked at.  This is where outside of the core people the migration team is made up of members of additional teams.  This allows for one or two people from the dependency teams to support the migration effort, however they will not be dedicated full time as the core people are.  There are several benefits to this approach.  It allows for support people to continue working issues that are relevant to their team when they are not needed, and it allows for migration team issues to get resolved as they will take priority for those one or two people.

Building out the virtual team from the start and having set meetings will enable everyone to have visibility and say into the process.  This is critical from the start, as later if a process does not work for a particular team and must be reengineered it can cause massive problems for the entire migration that was built around the old process.

Summary

Overall the main takeaways are that migrations must be staffed and treated like any other IT group during the course of the migration.  Key resources should be identified early and dedicated to the process.  Constant turn around to the group will have a negative impact on the entire migration.