Anything that interferes with a migration team completing their project on time and on budget risks cost overruns, reputation loss, and potential loss of future contracts. Migrations, by their nature, are behind-the-scenes projects. Increased complexity is rarely a viable excuse when users experience disruption to their work or loss of data. One example of complexity that can be planned for is mailbox mapping in a merger or acquisition scenario.
Recipient mapping use cases
Recipient mapping is used in mailbox migrations to ensure that user information maps properly from the Source to the Destination when the username or domain name have changed. Here are some use cases:
- When email remains reply-able post-migration, even after a full tenant-to-tenant migration, while keeping the same domain name.
- When changing domain names from the Source to the Destination.
- When calendar ownership and display name when performing a tenant-to-tenant migration wile either keeping the same domain name or moving to another.
- When migrating from Microsoft 365 to Microsoft 365 and keeping the same domain recipient. In this case, mappings must be added to your project as follows: ‘RecipientMapping=”@sourcetenant.onmicrosoft.com->@destinationdomain.com
- When migrating to a new domain name where you need to ensure that any entries for users such a bill@sourcedoman.com are renamed to bill@destinationdoman.com during migration.
Recipient mapping in action
BitTitan recently learned of a Partner who was performing a very large and visible migration for a Fortune 500 company. This was a tenant-to-tenant migration in which domain names were changing as the result of a merger. The Partner’s team knew in order for the mailboxes to work seamlessly, they would have to apply recipient mapping to all users.
One of the team members was concerned this process could slow down the migration. Luckily, they knew enough about MigrationWiz to check BitTitan Knowledge Base articles to see if there was another solution. Sometimes the scale of a migration plays an important role in how recipient mapping is implemented. For large migrations – fifty to five hundred users – using a hash table makes much more sense than one-to-one mapping. A single recipient mapping script greatly improved the performance of this process and allowed the team to get the cut-over done on time.
The how-to
Be sure to review the BitTitan Knowledge Base for details on how to implement recipient mapping. Here’s a quick overview:
While using Advanced Options, add UseHashMapRecipientMapping=1 option
Recipient mapping is just the same as it was but using the new Advanced Option of UseHashMapRecipientMapping=1 This will cause recipient mapping to be handled differently by MigrationWiz and will greatly increase the performance.
Here’s an example:
UseHashMapRecipientMapping=1
RecipientMapping=”user01@source.com->user01@destination.com”
RecipientMapping=”user02@source.com->user02@destination.com”
RecipientMapping=”user03@source.com->user03@destination.com”
RecipientMapping=”user04@source.com->user04@destination.com”
RecipientMapping=”user05@source.com->user05@destination.com”
……
……
RecipientMapping=”user5000@source.com->user5000@destination.com”
While recipient mapping has always been helpful when performing mailbox migrations, using the upgraded hash method available in Advanced Options greatly improves performance in a large migration.
MigrationWiz is great for migrations that result from mergers, acquisitions, and divestitures. Contact our sales team or pop over to the pricing page to start planning your migration today.
