MigrationWiz: the Migration Process

The following article answers questions concerning scheduling, delaying, stopping, and starting migrations. It also explains the order in which items are migrated, expected speeds, the progress bar, and other general MigrationWiz process questions.

While a migration will have variations based on type (document vs. mailbox, or different sources and destinations), the general flow of a migration is consistent. Each migration guide will give you the specific steps and instructions for your scenario, but the overall process will usually follow these steps:

  1. Prepare the source
  2. Prepare the destination
  3. Create a project in MigrationWiz
  4. Add items
  5. Set any advanced options (as directed by the migration guide)
  6. Verify Credentials
  7. Perform the Migration
  8. Post-migration steps (as directed by the migration guide)

As part of these steps, you will purchase licenses, notify users, and perform any data customization required by your scenario. Each migration guide provides detailed steps, instructions, clarification, and resources for your migration. 

Migration Management

The following section outlines the options for starting, stopping, scheduling, and delaying migrations and describes the steps to run the migration process. This is only a general description of the process. For specific migration guidance, refer to your migration guide.

Migration Stages

Once you have created and populated your migration project, MigrationWiz provides five migration options.

The five allow you to test and verify your connections, complete the migration either in stages or in a single pass, and then allows you to capture and migrate items that may have failed to migrate the first time around.

Following are descriptions of each migration option.

  1. Verify credentials: This process checks the credentials for migration at both the Source and the Destination. Verifying credentials will not migrate any data or consume any licenses. This process will perform the following actions:
    • It will check that the mailbox exists on the Source.
    • If using admin credentials at the Source (these are entered when creating the project), it will verify those credentials.
    • If not using admin credentials at the Source, and using user credentials for each mailbox, it will verify those credentials.
    • It will check that the mailbox exists on the Destination.
    • If using admin credentials at the Destination (these are entered when creating the project), it will verify those credentials.
    • If not using admin credentials at the Destination, and using user credentials for each mailbox instead, it will verify those credentials.
  2. Trial Migration: A Trial Migration will migrate a very small amount of data in order to test that the project has been created properly and that the mailboxes have been entered correctly. It is completely free and can be performed an unlimited number of times. Each Trial Migration will perform the following:
    • Trial migrations verify credentials at both the source and destination.
    • Trial mailbox migrations recreate the entire folder hierarchy on the destination, based on what is defined at the source.
    • Trial migrations migrate only up to ten items in each folder, and up to a total of 5MB of data.
      Important: For Public folder migrations, the Trial migration only migrates the current folder and does not scan sub-folders. No data is migrated, nor is an error message shown. Upon running behind the scenes, the trial migration on public folders will show a Success message.
  3. Pre-Stage Migration: A Pre-Stage Migration pre-fills a Destination mailbox with mail only migrated items, as defined by the Pre-Stage Migration settings selected. A Pre-Stage Migration is typically part of a multi-pass migration strategy. It occurs before the MX record cutover and is a great way to pre-fill the majority of the end users' data into their future Destination mailboxes while they are still using their old email system. It has no impact on the end users and is a highly recommended strategy to follow since the majority of data is migrated over prior to MX record cutover. Typically only mail items older than three months are included in the Pre-Stage Migration because these items are unlikely to change.
    • When performing a Pre-Stage Migration, it is important to understand that MigrationWiz is a migration solution and not a synchronization solution. With this in mind, it will not propagate updates, deletes, or moves of the items previously migrated in the first migration pass because we do not have “live” monitoring of changes (as with a sync agent), and we cannot handle scenarios like conflict resolution without user interaction.
    • Here is what would happen after a Full (Delta) Pass, if items previously migrated to Destination have been:
      • Deleted at the Source: The Destination will keep containing these deleted items. We cannot propagate deletes (e.g., if an item is archived at the Source, it will look like a delete and we can not delete the item at the Destination).
      • Moved from Folder A to another Folder B: These items will be duplicated at the Destination, they will be both in Folder A and in Folder B at the Destination.
      • Updated at the Source: These items will not be updated at the Destination. There is no process by which the calendars, contacts, tasks, etc., can be updated. This would require conflict resolution, which is only possible with a synchronization solution. Instead, MigrationWiz watermarks all migrated items so as to avoid remigrating any items in subsequent passes.
      • This multi-pass migration strategy typically follows an order of events similar to this:
        • First pass (Pre-Stage): Migrate ONLY mail items that are older than three months. The Pre-Stage migration is performed one to two weeks before MX record cutover (times vary, dependent upon the number of mailboxes being migrated and the size of the mailboxes). Perform the MX record cutover.
        • Second pass (Full or Delta): Migrate all items, with no date filters. This pass is performed after the TTL expires.
          Note: Changing MX records in DNS to point to the new system is not effective immediately, and is subject to replication delays. Wait for the TTL (aka Time To Live) to expire.
        • Optional Third pass (Full or Delta): Migrate all items, with no date filters. This pass is performed two or three days after the MX record cutover. This picks up any residual mail that was still delivered to the old mail system after the MX record cutover, due to slow DNS internet propagation.
  4. Full/Delta Migration Both Full and Delta migrations have the same settings in MigrationWiz. With both migration types, the migration has no date filters, and all items are migrated.
    • With a Full Migration, everything is migrated in one pass. For example, a single pass migration (Big Bang) strategy will move the entire mailbox in one pass, after MX records are cut over. A typical scenario consists in cutting over on a Friday evening and migrating during the weekend.
    • With a Delta Migration, which is performed after a Pre-Stage Migration and is part of a multi-pass migration strategy, it is possible to resubmit a mailbox or mailboxes to perform a differential migration pass. MigrationWiz will automatically find items that haven't yet been migrated since the first pass and migrate only those. In other words, a Delta pass will find and migrate residual items. In most cases, a Delta pass will complete much faster than the initial pass.​ In a Delta pass, MigrationWiz will continue the migration from where it left off and cause no duplicates to be created at the Destination, which means that all items which were not migrated in the first pass or were created after/during the first pass will be migrated.
  5. Retry errors This is another attempt to migrate any items that previously failed to migrate. It will not migrate any successfully migrated items. It will not consume any more licenses. Only submit mailboxes in the Retry Errors mode if they satisfy both of the following conditions:
    • The last migration completed successfully.
    • The mailbox contains at least one error.

