When you created a project, you defined the Source, the Destination, and the items that need to be migrated. This can be mailboxes, documents, archives, etc. The MigrationWiz project also has Advanced Option features that will allow you to customize the project even more.

These are broken down into General Options and Advanced Options. Under Advanced Options, you may also use Support Options to further configure your project. 

To access your options: 

1. Click Edit Project.
2. Click Advanced Options.

General Options

These options are basic-level configurations.

Notifications

• Send successful migration email notifications: Choose who to notify when a migration has been executed successfully.
• Send failed migration email notifications to: Choose who to notify when a migration fails.
• Customize Notification Email: Customize email for success, failure, and request for credentials. Use certain keywords as codes for certain data. OAuth 2.0 does not use customized email; it will only use the default

You can use Markdown syntax to format your email. 

Filtering

The filtering tabs allow for specific ranges to be migrated. You can choose the By Date or By Folder filtering options.

• Specify the earliest date from which to migrate: Migrates everything that is newer than this date.
• Specify the latest date from which to migrate: Migrates everything that is older than this date. Any date filters that have been set here will be overridden by the date filters that are set under Start/Pre-Stage migration.
• Filter folders (RegEx): Define Regular Expressions commands to filter the folder to be migrated. This option is found under the By Folder tab.

Maintenance

• Number of days after which this project will be auto-deleted if unused: We only keep a project as long as necessary. When a project is not being used, we will delete it after 180 days of inactivity unless otherwise defined in this parameter.
• Log subjects of failed items: When an item was not migrated successfully, retry the errors with this option selected to retrieve the subject and path of the item if it is available.

Licensing

• Licensing allows you to set up a maximum number of licenses to use per item.

Performance

• Preferred Data Center: Our migrations run in multiple data centers all over the world. Choose which data center should run the migration. By default, we select the data center closest to the authenticated user running the migration.
• Max. concurrent migrations: This parameter defines how many migrations to allow simultaneously. Submit as many migrations as you like, we will only allow this number of migrations to be active concurrently.
• Max. errors of migration: When an error occurs during the migration, we check to see if the number of errors that we received reaches this threshold. If it does, we call the migration a failure. Otherwise, we keep on going.

Specific Migration Type Options

Mailbox

• Source:
• Migrate From: Choose between migrating from Mailbox, Archive (only with archive project), or Recoverable items. If migrating from Recoverable items, then we recommend that you have a litigation hold on.
• Use  Impersonation to Authenticate
• Destination:
• Migrate From: Choose between migrating to Mailbox, Archive, or Recoverable items. If migrating to Recoverable items, then we recommend that you have litigation holds enabled.
• Destination Mailbox Language
• Use  Impersonation to Authenticate.

Failing Items

Several options can impact whether certain items in a mailbox get migrated. Ensure these options are not blocking the migration of items you intend to migrate.

Project Level

Check to see if you have one or more of the following enabled under Advanced Options:

• Folder filtering
• Date filtering
• Item type filtering (not migrating calendars, mail, contacts, etc)

Item Level

Check to see if you have one or more of the following enabled under Advanced Options​:

• Folder filtering
• Item type filtering​ (not migrating calendars, mail, contacts, etc)

Advanced Options

 These options will further configure your migration and will allow for special processes.

Migrate to Archive

You may perform an archive-to-archive migration simply by setting the Destination Advanced Option within an Archive migration to “Migrate to: Archive”.

You may perform a Mailbox-to-archive migration simply by setting the Edit/Project/Advanced Options (Source/Destination Tab) within a Mailbox migration project to “Migrate to: Archive”.

Recipient Mappings

Recipient mapping is used in mailbox migrations to ensure that the user information maps properly from the Source to the Destination, particularly in cases where the user name or domain name has changed. Below is a table that lays out the properties that are converted for each item to be migrated:

Email

• Sender
• From
• ToRecipients
• CcRecipients
• BccRecipients

Appointments

• SenderEmailAddress
• SentRepresentingEmailAddress
• senderName
• sentRepresentingName
• RequiredAttendees
• Organizer
• OptionalAttendees
• Resources

