I'm always interested in email migration projects that were unsuccessful and, specifically, the processes followed and the reason they failed. These stories seem to appear regularly, with many exhibiting massive cost overruns and time delays.
As an email migration specialist and consultant, I use these as examples on how not to run an email migration project, to advise others from making the same mistakes that can easily be avoided.
An example of critical email migration failure
The Canadian Government launched a transformation initiative with the aim of centralising 63 disparate email systems – with approximately 400,000 email accounts – into one central system. This was part of a wider centralisation programme, with the valid goals of increased security and reduction in costs. The savings were estimated to be $50 million per year – a great vindication for the project.
Take a read about how this project has gone badly wrong, with massive cost blowouts and delays.
Amongst the list of reasons why the migration failed, there was one of particular interest to me. There is mention of demanding users to reduce their mailbox size to under 1GB, in order to qualify for migration. Furthermore, there was an underlying threat to the user if they did not comply – losing email access entirely.
Asking the user population to do something is a bad idea. It opens the door to inconsistencies, and potentially stalls the operation. In this instance, if a key member of staff misses the opportunity, it causes the migration to grind to a halt.
The lesson here is to not give power to the user. Either provide more storage, or just migrate a set amount of information, such the last three years of data, or use an archiving solution. It's also obvious to state that users don't like to be threatened, especially with something as crucial to their workflow as their email capabilities.
I feel you need to have the users onside and in a positive mindset for any email migration project to succeed.
When departments don't cooperate it creates chaos
There is mention of "foot-dragging" from some departments also. In working across many email migrations myself, I've noticed times where a department wants to protect its own systems and technical people.
The cost savings will be realised, partially, by job reductions – consolidating all email servers reduces the staff needed in multiple locations, for example.
Email migrations require technical teamwork to succeed.It goes without saying that email administrators will not be eager to help with the process if it means losing their jobs. I've spoken before about the necessity of creating a Risk Register for each project. If this had been completed to a sufficient level, staff holdups should not have been a surprise to the project team and, personally, would have been high up on my Risk Register for this email migration project.
Strong leadership is therefore required for this not to be a factor in project delays.
Making good decisions instead of bad decisions
A successful email migration project is a series of good decisions, planned and executed at the necessary times. Any bad decisions made can quickly lead to big problems, especially with a large-scale project like this example.
There could be many outlying reasons why this email migration project did not work out, but I use this to highlight some examples of why this might happen.
For any large email migration project, make sure you engage with a highly experienced consultant involved from the inception of the project through to completion. Just as strong motivational leadership is required to map out the project and ensure it succeeds, technical leadership is required for success of migrating emails and identifying any faults.
