Recipient mappings are a useful way to ensure that:
- All email remains replyable to, post-migration, even after a Full (Delta) Migration has occurred when performing a tenant to tenant migration, while keeping the same domain name; or when changing domain names from Source to Destination.
- Calendar ownership and display name match on destination when performing a tenant to tenant migration, while keeping the same domain name; or when changing domain names from Source to Destination.
Note: If you are using recipient mapping while migrating from one Source domain to multiple Destination domains, a project is required for each Destination domain.
- When migrating from Office 365 to Office 365 and keeping the same domain name, recipient mappings must be added to your project, as directed below. This is included in the migration guide for this scenario.
- When you are migrating over to a new domain name.
- Source domain = Sourcedomain.com
- Destination domain = Destinationdomain.com
- Example - Migrating James@Sourcedomain.com to james@Destinationdomain.com you want to ensure that any entries for james@Sourcedomain.com are renamed to james@Destinationdomain.com during migration.
The following explains how to add a recipient mapping to your project's Advanced Options, using the example above:
- Under Support/Support Options, add the following:
- Make sure to click on the "+" sign after entering your recipient mapping. If you do not do this, it will not be added.
- The recipient mapping above is only an example: do not copy this verbatim. Change it to reflect your tenant .onmicrosoft.com account name and your customer domain name.
- Left part is a RegEx applied to the recipient email address. You can use more than one remapping expression. This is a very important step for Office 365 to Office 365 migrations. It ensures that emails are replyable to, even after the Full (Delta) Migration has occurred.
Refer to KB005100 for instructions on how to add this support option, under Advanced Options, at either the project or individual item level.
This Advanced Option has the following limitation:
- We do not support recipient mapping for the actual Mime content, so email mime content based migrations, such as Zimbra, won't have remapping for email. . The MIME content is the information that is listed under Show Details, for a message, for most email systems.
Here is a breakdown of migration scenarios, to show which scenarios support this Advanced Option:
- Exchange 2003+, or Office 365 as a Source - supported
Note: Exchange 2003 will migrate using WebDAV. Exchange 2007 can migrate using WebDAV or EWS, Exchange 2010+ will migrate using EWS
- GoogleApps as a Source - Calendar entries do support this option. Email entries will not support this option because migrations are based on MIME content.
- Zimbra as a Source - Calendar entries do support this option. Email entries will not support this option because migrations are based on MIME content.
- GroupWise as a Source - not supported
- Lotus Notes as a Source - supported
- Lotus' recipients are extracted inside the local Lotus Extractor as an Attribute of LotusWebServiceItem instead of MIME content.
- The customer's email addresses on Domino/Lotus server are in X400 format instead of SMTP, so inside Lotus Extractor we have a translator used to translate & map these email addresses.
- POP as a Source - not supported
- IMAP as a Source - not supported