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.

Determine Scope

Whenever starting on a new Migration it is easy to allow things to be oversimplified or just neglected.  I hinted at this in my first post.  I will be going into a bit more detail in this post on what sort of things you should be looking at and where some pitfalls are around migrations.

Let’s face it, migrations are usually an afterthought to the design of the new system and really not budgeted for.  So typically it’s “ok the system is up, now let’s start cramming users into it.”  Anyone who has had the misfortune to be a user during one of these migrations knows that usually the experience for the end user is absolutely woeful.  Most times you just get cut over, all of your settings are gone, Outlook profiles are gone, and you might have your mail in a week or so, along with many calls to the help desk to get access to shares you had access to before.  In addition management is unhappy because call volume shoots through the roof, and their experience and settings are gone as well.  A properly planned and implemented migration should prevent all of this.  It does take some forethought and most importantly understanding from the management.

Getting On the Same Page

I can’t stress how important this is for migrations.  If someone says “hey, we need to get users over to the new environment” and this becomes the operating guidelines for a migration, chances are a tech is going to use a tool to migrate user accounts and then say “Ok your done.”

Well what about passwords?  Standard, migrated, or new?  How are they being communicated to the customers so they can logon?  Do they know how to logon to the new environment and not their old accounts?  What will change?  How will they get to data they had setup with shortcuts before?   All of these questions if not answered lead to more trouble ticket calls.  And that is assuming that what was desired was in fact just user migration, more than likely they wanted mail and other services migrated too.  This goes back to getting everyone on the same page.

“Gee Derrick how do we do that?”  Communicate. Communicate, Communicate.  One of your biggest tasks as a migration engineer will be to educate your customer and management on what it is they are undertaking and prepare them for what a migration really is.  And what is it really?  Migrations are projects in themselves.  They should be given the same consideration and weight that any engineering effort has, such as designing an Active Directory or architecting an Exchange 2007 design.  What are some of the things this means to management and you should be preparing them for:

v  Cost – Most of the time there is  no budget assigned for migration and as such every time anything needs to be done to assist, be it software license for the tools, or hardware to run them from, there is no budget thus no way to quickly get these resources.  Working with the customer and preparing them from the start that often there are costs associated with the process of migration you will be setting up the future for success.

v  Resources – In every migration I’ve done there is never the concept of assigned resources to perform the migration.  It’s a hurdle that we have always had to overcome.  The bottom line is migrations take resources.  Resources have to come from somewhere.  Either you should prepare the customer so they are ready for the expense or are thinking of the impact if they choose to use in-house resources.  Really the options are budget for resources from a provider, which will cost money, or use in-house resources.  However if in-house resources are going to be used it will be your responsibility to educate the customer on what this means to them.   Often customers assume that the email guys or directory guys or general IT guys can do the migration.  Most migrations occur either at night or over weekends to ensure that users are logged off or incase anything goes wrong.  This means that those resources are now working many extra hours and are not available to perform their normal work the rest of the time.  This means your taking either a financial hit or a service degradation hit.  Either way Resources aren’t free.  This should be communicated early on, just in case a new contract needs to be created and people hired, this takes time.

v  Time – Migrations for large organizations don’t happen overnight.  Contrary to the thought that you can flip a magic switch and everything will switch over migrations actually take time.  How much time. . . well that depends on the other factors.  The concept of Time, Money, and Resources playing off each other is nothing new, but in case it is here’s a quick 101 for you http://en.wikipedia.org/wiki/Project_management it’s the section on Traditional triple constraints.  Basically the concept is these forces play off each other, if you want it quick then it’s going to cost more money and more resources, if you do it with less resources it will take more time etc. . .  Work with the customer to find out what the right balance is to meet their needs.  What you can’t do is say we will do it with few people, for cheap, quickly.  If you do it will come back to bite you.

What’s the Approach?

