How to move your mail infrastructure away from Lotus Notes

Tuesday, 13 January 2015

Mailbox Copy vs. Move – Don’t Let This Dilemma Get in The Way of Your Exchange Migration - Binary Tree

Mailbox Copy vs. Move – Don’t Let This Dilemma Get in The Way of Your Exchange Migration - Binary Tree:

'via Blog this'

Mailbox Copy vs. Move – Don’t Let This Dilemma Get in The Way of Your Exchange Migration
Posted by Vadim Gringolts, CTO

When considering an Exchange migration, it’s important to understand there are two radically different approaches to migration from the legacy to the new platform:

  • Creating brand new mailboxes and copying legacy content into them
  • Or moving legacy Exchange mailboxes in their entirety to the new environment
While few administrators start out by considering these alternatives, I’d like to highlight the importance of proper evaluation of these two very different approaches.

Approach A – Copying the Mailbox Content
You are taking content from one existing mailbox and moving it to a new target mailbox. This approach is usually accomplished by using transport protocols, such as EWS, MAPI, or some proprietary ones.

Benefits of This Approach: Simplicity and Flexibility

  1. You can migrate between any source and target platform, regardless of version or implementation flavor: on-premises, cloud, hybrid, hosted, or managed.
  2. You have the ability to filter content in a variety of ways, of your choosing—usually by age, type, size, or other criteria.
  3. You are not dependent on the alignment of old and new environments. As long as you can connect a migration workstation to a source and a target mailbox, you can migrate the data.
Shortcomings of This Approach

  1. It’s slower and less scalable than Approach B, although higher throughput and scalability can be achieved with proper planning and migration environment design.
  2. You could possibly suffer from data fidelity issues, depending on HOW you move your pieces of content.
  3. You have to figure out how to transition your users. Directory synchronization, mail routing, free/busy lookup have to be addressed outside of the migration engine.
  4. You will need to rebuild offline storage for your users, which may impact user experience.
  5. Your Outlook client reconfiguration becomes less transparent to your end users.
Approach B – Moving the Mailbox
You take an entire existing Exchange mailbox and move it from the old server to the new server (which could be either on-premises or in the cloud).

Benefits of This Approach: Efficiency and Transparency

  1. It’s a much more efficient process than the copying of content allows. The mailbox move is a Microsoft PowerShell command promoted by Microsoft for its efficiency, scalability, transparency and fidelity. All mailbox attributes are fully and seamlessly transitioned.
  2. End users have a local copy of their mailbox (also known as offline storage or OST file), and this option allows them NOT to have to rebuild their offline storage – an extremely time-consuming operation.
  3. End users transition transparently. The provisioning of mailboxes, along with the changes needed for mail routing, are made automatically while Outlook is seamlessly reconfigured.
Shortcomings of This Approach

  1. Everything is moved in its entirety, which means there is no data filtering. So, in order to leave any content out of the migration, you must archive it or delete it prior to performing the migration.
  2. You can’t just move from anywhere to anywhere. There are limitations for certain source and target combinations. For instance, you cannot move from one Office 365 tenant to another Office 365 tenant. In general, hosted source and target platforms do not always support this approach. Finally, you cannot move mailboxes directly from Exchange 2003 to Exchange 2013; you would need to perform a two-hop migration from Exchange 2003 to Exchange 2010 (or 2007) and then from Exchange 2010 to Exchange 2013.
  3. In order for you to perform the migration, you have to align everything – your source environment, target environment, access, security, DNS, active directory, firewalls, etc.  As a result, the initial configuration process is much more complex requiring precious time and a high level of expertise.
Bottom Line:
While it may take you a little while to wrap your mind around this issue, it is definitely worthwhile to consider the pros and cons of each approach before committing to a specific solution. In most cases, moving mailboxes is a more attractive approach, especially when it comes to large enterprise migrations. Only upon careful evaluation can you determine whether this approach is right for you or if you are better served by a data copy approach. To explore this topic further, please consider attending our webinar on January 20, 2015, Copy vs. Move – How to Select the Right Approach for Migrating Exchange Mailboxes.

In my next blog, I will cover more ways to segregate and compare the array of product/service offerings on the market.


Post a Comment

Thank you for taking the time to comment. Your opinion is important and of value and we appreciate the positive feedback! If you are "Negative Nancy" then please do us, and humanity, a favor, and piss off.

Total Pageviews

Google+ Followers


Blog Archive

Popular Posts

Recent Comments

Rays Twitter feed


Web sites come and go and information is lost and therefore some pages are archived. @rayd123 . Powered by Blogger.