MigrationWiz - General FAQ

This article will answer general MigrationWiz questions, including steps where necessary. Specialized topics such as Advanced Options, Support Options, and other specific groupings have their own FAQs and may be reached from the category page.

Can I use mailboxes during a migration?

Yes. You can be logged into both the Source and Destination mailboxes during a mailbox migration.

If data or folders are removed or moved during the migration, you may experience errors during the migration, or the migration might fail altogether. If this occurs, you may resubmit the mailbox back for migration if it fails, which will continue the migration from where it left off. In addition, after the migration has been completed, submit the migration in retry mode to migrate previously failed items.

Can I stop my migration to make changes?

Once your migration has been started and assigned to a migration server, it will cache the Mailbox and Project settings specified at the time the migration was started. This behavior is by design.

Should you make changes to your Mailbox or Project after your migration starts, you should stop and restart your migration.

Can I edit previously configured settings?

Yes, by following these steps:

  1. Sign in to your MigrationWiz account.
  2. If you do not see your projects listed, click on the Projects​ tab.
  3. ​Click on the name of your Project in the list. 
  4. Click on the name of the item to edit.
  5. Click Edit Item.​

How can I utilize AutoDiscovery?

Both MSPComplete and MigrationWiz include the Autodiscover feature. ​This can be used to discover items from the Source environment so that they can be imported into your projects. 

However, there are a few requirements in order for this to work:

  • The Source has to be Exchange 2007 or later, Microsoft 365, or G Suite.


    If you are using Autodiscover from G Suite, all G Suite domains must be added to the list of domains in the Endpoint.
  • The endpoint on the Source needs to use admin credentials.
  • For mailbox migration projects, the admin account that is specified within the Source endpoint needs to have a mailbox associated with it.
  • The admin mailbox must be listed in the public Global Address List (GAL).
  • The migration project type needs to be a Mailbox migration.


    For the exact steps to be followed during your migration, refer to the relevant Migration Guide. All Migration Guides can be found on the Help Center site.

How do I start a Migration?

  1. Sign in to your MigrationWiz account.
  2. Click on the name of the Project you want to run.
  3. Select one or more items to migrate by checking the box next to the item name. If you want to select all the items, click the checkbox to the left of Source Email.
  4. Click the Start button and select the type of migration to run.
    • Full - Requires a license. This migration selection will migrate all identified and supported items.   
    • Pre-Stage - Requires a license. This migration selection will migrate all identified and supported items before the selected date.  In the case of mailbox migrations, only email items will be migrated for this migration option.  This migration option requires a license of the appropriate type.
    • Trial - Free migration pass. This migration selection is used to test the migration server.  It will migrate up to 10 items per folder or up to 5 MB of data per mailbox. A full migration with a license will pick up where the trial left off. 
    • Verify Credentials - Free migration pass. This migration selection will be tested to make sure that the credentials being used for migration are correct and will allow a successful connection. No data is migrated.
    • Retry Errors - Free migration pass. Once a Full or Pre-Stage migration has bee completed successfully, Retry Errors can be run to retry only failed items.
  5. If you want to delay your migration, then select the checkbox marked "Automatically start the migration at", and enter the date and time to have the migration start.


    To start a migration immediately, you do not need to select the scheduling option.
  6. Click Start Migration.

Prior to starting your migration, you must have already purchased the appropriate licenses as needed.

Prior to starting your migration, you can customize your migration by selecting Advanced Options.


 In Public Folder migrations the Trial Migration only scans the current folder and does not scan sub-folders.  No data is migrated, nor is an error message shown.  Barring connectivity errors, the Trial Migration for Public Folder migrations will show a Completed status.

Can I restart a migration?

Sometimes you may need to restart a migration on a mailbox that stops, or that you must rerun after you fixed migration errors.

The migration needs to be in a migrating status and not show a status of submitted or queued.

To restart a migration, the migration must be in a migrating status and not show a status of submitted or queued. Ensure that the root cause of your migration errors is repaired.

Once the mailbox shows a status of stopped, you can restart the migration by following the steps below:

  1. Select the mailbox or mailboxes you want to restart.
  2. Click the Start tab.
  3. Select your migration pass for the mailbox, and submit it for migration.

How do I verify a migration?

You may verify the credentials of mailboxes without migrating data or consuming any licenses.

  1. ​Sign in to your MigrationWiz account.
  2. Open the Project containing items to validate.
  3. Select the Mailboxes you wish to validate.
  4. Click the Start button in your dashboard.
  5. Select Verify Credentials from the drop-down list.

Once complete, the results of the verification will be shown in the Status section.​

Can I schedule my migration?

Yes, you can stop and start migrations at any time, from any location, using our web interface, our PowerShell commands, or our SOAP web services.