Recipient mapping is useful in a variety of ways:

• 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 the destination when performing a tenant-to-tenant migration, while keeping the same domain name; or when changing domain names from Source to Destination.
• If you are using recipient mapping while migrating from one Source domain to multiple Destination domains, a project is required for each Destination domain.

Use cases:

• When migrating from Microsoft 365 to Microsoft 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.

         RecipientMapping="@sourcetenant.onmicrosoft.com->@destinationdomain.com"

• When you are migrating over to a new domain name.

• Source domain = Sourcedomain.com
• Destination domain = Destinationdomain.com
• Here is an example - Migrating James@Sourcedomain.com to james@Destinationdomain.com you want to make sure that any entries for james@Sourcedomain.com are renamed to james@Destinationdomain.com during migration.

          RecipientMapping="@sourcetenant.onmicrosoft.com->@destinationdomain.com"                                    RecipientMapping="@sourcedomain.com->@destinationdomain.com"

For large migrations

A large number of recipient mappings (5000+) may cause huge migration performance loss. If you are performing a large migration, add UseHashMapRecipientMapping=1. This will address such problems.

Below is a comparison of project configuration and expected behavior with/without this Advanced Option:

 

Note:

With the new AO, MW will identify each “RecipientMapping” item configured as a direct mapping item. Therefore the user has to make sure the mapping is correctly configured with the exact SMTP address.

Example: RecipientMapping="user01@source.com->user01@destination.com"

User Prefix Changes

If a user's SMTP address is changing during the migration, Recipient Mapping can be used to ensure that message headers are rewritten with the new prefix. An example is if john.doe@sourcedomain.com was changing to john.doe2@destinationdomain.com. This is common during mergers, when migrating data to an existing Microsoft 365 tenant and there are user name conflicts.

The following explains how to add a user prefix Recipient Mappings to your project’s Advanced Options.

Under Support/Support Options:

• Recipient Mapping should be added to each project under Advanced Options/Support Options.

• RecipientMapping="john.doe@abc.com->john.doe2@xyz.com"

• Note that Recipient Mapping changes are made according to the order that the mappings are added to the Support Options. Ensure that the prefix mappings are at the top of the Advanced Options list so they are performed first and not superseded by the action of a domain-level recipient mapping option, e.g., RecipientMapping="@abc.com->@xyz.com". Changes are made based on mappings added from the top down. Therefore, ensure that Recipient Mappings are noted in the correct order you wish them to be performed. 
• If you have multiple projects in progress for the same migration (e.g., batches), make sure that these mappings are also in the other project.  
• The SMTP rewrite is performed by MigrationWiz during the migration process. The Source and Destination SMTP addresses for the mailboxes in the project are simply to define the Source and Destination matching. It does not correlate to any changes made to email headers during the migration. This is why recipient mapping is mandatory; it ensures replyability.

Destination Language

The spelling of both 'Calendar' and 'Contacts' must also reflect the language of the folder name at the Destination mailbox, e.g., 'Calendar' will be 'Calendrier' in French and 'Contacts' will 'Contactpersonen' in Dutch.

G Suite (GMail API) Limitations

For ‘GSuite (Gmail API) to GSuite (Gmail API)’ migrations only:

If you want to map multiple source labels into a single label on the destination, then the parent destination label must be created before starting the migration.

Example: If you wish to map three Source labels ('ABC', 'PQR', and 'XYZ') into one parent label ('DestinationLabel') at the destination then you must create the parent label ('DestinationLabel') at the destination mailbox before running the migration.

Enable auto remapping for 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:

AutoRemapMigratingUser=1

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

Notes:

• 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".

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
• For:
• 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)

• Including:
• 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 a 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:

Refer to the Help Center article How do I add support options to a project or to a single item? for exact instructions on how to add this support option: AutoRemapMigratingUser=1

Note: The flag is case-sensitive, so be sure to add the flag exactly as indicated above.

Email notification customization

