Do you go for a “big bang” approach and migrate everyone over a weekend, or do you migrate over an extended period ?  The “big bang” approach can be a lower cost option, and minimises the period of time when you may have to operate with users on both the legacy email system and the new one — this is called co-existence, and can lead to support challenges. This approach is high risk, as any issue encountered on Day 1 “Go Live” has the potential to affect the whole company.

Migrating over an extended period will involve a higher cost, and a period of coexistence. However, risk can be managed by allowing time for the resolution of issues encountered when the first users are migrated.   You can timetable the migration of users according to how comfortable you are with the new environment.
From my experience the best approach to aim for is as follows:

1.      Implement new email system on new hardware
2.      Cutover internet email routing to use new email system (mail is routed to legacy email system)
3.      Review and resolve issues
4.      Migrate Pilot email users to new email system
5.      Review and resolve issues
6.      Migrate remaining email users over a weekend
7.      Resolve issues

This approach tries to allow for the benefits of both approaches and minimises their negative aspects.

Email Migration Approach | Key Aspects

Internet email routing change is a major technical change in itself, and from that point on, users may be affected by changes — examples: email formatting, attachment handling.   The email migration starts from this point.   You need to minimise the time period between cutting over the internet email routing, and migrating the last mailbox to the new email system. However, you need to allow enough time to perform a pilot migration to mitigate against any unplanned issues you may not have thought of.

Email Migration Approach | 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, but some key elements in the planning phase are listed here.

Email Migration 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.

Email Migration Approach | 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 the author has 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.

Email Migration 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.

Example Migration Project Success Metric

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 ?”

Email Migration | 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.

Email Migration | 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.  In the author’s experience, users will typically not attend available training.

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.

Application Sendmail or SMTP Relay

There is a high probability that your business will contain applications that interact with email.  You need to plan for this in your Migration Approach, to ensure minimal, and predicted, impact.   It is common to not know how many applications interact with your email system.  This is a risk that you can plan for.

Edge Email Services

Business’s email system will typically leverage a system that provides anti-spam & anti-virus services – this system will reside in between your Internet Service Provider and your internal email system.   If this system runs technology different from your current email system, it is likely to be outside the scope of any email migration.   Therefore, make sure you plan to include this server/service in your planning, as configuration changes may be required.