When Quest Migration Manager was still young, and i was at lot younger, i got to go on what Quest Software calls a Smoke Jump. These are engagements that are usually not being funded by the customer, where the customer is upset, and the migration seems to have failed. My role? To show the Migration Administrator how it is supposed to work and hopefully turn them into a happy (and paying) customer again. I am successful on these because I know the top three things that make Migrations fail.
- Name Resolution
- Permissions
- Process Chaining
Name Resolution
It the Top Three reason a very common one is Name Resolution. Name resolution refers to the ability of every workstation, server and domain joined device to be able to resolve both short and long name to every server in the environment. If I can’t ping targetcomputer and/or targetcomputer.com, and vice vesra for the source, regardless of the device being joined to either source or target, then the migration tools and migration coexistence will fail.
In today’s AD environment you can easily add to the Domain Suffix list via GPO. See a Microsoft Technet article on doing this here. You don’t have that version of AD in your source or target? Then you are down to scripting a solution, WINS or doing CNAMES in your merged DNS.
Permissions
The slightly more common are permission problems. Set permissions requirements that are required for the various service accounts in use can be daunting to the uninitiated. You will need local admin rights to everything, including Exchange (if doing an Ex migration), and no pesky DENY’s from things like the Domain Admins group.
To get a feel for the various exchange permissions alone that need to be done take a look at Matt’s fine article titled Checking Mailbox Access as Part of Migration Preparation.
Process Chaining
The real big one that gets most people is what I call Process Chaining. Process Chaining means putting multiple process steps in line in the same critical path, vs. separating them and doing them independently. A good example of Process Chaining is combining the workstation migration,the user migration and the mailbox migration into a single “migration event”. They can, and should, all three be done as separate migration events, if not only to avoid process chaining, then just because each of their work-flows are different from each other. Another example of process chaining is to tie other things to the migration, such as upgrading office – do that before, or after, not during a migration.
My favorite part of doing a Smoke Jump on a migration that failed to start is what I call the Oh! moment. It is usually around noon on the second day and take the form of, “Oh! That is how it is supposed to work!”.