You can customize the notification emails that MigrationWiz sends for successful migrations, failed migrations, or to verify credentials from the customer’s users.

Complete these steps to customize notification emails in MigrationWiz:

1. Sign in to MSPComplete.
2. In the MigrationWiz Project Details section of the Getting Started page, click Go To My Projects.
3. In the top left corner of the page, select the appropriate workgroup.
4. Click the project for which you want to customize email notifications.
5. Click Edit Project in the top menu bar, and then click Advanced Options.
6. In the Customize Notification Email section, select one of the following tabs:
   • To customize the notification email for a successful migration, select Success and add a checkmark next to Customize "successful migration" email.
   • To customize the notification email for a failed migration, select Failed and add a checkmark next to Customize "failed migration" email.
   • To customize the notification email for requesting credentials from users, select Credentials and add a checkmark next to Customize "request credentials" email.
7. Type your edits into the Subject or Message text boxes. At this time, the notification emails only support simple text customization.
8. The parameters listed below can be used to further customize the notification emails. These parameters pull information from MigrationWiz and the configured project.
9. Click Save when you have finished editing the notification email.

MigrationWiz notification emails originate from support@migrationwiz.com on behalf of your BitTitan user account. This cannot be changed; this feature was designed to prevent potential abuse.

Parameters
Project Type: The type of migration project (mailbox migration, document migration, etc.).

• SourceSystem: The source environment (Hosted Exchange, G Suite, Microsoft 365, etc.).
• SourceIdentifier: The source account (user@domain.com).
• DestinationSystem: The destination environment (Hosted Exchange, G Suite, Microsoft 365, etc.)
• DestinationIdentifier: The destination account (user@domain.com).
• AdminFullName: The full display name of the MigrationWiz administrator (John Doe).
• AdminEmailAddress: The email address of the MigrationWiz administrator (user@domain.com)
• FailureMessage: The error message for a failed migration. (Reason: Your migration failed to check source credentials.). This parameter is recommended only for the failed notification email.
• CredentialsUrl: The URL where users can enter their credentials (https://migrationwiz.bittitan.com/user-credentials/input?i=xxxxxx). This parameter is recommended only for the credential notification email.

Folder Max Length

Even though SharePoint and OneDrive support the folder path length is 400, we have to keep in mind that it's a whole path with extra root folders (SharePoint/OneDrive specific folders and Site URL) which can not be on the source, in case of Google Drive or can be shorter, in case of SharePoint/OneDrive.

Currently, MigrationWiz accepts the ShrinkFoldersMaxLength=n values from 50 to 350, where n is equal to the desired number of characters in the folder path. The base of 50 symbols is to keep space for a filename and specific SharePoint/OneDrive root folder extensions. There is a table with path differences below. Bold text indicates the change in the path from the Source to the Destination.

Source Destination	Changes in the path
Google Drive SharePoint	Folder1/Folder2 sites/Sitename/DocumentLibrary/Folder1/Folder2
Google Drive OneDrive	Folder1/Folder2 personal/username_tenantname_onmicrosoft_com/Documents/Folder1/Folder2
SharePoint SharePoint	sites/Site/DocLib/Folder1/Folder2 sites/LongSitename/LongDocumentLibrary/Folder1/Folder2
SharePoint OneDrive	sites/Site/DocLib/Folder1/Folder2 personal/username_tenantname_onmicrosoft_com/Documents/Folder1/Folder2
OneDrive SharePoint	personal/username_tenantname_onmicrosoft_com/Documents/Folder1/Folder2 sites/Sitename/DocumentLibrary/Folder1/Folder2
OneDrive OneDrive	personal/username_tenantname_onmicrosoft_com/Documents/Folder1/Folder2 personal/longusername_longtenantname_onmicrosoft_com/Documents/Folder1/Folder2

Troubleshooting

If no Tags are present in Advanced Options (AO), by default Tags=null are added 

In case no Tags are present in Advanced Options (AO), by default Tags=null are added in Support Options. However, projects with Tags=XXXXXX do not have any impact i.e. no Tags=null if Tags=XXXXXX is already present in AO.