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.