Start a Migration

From the MigrationWiz interface:

  1. Click on the name of the project you want to run.
  2. 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.
  3. Click on the Start button and select the type of migration to run.
    • Full - Requires licenses. This migration selection will migrate all identified and supported items.  
    • Pre-Stage - Requires licenses. This migration selection will migrate all identified and supported items before a set 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 licenses will pick up where the trial left off. 
    • Verify Credentials - Free migration pass. This migration selection will test 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 completed successfully, Retry Errors can be run to retry any failed items.
  4. 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.
  5. Click Start Migration.

Prior to starting your migration, you must have already purchased the appropriate licenses as needed and you can customize your migration by selecting Advanced Options. These steps are outlined in your migration guide. 

Important: 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.

Schedule a Migration

Migrations can be scheduled to start at a specific time. There is no option to have the migration stop or pause at a scheduled time.

If, at any point, you wish to change the start date and time of the migration, 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 in a state which will allow it to be started again. Once the status has changed from "Stopping" to "Stopped", you will be able to resume the migration.

If there are concerns about bandwidth usage, it is possible to specify how many mailboxes to migrate concurrently within a project. MigrationWiz will only open one 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.

Delay a Migration

From the MigrationWiz interface:

  1. Open the project and select the items you wish to start at a delay.​
  2. Click the Start button.
  3. From the drop-down list, select either Pre-Stage Migration or Full Migration.
  4. Check mark the box next to: Automatically start the migration at
  5. Select a day and time for the migration to begin.
  6. Click Start Migration.

To stop the "delayed start" of the items to be migrated, select the users, then click on Stop. After they are stopped, resubmit the items for migration as desired. This can be useful for large items, or those still in use at the source.

Stopping a Migration

You may stop a migration at any time while it is in progress. 

The migration needs to be currently migrating data, so if the migration is still in 'submitted' status you will need to wait for it to begin migrating before you are able to stop it. If you attempt to stop a migration while it is still in 'submitted', you will receive a warning and your request will be ignored. Wait a few minutes for the migration to begin before trying again.

