Selecting mailbox migration software


I am asked on a fairly regular basis to recommend software to migrate data from different systems to Exchange (either on-premises or cloud). I don’t want to endorse any software in any way, but I think it worthwhile to set down a number of principles that can be used to guide a company in making a choice from the available software.

Here are the consideration that I advise people to consider when the time comes to pick migration software:

  • Cost. This is actually an interesting topic because of the old adage that if you pay peanuts, you might get monkeys. In other words, sometimes the lowest cost option is not the best, especially when it comes to migrating content from a high-fidelity and high-function system like Lotus Notes. Migration from POP3 or IMAP4 is quite a different matter because all you need to worry about is how to move messages. Make sure that you understand the exact breakdown of all costs involved in using migration software, including fees for updates or annual license renewals.
  • Multi-type support. As noted above, it is relatively straightforward to move email messages from one repository to another. It is quite another matter to process calendar items, tasks, contacts, and other item types. The first issue is to understand what types are actually used and how they are used; the second is to ensure that the different types of items can be migrated in such a way that they remain useful when accessed through the target system.
  • Reputation. Check out customer experiences with different migration tools. In the Internet age, you can’t but find stories posted of migration horrors. Fewer exist of migration triumphs because humans generally don’t report their successes, but the problems will give you some guidance about pitfalls to avoid.
  • Test. Ask vendors for test licenses and test the migration process. Don’t test a small mailbox; take a copy of a nice juicy complicated mailbox and test what happens when that is processed. Include common user scenarios such as delegate access and shared mailboxes. Then do a set of mailboxes to understand how long it will take for the migration to happen and what to expect when it does happen. Make sure that the test mailboxes are of a reasonable size and age (very important). Any migration software can move 100MB mailboxes that have been created specially for test purposes. It’s much better to give them a nice fat 5GB mailbox that’s been in use for six or seven years and has been exposed to potential sources of corruptions (mobile clients and Outlook add-ins are the usual suspects). Always remember that real mailboxes expose real problems for migration software.
  • Support. Who delivers the support during your migration project? If it is a local reseller, what relationship do they have with the folks who actually write the code? What turnaround time is likely if you report problems and what escalation path is used to pursue the closure of problems? Do you have a guarantee that you will get a refund if the migration doesn’t work? How quick do you have to make up your mind about whether software is suitable?
  • Information. Apart from the sales-type information available on their web site that tells you just how wonderful their software really is, what other information does a vendor provide? Some vendors do an excellent job of documenting the technical side of their products, including some of the warts, and some do not. I prefer when detailed in-depth information is available. I expect that you do too.
  • Added value. Moving mailboxes is expected, but does the software give you any extra capabilities such as moving mailboxes in the background, scheduling capabilities, automation, or project management?
  • Post-migration tasks. What work must be done following mailbox moves to make users productive in the new environment? For instance, do you have to recreate Outlook profiles or will Autodiscover work with the new mailbox data?
  • What does the local Microsoft subsidiary use? Ask your local MCS contact to find out and ask why they made that selection (and what their experience has been). It’s not a deciding factor because the other factors have to considered too in the context of the data to be migrated, number, customer preferences, etc., but it’s a good thing to know – if only because your company might ask why you selected a different tool.
  • Applications. Although email systems serve to send and deliver email, many also include some aspect of application development. Lotus Notes is probably the best example as most Lotus Notes deployments include applications (the original raison d’etre for Notes). How will applications be migrated?
  • Plan B. Can you use the migration software to reverse course and move data back to the original system should the need arise? Having a one-way option is OK if you are absolutely sure that this is all that is required, but you’d be surprised how many times the need arises to move a mailbox back to its original home.

Some people love the technology exhibition at most large Microsoft-related conferences such as TechEd and MEC.  I don’t care for them very much because I think most of the vendors do pretty well the same thing as they’ve been doing for the last decade to attract customers (how many cheap t-shirts can you pick up at a conference?). There are some notable differences who try and make their stands more interesting and welcome (ENow Software (who also host excellent parties) and Binary Tree are two companies that come to mind in this respect), but in general I find exhibitions a drag. The reason why I mention them here is that they can be a very useful place to learn about migration software and, possibly even more important, to make contacts with developers who work on the code and might be able to help you during your migration projects.

Companies that I have commonly encountered in Exchange migration projects include the set listed below. Most can handle migrations to both on-premises and cloud Exchange and accommodate multiple sources including Lotus Notes, IMAP/POP, Gmail, GroupWise, and Zimbra.

Binary Tree

Skykick

Dell Software (ex Quest)

MigrationWiz

Priasoft

Again, no endorsement of any software is offered here and the list of available suppliers is acknowledged to be incomplete. Test them using some realistic mailboxes before you make a final choice.

Follow Tony @12Knocksinna

About Tony Redmond

Lead author for the Office 365 for IT Pros eBook and writer about all aspects of the Office 365 ecosystem.
This entry was posted in Email, Exchange, Office 365 and tagged , , , , , , , , , , . Bookmark the permalink.

1 Response to Selecting mailbox migration software

  1. Thanks for mentioning Priasoft!

    I’d add to your list support for Outlook profiles. Outlook + Auto-Discover is not a proper option except for same-forest migrations. Migrating terabytes of data is often of little value if end users have difficulty accessing those shiny new mailboxes :). Updating existing profiles is more complicated than just changing a server name and starting with new profiles impacts the end-user experience and thereby the perception of success. This is even more important now with Exchange 2013 and the requirement that all connections be HTTP/S.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.