Migrations: It's not the destination, it's the Journey.

Often times, as with other things in life, the starting path you take on a major endeavor will determine its degree of success.  This is especially true of migrations.  That is not to say that if you get off on the wrong foot, or you’re involved in a migration that is off track you won’t be able to get it back to good.  It just means that you should make sure that when you’re beginning a migration project you do so with thought and an idea of how things will proceed.  Too often migrations are an afterthought to building the environment and getting things working.  This is a recipe for disaster, since first impressions are critical, and the migration is the user’s first experience with the new environment; right, wrong, or indifferent this will set the impressions the user community has for the new environment.  If the system is top notch with every feature under the sun, however the migration is painful with lost data; users will be dissatisfied with the new environment and want things “the way they used to be.”  People resist change, a good migration makes the change so seamless that users only see the new features and don’t feel the loss of the old environment at all.

Having said that, what are some things you can think of as a migration starts that will ensure a smooth transition?  Over the next few weeks I will be posting phases of a migration and some activities that I typically assign to those phases.  By the end you should have a decent roadmap on starting a migration or verifying that you have looked at all of the things you should have and will be able to assess the health and chance of success for any migration in progress.  Today I will just give the overriding phases and what sort of activities you can expect to see associated with those phases.

Determine Scope

While this may seem like an obvious one, often times it is overlooked or defined too broadly.  It is not unusual to start a migration with a statement like “get the users moved to the new environment.”  While a simple statement it does not give weight to the micro decisions that often brings, such as:

v  What data will be moved with users (profiles, email content, home directories, shared directories, printers)

v  Will it be moved at once or in phases, such as users and email in phase 1 and data and printers in subsequent phases

v  What will be the pain threshold management is willing to impose on user community (this will be discussed in further detail on a future blog)

v  Establish clear boundaries between what is migration and what is external dependencies (this will be discussed in further detail in future blogs as well)

Information Gathering

This is the phase where you and your team will begin to get a firm understanding of the current operating environment.  You should already know the high, and possibly detailed understanding of the architecture.  This is a more detailed examination of the environment’s health and true operating conditions.  Activities typical in this phase are as follows:

v  Gathering Metrics on the systems and getting an idea of how they are running, this will assist in determining the load that you can place or how aggressive you can be before hitting a break point.

v  Amount of data

v  Growth projections.  Often when doing a migration until a break point is reached new users are added to the old environment and it continues to be a living breathing system with growth that must be accounted for

v  Determine what custom applications are running (This will be critical later on, I will cover this in depth in future posts on this phase)

v  Determine Operating processes and how the new environment might change them, part of a migration is bridging the processes and procedures of one environment to another, it’s not just data.

Schedule Determination

Once data is collected it needs to be made sense of.  Before even determining the how it is necessary to put some thought into the who.  This isn’t to say at this phase you build the schedule for migrations and stick to it; that would be impossible with knowing the technical aspects of how to do the migration.  However there are some things that you need to know in approach that is schedule dictated that can affect the how.  These types of things are listed below:

v  Determine the best method of scheduling for your customers environment

·         Data Size – will size of data pockets determine schedule

·         Group Affiliation – Will pockets of users have to be moved together by certain types of grouping (org, geography, common data, etc...)

·         Data Location (floors, geography, common shares)

v  How are accounts going to be created?  Is there a group responsible for this or an application that is fed from a data source (HR Database)?

Customer Notification

This is often overlooked in most migrations.  It is often an email a day or two before that says “you’re being migrated”.  In large migrations there are often major changes coming and it will be critical to the success of your migration to ensure customers are educated and possibly trained prior to migration.  When I cover this section in future blogs we will talk about some strategies and things to look at to ensure all goes smooth.  It is too much to tackle in this post.

Engineer the Migration

This is the technical bits of how.  I will go into some detail on strategies for the most common things I’ve seen and will cover things that are requested by a good amount of people (I’m looking for some guidance on what to cover from you the readers).  However it will mostly look at what sort of documents and things you should be looking at to ensure that you’ve done your job of providing a proper engineering solution.

Build the Schedule

After taking in the data from Info gathering and determining the scheduling factors, adding in the actual process you should be ready to build the schedule for real.  This section will talk about things like the following:

v  Nightly Timeline breakdowns

v  Building a proper migration matrix

v  Establishing a pilot

v  Gathering metrics on Pilot

v  Generating the full schedule

v  Impact documents

I will go into detail on each of these in future blogs.

Building in Quality Assurance

This section will detail how you can build in trending and gates to check on progress, take that information, and feed it back into other sections to constantly improve and adjust your migration.

So as you can see in the up and coming months we have a decent roadmap of content that will give you a breakdown on migrations and some things to look at and think about when undertaking a large scale migration effort.  I am open to any comments, thoughts, or ideas on content.  Ultimately, you are the best judge of this content and what it should cover.  I will adjust and adapt to feedback and adjust the content based on what you are looking for.  Please let me know so that I can better target the content to you, the reader’s needs.

Be talking to you soon, we have a lot to cover.

Derrick