How to succeed ? This section lists some ideals to aim for, to achieve a successful email migration project. They are listed in no particular order, and most will be obvious. If you have suggestions for more ideals then please email me.
Good Quality Staff: Having a good team of resources will allow you to react to unplanned events during the migration. Testing can only go so far for an email migration, leading to a good chance of the occurrence of unplanned events. How you react to these events can be the difference between success and failure. A good team of people will increase the probability of making the right decisions.
Detailed Project Plan: The Project Manager needs to have a detailed project plan which is maintained properly, working with the Technical Lead. Do not proceed without one if you want a successful email migration project
Plan for the Unplanned: At some point during the migration it is likely that an unplanned event will occur that will test your technical ability to continue. I have experienced such an event in the majority of the email migration projects I have worked on. These events can occur due to many factors, such as: lack of understanding of business systems using email, hardware failure, or staff issues. You need to be able to react and deal with these events when they occur. How can I plan for the unplanned ? Good question ! You can, by being aware that an unplanned event can occur, and by setting expectations with your Project Sponsor and management that email migration projects are not an exact science, and you will need their support if something unplanned occurs.
The only other mitigation step you can take, to ensure a successful email migration project, is to source a competent Technical Lead, so you can mitigate against not knowing what to do when unplanned technical issues occur.
Effective Monitoring: Be the first to know if there is a problem within the email system, to give you the change to remedy it before the users start complaining to the Helpdesk. A good example during the migration is mail flow between the legacy and the new email system — this could be inbound internet email. Users will not know immediately if they are not receiving internet email, allowing for the opportunity for remedial action. Monitor queue lengths or use an internet email ping service — both with effective alerting to a central screen. A central monitoring screen can be used to allay senior management fears that there is a “problem with the email system” — this is a common scenario if users have complained to the senior manager. Having visual information available that shows the health of the email system is a valuable technical and political tool.
New Features: Plan to include new features in the new email system that users will be able to take advantage of. This could be access to Outlook Web Access (OWA) for home use, or providing email on users’ smart-phones or PDAs. These will help to “sell” the new email system to the users.
Beware of Outlook OST Files: If Microsoft Outlook is being deployed with the default settings, it will enable the Cached Mode option which deploys a local copy (OST file) of your Exchange Server mailbox onto to the user’s workstation. This is to enhance performance of the Outlook client, and reduces load on the Exchange Server. Typically the feature allows Outlook clients to be used over WAN links.
Commonly, you will use this feature. But you need to be aware that its behaviour can negatively affect your migration on Day 1. If you choose to migrate the users legacy mailboxes directly into their new Exchange Server mailboxes (not to local PST files), then when Outlook runs for the first time, the new Cached Mode mailbox copy is created, forcing the copy to be made immediately.
As an example, you may have, 1000 mailboxes all 1GB in size, and a WAN connected Exchange Server, and all 1000 users start Outlook for the first time on Day 1 at 08:00am. This will cause your network to be saturated, resulting in very poor performance for all users for an extended period of time. Not a good experience on Day 1.
Here are some different example approaches you can take to mitigate this:
- Approach 1 is to disable Cached Mode for a couple of days, and then gradually enable it for all users.
- Approach 2, which the author has used, is to deploy temporary staging Exchange Mailbox Servers at each major office location, and ensure all mailboxes for that location are homed on that server. This will contain all OST-generated network traffic to be contained to the LAN, and not over a WAN. Then, after a week, move all mailboxes back to the main production Exchange Server – during non-business hours. As long as the temporary staging Exchange server is still available, the Outlook MAPI profile will automatically redirect itself to the new production Exchange Server. After a period of time, de-install and remove the temporary staging Exchange 2000 server. Make sure you are able to backup the Exchange Databases on this server !
- Pre-seed the OST files at the Data Centre. See my OST Seed blog post on this elsewhere on the website.
Support Backup: Be aware of the technical support channels that are available to you during the migration project from your vendors. If you encounter an issue, then it is a good idea to log a support call with the relevant vendor. Even if this proves to be of no use to you, your management will expect you to have logged a support call, as part of your risk management planning !
You do not want to explain why you haven’t logged a support call when you are able to !
Finally, have additional technical staff who you can call upon to provide extra manpower to your project at short notice. You never know if you may need them.
