How do I enable auto remapping for the migrating user?
MigrationWiz has an Advanced Option available which can be added at either the project level or the individual item level, which remaps the Source email address over to the new Destination email address.
To set this, add the following flag under the Support options/support field:
There are a couple of examples where this is useful:
- When migrating over to a new domain name. For example, the Source domain equals Sourcedomain.com but the Destination domain name will become Destinationdomain.com. In this example, if migrating James@Sourcedomain.com to james@Destinationdomain.com, then you want to ensure that any entries for james@Sourcedomain.com are in fact renamed to james@Destinationdomain.com during migration.
- When migrating Source mailboxes over to different Destination mailboxes. For example, james@Sourcedomain.com will migrate over to bob@Destinationdomain.com
- MigrationWiz does not auto remap the migrating user unless this option is set.
- We do not set this by default since we do not want to modify any content during migration, unless our Partners deem this as necessary, by adding this as an Advanced Option.
- An alternative, and preferred, methodology for such remappings is to use the Advanced Option "Recipient Mappings". More details on this Advanced Option flag can be found in KB005150.
Here is a breakdown of the exact functional behavior patterns, when adding this option:
- It will auto remap:
- The email address (e.g,. if the Source domain name is Sourcedomain and the Destination domain name is Destinationdomain, then a mailbox for james will be remapped from james@Sourcedomain.com to james@Destinationdomain.com)
- The display name
- Mail (sender + receiver + extra entries such as CC and BCC addresses)
- Calendar (organizer + attendees + extra entries in the calendar item, such as resource rooms, and optional attendees)
- ItemAttachment (for any attachment to items)
- Recurrence exception (for calendar recurring meetings)
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.
- Further explanation: 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 specify which scenarios support this Advanced Option:
- Exchange 2003+, or Office365 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 LotusExtractor 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 LotusExtractor we have a translator that translates and maps these email addresses.
- POP as a Source: not supported
- IMAP as a Source: not supported
Refer to KB005100 for exact instructions on how to add this support option: AutoRemapMigratingUser=1
Note: It is case-sensitive, so be sure to add this flag exactly as indicated above.