What is the most complicated part of an average email migration?

People often ask me, “Email Annie… I am about to start an email migration project, what is the hardest part about email migrations? What do I have to be wary of? And what do I need to tell my users?”

I’ve been leading email migration projects, designing messaging architecture, as well as providing engineering and support to clients for 17 years. I typically execute several projects like these a year, and the fact is that EVERY single email migration project is different with unique technical configurations, planning requirements , coordination and scheduling.

Why is this? And how can it be that if we have two environments with the exact same number of users, the same type of business model and goals, that we can have such different email migration projects? Why would one take twice the amount of time than the other, cost much more, and require significantly greater effort and planning? Isn’t it as simple as moving a mailbox or connecting through Outlook or Gmail, like we often do at home or see on YouTube videos?

Unfortunately no… Although seasoned consultants like me tend to make it sound simple sometimes, the reality of it is very different.

Email systems in business are at an entirely different level of complexity compared to using email at home or simply connecting to email with Outlook or Gmail. Email systems in businesses have become the most critical common business system across the various types of companies present in today’s economy. And depending on the situation, email can be extremely complex and woven into the very fabric of the organization.

Email clients and messaging in today’s business world are at the pinnacle of communication for every type of business from financials, legal or consumer products to government, education and nonprofits.

How many people do you know who keep their email clients, like Microsoft Outlook, OWA, Web Mail, Gmail, etc. open all day long in the background on their desktops even when they are not in use?

Lots, right?

And how many people do you know who use text messaging, Microsoft Lync or other instant messaging clients all day long?

Tons, right?

Messaging is also used millions of times a day with the most popular social media platforms, such as when an individual sends messages through LinkedIn, Facebook, Google Plus, Twitter, etc.

So… because messaging is ubiquitous (whether we like it or not), every company has different preferences for how they want their messaging platform interconnected and configured – from connecting with various components including social media, devices like iPhones, iPads, Droids, GoodLink, Blackberry devices, ActiveSync and faxes to email journaling, archiving, legal holds, retention requirements and e-discovery.

So… what is the hardest part about all this?

Is it:

Planning?
Architecture and Engineering?
Directory and Password Synchronization?
Pilot Implementation?
Mailbox Moves?
Production Rollout?
Getting the certificates correct?
End user support and adoption?
Keeping the environment secure?

The planning has to be performed with meticulous attention to dependencies. This includes paying special attention to the end user experience and how it may change, identifying dependencies on components like 3^rd party suppliers , other dependent projects that are being deployed, client updates, and resource availability.

The architecture and engineering is not always easy and straightforward, and the most important thing for the lead engineer to do is to ensure that all components are as close to best practices or standards as possible. The engineer should also make sure that the appropriate requirements for hardware and software are in place to ensure a successful project.

The directory and password synchronization, pilot implementation, basic production configuration and certificate changes requires some patience and expertise. For the certificates, make sure to include the server SAN names, both the internal and external FQDN addresses of the affected servers (there will be more on this subject later).

The mailbox moves and physical data migration becomes fairly effortless after the first 10%-20% of the mailbox changes in the environment are completed, and you (and your team) anticipate any common errors for your mailbox migration tasks like permissions complications, corrupted data, encrypted data, etc. and how to work around it.

For messaging security, the best strategy is to lock everything down, then open up ports as you need them. Keep software updated for antivirus and malware on gateways, servers and workstations and assign knowledgeable personnel to keep an eye on logs and related reports.

The answer is H: End user support and adoption.

How can this be?

To most users, email is the most important application in the organization, and end users want and expect their email to be available as all times… so changes must be as seamless as possible. For the most part, they generally don’t like changes around their email clients, since they prefer not to be interrupted. If your company is migrating to a completely different email platform (for example from Google to Microsoft Office 365), the end users will have a couple of days of acclimatization . And if they don’t have proper training on the new client interface, the change will most likely be difficult for them. If this is your project, ensure that this training is scheduled, attended and internalized by your users.

If your company is migrating from one version to another of the same type, for example Microsoft Exchange 2010 to Microsoft Exchange 2013 (either on-premises, Microsoft Office 365 or another Microsoft Exchange hosted service) or from Domino Lotus Notes 6.5 to Domino Lotus Notes 7, the transition is fairly seamless to the end users.

If your company is migrating from a platform like Domino Lotus Notes to Microsoft Exchange or Microsoft Office 365 or Google/Gmail, the end users will experience more changes. This may result in minor components and settings that are not compatible or may need to be reset after the migration has completed. With migrations like these, I strongly recommend a few hours of mandatory email client training. This is most critical for your email migration perception of success.

I have managed these types of projects for organization of all shapes and size, and have found the following aspects of planning around client deployment is critical to the success of the project:

Make sure that somebody on the project team owns the task of communicating to the users.
Construct the training part of the pilot so that its effectiveness can be tested.
Ensure that the training task is a dynamic one, gather feedback, and update the training to best fit the audience.
Take time to understand how the users make use of their email, how they have customizations set up, and most importantly find out what they are doing with their private .pst files (to expedite this, you can run a mailbox profile utility to copy the old profile or .prf to the new settings. You may also want to consider importing PST files to server mailboxes with a utility like PST Capture – more on this later).
Communicate, communicate…. and communicate some more. Use every channel that you have available to keep your users abreast of what is happening, and “how it impacts me!”
Take time to listen to your users!

I also recommend some training or a tutorial to aid the people responsible for email server administration and support. This will help the stability in the long run and administration efficiency for the new mail platform.

What do I need to tell my users about the email migration?

If your company is simply upgrading your old email platform and keeping the same type of mail servers with a newer version, then you can anticipate that everything (except perhaps some corrupted data like very old recurring meeting reminders) will migrate and/or be accessible after the email migration. Some companies find an email migration like this to be so unobtrusive that they tell the users that maintenance is being performed during the time of their mailbox migration. The users are notified in advance in case they notice any changes like email client slowdowns or temporary mailbox disruptions during non-business hours.

If your company is migrating across platforms, forests or migrating from an on-premise environment to a cloud service, or from a cloud service to a different cloud service or from a cloud service to on-premise, you will need to inform your users on multiple instances and through multiple ways about the upcoming changes. Let them know what they can do to minimize the impact. For instance, they may need to re-establish shared calendar permissions, reset custom fonts, views, categories, preferences or mailbox client rules. They also may need reminders, instructions, or training about how to log in on the first morning of the migration, how to reset their devices (including phones, devices or blackberries), and how to log into their email remotely or through OWA or Web Mail.

I wish you the best with your upcoming project. Happy Migrating!

-Email Annie
Messaging Architect, Engineer and Messaging Migration Specialist