I’m not talking about the technical hows, you’re not even close to determining that yet.  What I mean by this is “what is the approach for the entire migration?”  What will you be moving and what will you be leaving behind for good, or temporarily?  Many large scale migrations happen in phases.  I am a huge fan of this approach for a few reasons.  One is it allows for victories along the way.  This makes management feel that something is being accomplished as well as the migration team.  It’s difficult to work on something for a year and have nothing to show for it except really good migration plans and groundwork.  It is critical that whatever approach you choose everyone is on board with the decision and that is the message that gets carried forward.  If the choice is to lay a foundation and build on that then the milestones need to be communicated and relayed up the chain so that everyone knows what the steps are and rough timelines.  Another approach is to do all of the pre-staging and then in one fell swoop take all of the accounts and turn them on.  This is possible but it absolutely requires information be exchanged at all levels.  This is because these typically involve months of work with no tangible results and then in one weekend huge results.  If there is not good communication it’s very easy for management to think nothing is happening from the migration team.

Pain Threshold

All migrations are painful.  I don’t mean the headache you will surely have from just thinking about all of this stuff more or less the long nights you will be up performing or overseeing others perform the migration.  I am talking about the user experience.  It is not possible to do a migration without some impact to the user community.  In most cases this manifests itself as settings or customizations to the UI of programs and desktop.  Working with management from an operations standpoint, i.e. the people who deal with the customers and will endure the burden of increased call volume after a migration, to determine what is absolutely critical to bring and what is nice.  Break your features into sets of critical, nice, never.  The critical settings should be the things that users will not live without coming over, for instance certificates for users is typically in this category as users will need these to open old mail encrypted by them even if new ones are needed to send after a migration.  Nice features are those that would be nice to have but should be scoped in terms of effort to capture and let management make the decision on if this is worth the time and expense to develop a solution.  An example of a nice feature is signatures in outlook, it would not be hard to script something to dump this out to a file and bring it with you, and add on first logon.  However the cost to develop the script, test, document, and run may be too expensive for the benefit of having a signature it takes a user 5 minutes to recreate.  The final category is the never, these are the things that are either way to expense to mitigate or are just technically impossible.  An example of this would be capturing the customizations to the view in outlook, if the user turned on the reading pane and dragged it up so only 3 emails are shown and the rest is reading pane it is not possible to capture this so it is the same on the new side.

Once a pain threshold is determined you have a rough set of requirements for the migration and a start on defining the goals of the project.  The final step is to determine what your migration is not.

Setting Boundaries

As import as it is to understand what will be migrated and included in the new environment it is equally important to understand what is not part of the migration.  This is area that is often neglected and will cause massive delays, unhappy management, unhappy customers, and possibly cost overruns.  Most migrations deal with many interdependencies from other groups.  A migration will typically depend on the storage team, network team, server maintenance team, Change Management team, Help Desk, and Account management to name a few.  It is critical that all of these line up before a migration to ensure that everyone is aware of what is going on and what their role is.  I will discuss this more in the next post.

I think that is enough for now but I will drill more in depth with setting boundaries and how to deal with some of these interdependencies in the next post.

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

Hi, my name is Derrick and I'm a consultant at Microsoft.  I have been working migrations for large customers for the last 5 years and noticed some things.  One is that there isn't a really reliable place to go to get information on migrations and how to do them.  That's not to say that Microsoft doesn't give great guidance for each product they put out like the Exchange migration information found at http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/interopmig.mspx That being said there is more to a migration than just the technical aspects.  So that brings me to item two, there is no place to go to ask questions or get answers or just read about large scale migrations and the process, challenges, solutions, and otherwise useful lessons learned.

That is my goal with this blog.  I would like to periodically post items of interest and things that I am working on.  This will work best with participation from you the community so feel free to post comments or drop me an email and ask questions about anything I write about or migration related.

As the tag line says it's not the destination it's the journey, and were taking the first step today.

Talk to you soon,

Derrick