Migration Land Mines

Co-Existence 

In your planning phase, you are quickly going to find out which systems are not going to be available to your migrated users, we touched on this during the Sync and Switch migration earlier. Co-existence means that you can still do everything you could do in the old environment once you move to the new environment. In the case of email, it would mean that you can still see all your old contacts, reply to your old messages, see Free/Busy information for users who have not migrated yet, and your OST is still available, in the case of workstations, it would mean that all the shares, printers and your PC network profile is the same. For users, it means that all the applications and websites that you had access to with your legacy credentials all authenticate with your new credentials. Co-Existence is the cleanest approach to any migration, but it requires planning. 

DNS 

The single biggest problem I have with migrations is often DNS. It is critical that your DNS traverses your trust between the source and target environments, every workstation, every server, everywhere must be connected and must be available. 

Permissions 

Pitfalls often come when you are trying to authenticate to resources. Migration tools require deep permissions. Arguments will occur between different teams on who, what, where, when and why. Get a good understanding of the requirements for your migration tools. Each vendor will have a granular permissions requirement guide that will explain what they need, when and why. Socialize this document with the teams involved so they know what requirements are coming, what is just not possible and how the needs can be met in other ways. Most vendors will say they want Domain Admin, but as we all know, this is never really required, there are minimum permissions that will meet any requirement.  

Too Many Cooks 

The structure is so critical in a migration. I have heard the term “Herding Cats” used very often on some projects that have failed. Customers have felt that this more than anything made them seek a more professional approach. Just because you have the tools to get you there doesn’t mean that you have set yourself up for success. Often times customers will come to me half-way through a migration, in a state of emergency and everything has gone wrong. In analyzing these efforts, it’s obvious that there was no coordination, with too many people driving the resources in different directions. 

Not Enough Cooks 

Not having the correct amount of staff, or the correct staff, in general, can also hamper your efforts. A weak or absent project management staff or a controlling executive holding the team to irresponsible metrics or beyond their ability can cripple a project. Insufficient staff at the switch either performing the migrations, planning the lists or helping the migrated users the next day is also going to slow you down or slam the brakes on altogether. 

Process Chaining 

One of the worst headaches during any project, and definitely during migrations is process chaining. This practice can be innocent and simple at first, but it is the equivalent to a gorge between your start and finish lines, oh and its filled with quicksand! So, just what is a process chain? Most migrations start out with a single team with a single requirement. They want to move one system or data set from one location to another. Meetings are held and an investigation is done only to find out that another team would like to do a networking migration in the same timeframe as our migration project. Next, we find out that there is an implementation of a new POS system that we want to get completed during the same window. These different projects will be overlapping many of the resources that you will need to complete your migration… We try to be as accommodating to other projects as we can be, so an attempt is often made to try and bring the projects and processes together. In the above example of the networking upgrade, if we decide to bring the two projects together, we would have to wait for each office location to get an upgrade to its networking infrastructure before we could migrate that office. In the case of the POS system example, if we decide to chain this with our migration, we now must understand the new environment variables and the migration requirements of this new application in the middle of our migration. The new POS system is not even deployed yet. In both situations, your project will suffer big time. Allowing the processes to come together in a chain of events has now increased costs, complexity, and timeline. It is therefore always a better idea to keep as far from chaining your project to others as you can.