You can also set up the migration to have a start delay by performing the following:

  1.  Log in to MigrationWiz.
  2.  Go to the project containing the migrations you wish to start.
  3.  Select the checkbox(es) next to the migration(s) you wish to start.
  4.  Go to the top of the screen and select Start. Then select either Trial Migration, Full Migration, or Pre-Stage Migration, depending on your chosen migration strategy
  5.  A side window will appear, and once it has loaded, you will see a checkbox at the bottom that says Automatically start the migration. 
  6.  Checkmark this box, and you will see date selection fields appear.
  7.  Choose a date in the future to set an automatic start time for the migration.
  8.  You should now see it submitted with a future start date. 


    Scheduling a delayed start is tied to the local time of the computer that initiates the migration rather than the local time of the computers being scheduled for migration.

If, at any point, you wish to change the start date and time of the migration you have selected to begin, simply stop the migration and start it again with different date settings. Be aware that it may take some time to stop, and will remain in the "Stopping" state until it is ready to be started again. Once the status has changed from "Stopping" to "Stopped", you will be able to resume the migration.

You should be able to create a scheduled task that invokes simple PowerShell commands to initiate or stop migrations.

If you are concerned about bandwidth usage, you can specify how many mailboxes to migrate concurrently on your connector. MigrationWiz will only open one (1) connection per mailbox. Therefore, setting a low concurrency value on your connector is an effective way to control bandwidth usage. MigrationWiz will automatically start new migrations as others complete.

To set a limit on the number of concurrent migrations, perform the following:

  1. Log in to MigrationWiz. 
  2. Go to the project containing the migrations you wish to start.
  3. Go to Edit Project, in the top-left corner.
  4. Select Advanced Options from the drop-down.
  5. Under the Performance section, on the right, change the number of Maximum concurrent migrations to a lower number. The default is 100; you can set it as low as 1.

Time Zones

When setting up the destination, set the correct time zone. This will enable all-day events to populate correctly, as well as show events at the proper time.

Data Centers

In order to reduce the latency between a Source system and our migration infrastructure, we provide our customers with several data centers in strategic locations around the world.​

Choosing a data center closer to the Source servers can significantly increase the performance of migrations by decreasing latency.

Specify a data center

  1. Sign in to your MigrationWiz account.​
  2. Edit your Project and click on Advanced Options.
  3. Under Performance, select a data center using the Preferred Data Center field.

Preventing Duplicates

MigrationWiz uses a system of watermarks to track items that have previously been migrated. There are several advantages to using watermarks instead of detecting items by their names, titles, or other properties.

How are watermarks created and stored for later use?

As items are migrated, a small watermark is embedded in the header of each item. This allows us to track it once it resides in the Destination. Watermarks also convey information such as the endpoint type specified in MigrationWiz. 

Additionally, a matching watermark is stored in one of our databases. We do not store any content data from the item, only the watermark data. The database holds the items that have been migrated and prevents items from being remigrated if they are deleted by users at the Destination.

Because watermarks are tracked in two different places, there is a double layer of protection against the creation of duplicates.

How does MigrationWiz use watermarks in additional migration passes?

When another migration pass begins, the Destination is scanned for watermarks so we will know what data has been migrated. The watermark database is also scanned to prevent the re-migration of items that were deleted or moved at the Destination between passes. This scanning process occurs at the beginning of every migration pass. The larger the quantity of data migrated, the longer this process will take. For example, a migration that previously transferred 20GB of data will take longer to scan for watermarks than a migration with 20MB transferred.​


Watermarked items are not migrated a second time. Only items found without a watermark will be migrated.

What happens to items at the Source?

Data at the Source will not be modified. this includes watermarks.

How do I delete watermarks?

  • If a user manually deletes a migrated item from the Destination, it will not be migrated because it will still be tracked on the back end.
  • To delete our end of the watermarks database, check the box next to the migration you want to do this for, then click the circular Reset Items button on the toolbar at the top of the user list. This will only clear our end of the database.
  • If you would like to delete watermarks stored at the Destination, you need to delete the items themselves, as the watermarks are embedded in the item headers. This is typically done only when restarting your migration from scratch. Deleting items at the Destination will only clear the Destination watermarks. Unless the watermarks are reset on our end, items deleted from the Destination will not be re-migrated.

Because we use proprietary watermarks that are specific to our system, we will not be able to detect items migrated by other means. For example, items forwarded from the Source to the Destination (also items migrated by other solutions) will not contain our watermarks. Therefore, we have no knowledge of them existing at the Destination. As a result, we will migrate these items even if they are already at the Destination.

Since we store the endpoint type in the watermark, changing the Source or Destination endpoint type in between passes will void the watermark and all items will be migrated again. If this happens, a new watermark will be generated in each item based on the new Source or Destination endpoint type.

If an item at the Source is moved in between passes, we will not be able to match the Source item with its Destination counterpart. As a result, the item will be migrated a second time. It will then exist in both locations.

Was this article helpful?
1 out of 1 found this helpful