Netmail Blog

Top 8 Email Migration Questions

Posted by Frederic Bourget

Mar 2, 2015 3:12:16 PM

 

Every time we have a conversation about email migrations, the same questions come up. So, in this blog, I have captured the essence of these questions. Most of these questions are related to Netmail’s unique migration methodology that allows large and small organizations to migrate in a weekend. Yes, this may sound impossible, but we actually routinely run email transformation projects this way.

How are you going to move all my data in a week-end?

We don’t! The basis of the Netmail migration methodology is that you migrate all the data prior to the migration date. It is typically done in a staged manner. First, we move all of the data that is more than 1 year old into the new email system. We do this in a two-step automated process, working our way towards the last two weeks of email. Then every night, we capture the 14 day-old email to keep this gap to two weeks. On the week-end of the cutover migration, we only have 2 weeks of email to move, which is very doable. 

There are significant advantages to this methodology. The first is that users get to familiarize themselves with their new email platform. That's right, users can connect to the new mail system and see all data that is older than one year. It also gives them confidence that when the time comes, they will be able to log in and use the system. It also allows them to train themselves and set up their mailbox and folder structure the way they want it. Which leads me to the next frequently-asked question...

What is the impact on users compared to co-existence migrations?

Traditional co-existence migration processes require users to work in one system up until the point of migration then log out and log back in to the new system the following day. Data is migrated with the user so any issues can affect that user when he logs back in. With individual users being moved on a daily basis and individuals not having access to email during that period, this results in an impact to users and rescheduling logistics for those users who may need to have access during the process. It may also lead to outages if the migration has issues.

The Netmail advantage is that all data is copied, moved and validated in the background without impacting the user prior to migration. Users can continue to work in the current system, filing, deleting and responding to items. The 14-day collection offset ensures that all current transactions are properly recorded for migration to the new system. Users do not need to do anything to prepare for the migration outside of maybe cleaning up their contact lists and recording their rules for re-creation in Outlook.  

In addition, during the transition, users will need to be aware of where conference rooms and other shared resources reside as this may impact their workflow--a situation which must be endured until all of the users are migrated, and may have an impact on the organization. With single cutover migrations, all of these impacts go away, since all users are on the same platform all the time.

Single cutover migrations are best for ongoing 24x7 operations because once the cutover has been announced, users who are working weekend shifts can immediately start receiving mail in the new system. They have all of their email with exception of the last 14 days, which they will see appear automatically within the following few hours.

Can my Help Desk handle all the calls that come in after the migration?

The number of help desk calls is directly related to the training you offer to your users. Having the capability for the users to connect to the system ahead of time reduces a lot of calls. That said, not everyone will take the time to learn the new system ahead of time, so you should expect to have to increase the size of your desktop helpdesk by about 30%-40%. For example, a hospital with a desktop help desk of 7 people should have 3-4 additional people for the first week. The majority of questions will be around Outlook or OWA usage, password resets and the like. This is really consistent with the roll-out of any new application.

How do you handle the communications & change management for an email migration?

Like any change management process, there are a few key things you need to plan for. First you need to get executive buy-in in the process. "Mahogany row" (executives!) is usually the heaviest user of communication tools like email; you should make sure they see the benefits of the new system you are putting in place: it’s not about the migration, it’s about the destination. 

Then you need to get a feel for what happens on the ground. Get a survey of what are the special business processes that are based on your current email platform. It is also a good time to get sponsors from various parts of the company. These will be key advocates in making sure everyone is on board.

Finally, (ironically) you need to start early with your communications. Setting expectations properly with the organization is what will ensure success for the project; this includes training and expected changes.

Actually, cutover migrations are great, because everyone is involved at the same time. You are creating an event, so people are part of the event and help each other. It makes getting attention through communication much easier.

From a risk perspective it is less risky than other methods. Prior to even getting close to the migration, you have already moved the data, so you know everything is good on that front. You have trained your users and they were able to log on to the new system. Your whole team is mobilized for the event, and there will be no discrepancies.

Should we setup co-existence for our migration?

Co-existence is appropriate when you run an email migration over multiple months (6-12 months). The challenge is that co-existence is expensive and fraught with problems and support nightmares. First, you need to license, install and  manage two email systems in parallel for a long period of time. This is no small feat in itself as you normally do not have double the email staff.

In addition, the co-existence servers must be setup, configured and managed. These are very touchy machines that need to be scaled properly and maintain connectivity at all times. Then, there are challenges related to incompatible data. Not all information gets transferred properly through these gateways, which adds up to a lot of help desk calls and troubleshooting. Whenever possible, it is better to run a single cutover migration. It’s easier to build your new house, duplicate your furniture to the new house, setup everything, and then move in one shot rather than having part of your furniture and family living in one house and the other part in the other house and moving the furniture and the family members one by one over a long period of time. Right?

How long does it take to run a single cutover migration?

There are two major factors that influence a migration timeline. The first is the efficiency of an organization at managing change. Preparation and end-user communication are usually the key factors. From a technical standpoint, the amount of data to move is the limiting factor. Usually, throughput can be scaled pretty high by adding hardware. We run 1Gig per hour per virtual server. It becomes a cost benefit discussion at that point. 

Typically a migration of 10k mailboxes will take 3-6 months. There are ways and choices that can be made to reduce the timeline. For example, some customers have decided to move only two weeks of data and back fill the rest of the next few weeks following the cutover. This allows for very short migration, assuming the organization can handle communication, hardware setup, and new mail system setup in the timelines.

What is the #1 problem you see with cutover migrations?

Organizations who do not have a good handle on the mailboxes they manage tend to have issues. It is important to have a well-defined process to identify, create, and delete mailboxes within your mail system. This is basic good management and security practice. If your organization does not have such processes in place, prior to the migration is a good time to put them in.  Anything else will lead to forgotten users – and a bit of remediation after the cutover. It is critical to have an accurate list of mailboxes to migrate if you want to really succeed.

These are typically the top questions that come up prior to a migration. For all the benefits of a shorter timeline, user training, less stress on the organization, and a significantly improved user experience, our experience has shown that single cutover migrations are a lot more successful!


Learn more

Topics: Email Migration, Email Management, Netmail Archive