To stop one or more mailboxes currently migrating:

  1. Open your project.
  2. Select the migrating mailbox(es) that you wish to stop​.
  3. Click on the Stop button.​

Your migration should stop within a few minutes, once the migration server has picked up your request.

Restart a Migration

Sometimes you may need to restart a migration on a mailbox that has stopped or you may need to restart a migration after correcting errors. The migration needs to be in a migrating (stopped, failed, or completed) status, and not showing a status of submitted or queued. 

Once the mailbox shows a status of either stopped, failed, or completed, 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 for migration.

Verifying Configuration

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

  1. Open the project containing items you wish to validate​.
  2. Select the mailboxes you wish to validate.
  3. Click on the Start button in your dashboard.
  4. Select Verify Credentials from the drop-down list.

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

MigrationWiz Process FAQs

Submitting a Migration More Than Once

MigrationWiz was designed to never duplicate items that have been migrated by our service. No matter how many times you submit a migration, you should not encounter duplicates.

But if you do encounter duplicates, it is most likely due to one of the following scenarios:

  1. You selected the option Do not search destination for duplicates in the Project configuration. This option will disable duplicate detection.
  2. You performed a migration previously with a 3rd party tool prior to using MigrationWiz. We will not check for duplicates against data migrated by a third-party tool.
  3. The Source mailbox contains duplicate items. The Destination mailbox will reflect the data contained in the Source mailbox.
  4. You changed the protocol used by the connector to connect to the Source, for example from IMAP to Exchange. We cannot prevent duplicates in this case.
  5. The Source mailbox is forwarding email to the Destination mailbox. This results in two copies: a forwarded item and a migrated item. 
  6. You've enabled specific options to force remigration​ without detection of duplicates, etc.​

Folder Processing Order

MigrationWiz will process the folders based on their item class. The order is the following: 
  1. Calendar
  2. Contact
  3. Mail
  4. Journal
  5. Note
  6. Task
  7. Rule
  8. Document File
  9. Security Groups
  10. Permission Levels
  11. Document Library Permissions
  12. Permissions

Some classes of folders may not exist on some source environments. For example, if you are only migrating documents, no mail or mail-related items will migrate.

The order of the mail folders depends of the order in which they are returned by the source environment.

Progress Bar

The bar length indicates the number of folders processed so far. Because folders typically vary in size, the bar length does not necessarily correspond to the total percentage of items processed. The bar may remain "stuck" at the same length for an extended period of time if the folder being migrated is very large.

The number (for example: 112.18 MB) indicates the amount of data transferred so f​ar. This number will increase constantly, showing the total data transfered thus far, and is independent of the bar length.

You can access more detailed progress statistics for each mailbox by doing the following:

  1. Sign in to your MigrationWiz account.
  2. Locate the Item and click on its status.​

Migration Speed

Comparing your mailbox migration speed with the result of a bandwidth test is comparing apples to oranges. A network speed test generates random bytes in memory and checks how quickly the data can be transferred. A speed test does not convert data, encrypt data, parse data, index data, read data from disk, write data to disk, or authenticate users.

Mailbox data is stored on a disk. When we retrieve mailbox data, it must be read from the disk. When we write mailbox data, it must be committed to disk. To access this mailbox data, the caller must be verified and authenticated. When data is written, it may be indexed. Mailbox data often also needs to be converted between systems.

Mailbox data is typically encrypted during transfer. Mailbox data must be encapsulated in protocol packets in order to be transferred over a network. Mailbox data must be parsed, for example to verify it contains valid MIME, to check if it contains a virus or to determine if it should be classified as spam. Mailbox data can contain hundreds of properties that must be analyzed and stored.

MigrationWiz will only open one connection per mailbox. This ensures we can scale to a large number of concurrent mailboxes. A speed test will try to fill your entire bandwidth, pushing streams of random bytes in parallel. While a faster connection will result in a faster migration, raw network speed is just one of the many factors impacting your overall migration speed.

Was this article helpful?
4 out of 9 found this helpful