This section lists the most common failings made during email migration projects — as experienced by the author.  They are listed in no particular order.   The likely impact of each failing is also listed, along with any suggested mitigation.  Email me any others I have missed !

Of course, failure is not encountered only during email migration projects.  Lessons in failure, and how not to fail, and can be learned from many areas in life, such as sports, politics, and business.   If you, or someone else, fails at something, try and evaluate why that failure occurred, and work out what you would do differently to avoid that failure.

Poor User Communications:
By not communicating adequately with the users during the migration, the users will not be on your side.  This will result in negative sentiment for your project, which may filter through to senior management.    A tip here is to remind everyone that you are expecting a week for everyone to get used to the new email client, and to put off non-essential calls to the Helpdesk.  Make sure the company Intranet is used to post a regular series of updates on the project, along with links to training material.  Setup a mailbox to which people can email to ask project related questions.

Incorrect Hardware Specification:
If the server hardware you have purchased for the new email servers has not be specified correctly, it may result in poor performance.  This may lead to complaints from the users, and the project having to order additional hardware, affecting the budget.   Note: with Exchange 2007, the amount of memory in the server is of key importance.

In addition, your project will generally require additional temporary hardware to effect the actual migration. Often, low quality hardware is secured for this purpose, which can fail during migration, or result in a slow migration.  You are advised to secure high quality enterprise-class server hardware for this purpose, racked to the same standard as a production server.

A suggestion would be to use a server from another project, or a newly ordered server.   Do not use old PC’s or out of service servers.   If your migration has to run within a tight timeframe, you do not want to have to manage the hardware failure of a key migration server in this critical period.   The message is clear – do not try and save money on the hardware !

No Recovery Plan:
What will happen if your new email server fails on Day 2 after the “go-live” day?   You will need a recovery plan in place that has been tested, so you are confident of recovering the email service to your users in an agreed timeframe.   This may be utilising a stand-by server and the dial-tone recovery feature of Exchange 2010, followed by a tape restore.  Ideally you will have already tested a recovery procedure prior to migrating any users.   Often overlooked in a recovery scenario is how to redirect the Outlook 2010 client to a new Exchange 2010 server, as the MAPI call to the failed server will cause Outlook to not start.

A tip here is to use a DNS CName that references the Exchange Server, and have Outlook to refer that DNS CName when it starts for the first time.   Then, during a recovery scenario, you can use the login script to change Outlook back to the “first run” state, and update the DNS CName for Exchange to your stand-by server.   Then, Outlook will be able to start normally for users, utilising a dial-tone mailbox, for example.   Autodiscover may help you in this area also, as long as it has been correctly implemented.

Ensure there is a link to OWA on the company Intranet also, as this provides an easy method for users to access their email without having to use the full client.

Change Freeze:
Ensure that your business has a freeze on any other technical changes during your migration period.   You need to prevent any other work impacting your migration.  An example could be server patches being deployed during a migration weekend, resulting in the email servers rebooting during the migration, resulting in migration failures.

Make sure you are talking to Change Management during this time.

Lack of Testing:
Having a pilot migration will provide a good level of testing, but ideally you will have already tested the main components of your migration.   A common area that can be focused on is the deployment of the Outlook client, as this usually coincides with the email migration.  The Outlook client would be activated on user’s PCs on Day 1 “Go-Live” usually via the login script.  If this process fails then your migration will be seen to be a failure, even though you may have migrated all the mailboxes onto Exchange successfully.

Getting the Outlook client deployed and configured is a complex task, and is one that requires extensive testing.   The author has seen instances where the Outlook client has not started up for the first time due to other programs that some users have had in their Start-up folder in Windows.   It is a good idea to have a mitigation in place, whereby users can access Outlook Web Access via the intranet if they can’t login to the normal Outlook client.

Corrupt Email Messages:
Your migration may fail for some mailboxes due to corrupt messages in the legacy email system.  This is common due to lack of maintenance performed on legacy email systems prior to migration to a new system.  If you are reliant on only one migration method then this may fail to migrate these messages, resulting in unhappy users.   It is advisable to have a second migration method ready to use, as often a different migration software product will be more tolerant of corrupt emails.

For example, the author has used the Quest migration software extensively, but on average, 0.5% of mailboxes will fail to migrate due to corrupt messages.

Workarounds may include trying to run maintenance on the corrupt mailboxes, but this may not be an option, and may take too much time, as typically it will be a large mailbox.   The author has used the native Microsoft Exchange Migration Wizard to migrate these mailboxes across to Exchange successfully.  This tool, although not as feature-rich as Quest, appears to be more tolerant of corrupt messages.

No Risk Management Plan:
Similar to the lack of Recovery Plan item, management will expect some sort of Risk Management Plan.   This will show that you are including Risk Management in your project.   If you fail, and did not have a Risk Management Plan, then you are open to criticism from management.

Deviating from the Plan:
This item can relate to any technical project.  Do not deviate from your plan unless you are forced to.  Only deviate if you are unable to proceed.   It is harder to think through changes to the Migration Plan in the middle of a crisis, with all the associated pressures.  Your credibility will be questioned if you make many changes to your Migration Plan, as it will appear as if the Plan was flawed.

Badly Resourced:
You may have selected technical resources who were not capable of carrying out the email migration.   Always ensure you have at least one person who has done a similar migration before, and make that person the Technical Lead for the migration phase.    Technical people will always be suggesting “better” ways of doing the work – other than what you are trying to do.   The best argument you can use to ensure you stay on the correct path is to say that “from previous experience….. this is the best way to do it.”.  It wins every time.   There is no one way to do the email migration, but you are better off doing the project in a similar way to previous projects, rather than trying out a new method.