Migration Planning
Planning for the migration is critically important and you will need a detailed project plan to work against. That plan will vary according to the size of the project. Some key elements in the planning phase are listed here:
Project Technical Documentation:
In my experience you need full visibility and agreement on a set of key Technical Documents to ensure no deviations are forced upon you during the project. Start with a High Level Email Migration Strategy that any person can pick up and read to gain an overall understanding on what will take place. From that document other more detailed documents can be written until all areas of the migration are covered. You need the business to understand and agree on the High Level Email Migration Strategy.
Communication Planning:
Keep your users informed on what is happening during the project. This could involve information on the company intranet or wall posters. Let them know that email migration is on its way and they will be affected. A good tactic I have seen is to hold a competition to see who can reduce their mailbox by the most amount, the winner receiving a prize. This gets people involved and gets them talking about it.
User Expectation Planning:
People do not like change. Migrating to a new email platform is a major change for most normal users. You need to make them aware that change is on the way and that there will be disruption for a limited period of time whilst they get used to the new email client.
Project Metrics:
Agree with your project sponsor a set of metrics by which your project will be judged. One of the most common, and potentially damaging, feedback from users is the comment “email is broken”. Users are normally happy to find fault with an email migration project — and this can soon spread amongst the user community and damage the reputation of your project.
What does the complaint mean ? That user’s Outlook client may be broken, or their PC may be off the network, or their password may have expired. As feedback, the complaint is of little use to the Technical Support Team, and needs further qualification. That much is obvious.
However, at a project-level you can’t stop this sort of feedback, you can only manage it. It can be managed by agreeing some metrics by which your project will be judged by your Project Sponsor.
An example metric would be:
On Day 1 after migration, are 95% of users successfully using their new email client and can send and receive internal and external email.
This is my favourite metric and one I have used across many email migration projects to change management opinion of how successful the project has been. How can this be measured ? Easy — On the night before the Day 1 “Go-live” day on the new email system, send a new Outlook email (from a system mailbox) to all the user mailboxes with a subject line of “From the Email Team — please open this email”. Then, importantly, tag the email with the Request Read Receipt, and Request Delivery Receipt options. And send it. Monitor the system mailbox Inbox and you will see the Delivery Receipt come back in to show the email was delivered successfully. Then, when you are in early in the morning on Day 1 “Go-live”, have Outlook open for the System Mailbox, and watch those “Read Receipt” acknowledgements flood into the mailbox.
Then, when anyone attempts to claim that “email is broken” or your project is a disaster, you can just say, for example, “Well, it is now 9:30am, and we have 400 users actively using Outlook out of a total of 500 users. Please can you explain what metric you are using to back up your claim, as it looks successful to me ?”
Roll-back Planning:
A common question from senior management across all the email migrations is this:
“How do we roll-back during the migration if we hit problems ?”.
You need to be able to answer this confidently, otherwise you may not be able to proceed. Risk management is critically important from a technical and political point of view. At all points in the project you need to be able to roll-back all the changes you have made. This could be rolling back the internet email routing change to the new email system, or moving a mailbox back to the legacy email system.
Training:
Offer training to users on the Outlook Client. Many users will be familiar with the Outlook Client, but some may not be. The users may not wish to do training but you need to ensure you are seen to be offering it.
Personal Assistants:
How do the Personal Assistants manage their Manager’s mailbox/Calendar. Will this change under Outlook — most probably it will ? Keep the Personal Assistants on your-side, as they are unhappy they will complain to their Manager — who will complain to you ! Keep them informed, and ensure they get special attention from support staff after the migration.
Who to Migrate ?:
When the time comes to carry out the actual migration of mailboxes, you need to have an accurate list of users who are to be migrated. Often, it is difficult to get this list finalised. You are advised to put this list into Excel and use it to track the migration status of each user. Also, ensure you have a unique identifier for each user, to avoid mistakes with common names being mixed-up – such as more than one “John Smith”. The author has used the user’s smtp email address to provide the unique identifier, alongside their Active Directory login id as a backup attribute.
You may wish to consider updating a user’s legacy display name in the legacy email system’s address book with a suffix of “- Migrated to Outlook” to help clarify where each user resides. This is more useful during any co-existence phase of a migration.
Global Address List:
Ensure that the Global Address List in the new email system is accurate and displays names in the expected format. Check the format in the legacy email system – it may be “Firstname, Surname”, and then check the new email system – it may be “Surname, Firstname”. It is an easy item to overlook, but with the integration of Exchange with Active Directory, the author has seen this happen.
This may also be an oppurtunity to tidy up the Global Address Book. Often, the first entry may make the list look untidy if it is not a normal mailbox name. A good example would be to introduce a dummy mailbox with the name ” ** Company Global Address Book **”. Make sure you use the ” ” character at the start of the Display Name field so the name appears at the top of the Global Address List.
In addition, you may wish to group all Resources together by adding the prefix of “RES_” to the start of the Display Name. Users will then be able to quickly navigate to them from Outlook.
Tracking:
Setup a spreadsheet that contains the complete list of users who are to be migrated. Include their user login names, email address, and full name details. Add columns to cover events such as new Exchange mailbox, migration completed, and any other key migration events, such as setting a forwarder, or archives migrated. Lastly, add a column to track the successful migration, and a comments field to cover any errors. During the migration it is important to record any errors or problems, and press on to complete the overall migration. Then you can re-visit the errors after-wards.
Do not be distracted by individual errors during the main migration events. They can distract and delay you. However, if there are multiple common errors encountered, then these may point to a wider issue, that may need addressing with more immediacy.
Also, if any users need to be rolled back, you need to know the exact state of all your users during the migration.
x
x
x
Collaboration Partners:
