Introduction to Email Migration Project Challenges
This blog describes common email migration project challenges that can appear in different email migration scenarios. There are many different types of email migration project (eg: Domino to Office 365, GSuite to Office 365), but certain challenges can appear in all. Bad decisions in any category will result in a higher chance of failure for your email migration project.
I list out the following challenges, and what steps can be taken to overcome them.
- Choose Target Platform
- Project Plan & Timeline
- Involve the Business
- Hiring an Email Migration Consultant
- Migration Software
- Migration Strategy
- Risk Register
- User Communication
- Success Metric
Choose Target Platform
One of the first decisions that is made for an email migration project is the target platform. This decision drives how the project will start out. The decision may be to migrate to Office 365, Google GSuite, or a new version of Exchange On-Premise. Whatever the decision is for the target platform, make sure the decision is clearly recorded, with the reasoning listed. For example, the decision to move to Office 365 may be a financial one to reduce operational costs.
A list of requirements is an important way to define what is being done during the email migration project. This also provides an important success metric. Project stakeholders have an opportunity to add their own requirements. If the customer does not wish to have any defined requirements, then this needs listing as Risk 001 in the Risk Register! For the email migration projects I act as Lead Consultant, you cannot have no requirements and no risks.
Project Plan & Timeline
The email migration activity is recommended to be treated as a project, with a defined start and end date. If there is no timeline then this acts as a warning flag to me – the project is not being run correctly with formal project management structures. For email migration projects that I have been hired to rescue, it is not uncommon for there to be no timeline or project plan.
Involve the Business
Seems an obvious one, but I have seen email migration projects started without broad business support. This creates problems later, and these projects often get put on hold, or are halted altogether. There is no point in starting an email migration project unless there is business support in some format. Furthermore, the business need to be involved with the project every step along the way. Business support allows the project to progress smoothly in the face of resistance from certain areas of the business, which may otherwise result in a project stoppage.
Hiring an Email Migration Consultant
You need an email migration expert to be involved in the project from Day 1. The cost of not hiring an email migration consultant can be very high, as you will be lacking Technical Leadership to guide through the difficult paths of the project. You will have access to deep experience of what no to do during an email migration project, and how to succeed. When you learn to fly you would have an instructor next to you. Would you be happy taking a flying lesson all by yourself? Hire my email migration consultant services for your project.
Migration & Coexistence Software
Use your email migration consultant to help you choose the best migration software to use for your project. Costs of migration (and coexistence) software can be very high. If you are migrating a 10,000 mailbox IBM Domino platform to Office 365, and the 3rd Party software is $30USD per mailbox, then that is $300,000 USD of cost! I recommend reading this great partner blog article that covers how to approach a migration to Office 365, including migration & coexistence software.
Your email migration consultant may be able to offer some alternative strategies that can use different migration (and coexistence) software. For the above example, if the software costs can be reduced to $20USD per mailbox, via a different Migration Strategy, then that is a saving of $100,000USD. If your email migration consultant costs you $20,000USD then that cost is very good value.
If I was the CIO of a company about to embark on an email migration project, I will likely ask the Project Manager to explain the Migration Strategy to me. If the Project Manager cannot answer clearly, and concisely, then that is a problem. For all my email migration projects I consult on, I produce a Migration Strategy document, that is easily understood by any stakeholder in the project. Indeed, stakeholders are required to sign their approval of this document, recording their understanding and agreement.
A Migration Strategy should summarise how the project will achieve the email migration successfully. Also, it should present an acceptable balance of the following core components:
- Business Risk
An email migration project being run with no Risk Register is a major risk. Certain formal structures are required by project management doctrine, and the Risk Register serves a vital part of any project. All risks need to be recorded and published to all stakeholders. A Risk Register that is not properly maintained is the same as having no Risk Register.
The email migration projects that I have helped achieve success have all had rigorously maintained Risk Registers. Closely aligned to the Risk Register is the Issues Register and Technical Decisions Log. These project management controlled documents are your friend.
Every email migration project needs at least one test phase. For my projects, I would recommend Function Testing, and User Acceptance Testing (UAT). Further testing will inevitability take place during the pre-pilot and pilot phases. Importantly, you want to get all stakeholders to sign off on the UAT Test Phase before proceeding into production mailbox migrations.
For migration projects such as Domino to O365, there will be significant change to business process. For these projects, the test phases take on an extra level of importance.
Informing the user population throughout the email migration project is important. This can be to tell them what the changes will be, and when. And checking with them on Day 1 post-migration.
Importantly, you need an alternative way of reaching users, other than email. If the email migration project breaks the email system, then you cannot email the users! My advice is to use multiple mediums for communication – examples are:
- Instant Messaging
- Noticeboards in the Office
Plan to measure success for your email migration project. You want to be able to say the project was a success, and demonstrate this success via metrics. Otherwise, a small group of unhappy users can label the project a failure. It is my experience that there are always some unhappy users, despite the email migration project being measured as a great success.
Some of these topics have been covered elsewhere on this website, but taken together they provide a great summary of the common email migration project challenges.