Azure Storage for MigrationWiz

Introduction

The following article provides answers to commonly asked questions about the use of Azure storage with MigrationWiz.

MigrationWiz can use Azure storage in three different ways:

As a source endpoint data storage area (Blob Storage)

MigrationWiz needs to have a storage area from which it can access and read source data. Certain migration scenarios follow a two-step process whereby files are uploaded to an Azure container or containers first, before being discovered and used by MigrationWiz during the migration. Migration workloads that require Azure storage for the source endpoint include Google Vault, PST, file server file share, and file server home directory migrations.

As a destination endpoint data storage area for PST exports (Blob Storage)

MigrationWiz needs to have a storage area to which it can write PST data. 

As a destination endpoint staging area for Document and Collaboration migrations (StorageV2)

During some migrations, MigrationWiz uses either Microsoft Shared Storage or customer-provided Azure StorageV2 type storage to temporarily store data during the write process to the destination system. These migrations include data migration to Teams, OneDrive, and SharePoint Online.

The specific migration guide for your scenario will tell you whether or not you need to use Azure storage and will provide specific steps and details for your migration. 

Important

IP lockdown will not work for your custom Azure Storage unless Microsoft server IPs are included as well. For more details on Microsoft endpoints, refer to URL & IP address ranges.

Source endpoints and use of Azure Blob storage

You generally use your own Azure storage when setting up required MigrationWiz source endpoints. If you are performing a PST migration there is an option to use BitTitan-provided Azure storage for smaller migrations.

Your own Azure storage

  • If you use your own Azure storage, there will be no storage limitations.
  • You can read and manage the data in your Azure storage containers.
  • You can upload the PST files into your Azure storage using your favorite upload tool (or even drive the ship to Microsoft).

BitTitan storage for PST import migrations

BitTitan storage is meant to be used for small PST migration projects only; it is a free service provided as a convenience when you do not have your own Azure storage account. 

If you already have an Azure subscription, you should use this during the upload process. However, if you do not have an Azure subscription, you can use the BitTitan Azure storage to store your files temporarily.

  • BitTitan storage has a limitation of 100GB per customer. If you require more than 100GB, you will need to use your own Azure subscription to provision the required storage.
  • For security, you will have to use the BitTitan specialized tool, UploaderWiz, to upload your PSTs to BitTitan Azure Storage.  This will securely upload your files to an isolated container that no one else has access to.  Once you upload the files, you will not be able to read them from the Azure container.  Only MigrationWiz will be able to read the files to retrieve the data from the Azure container into your MigrationWiz project dashboard.

The following retention policies are in place with BitTitan Storage:

  • Your files will be purged from BitTitan storage after 30 days.
  • Your oldest file(s) may also be purged when you are attempting to upload a new file and have reached the 100GB limit.
  • For security, you will have to use our specialized tool, UploaderWiz, to upload.

Destination endpoints and use of Blob storage for PST exports

You need to use your own Azure storage. MigrationWiz will write PST files to this storage. Follow the instructions above to create BlobStorage.

Destination endpoints and Azure StorageV2 storage

Use either your Azure storage or Microsoft-provided storage when setting up relevant MigrationWiz destination endpoints. You do not need to write any data into this storage or remove any data after migration activities are complete - MigrationWiz takes care of this process transparently.

Your own Azure storage:

  • Data is automatically purged from the storage once the write operation has been performed.

Microsoft provided Shared storage:

  • Only use Microsoft shared storage if it is likely that your migration will take less than 3 days. If you have any doubt about how long your migration might take then it is best to use your own Azure storage.

How to create Azure StorageV2 storage for destination endpoints including PST

Using the Azure Portal (unless specified, leave settings as default):

  1. Visit the Azure portal.
  2. Click Storage accounts.
  3. Click Create.
  4. Select the Subscription and create a new Resource group or use a current one.
  5. Name the Storage account.
  6. For Region, select a geographic region for the storage account.
  7. For Performance, select Standard general-purpose V2 account.
  8. In the Redundancy field, select Locally-redundant storage (LRS).
  9. Click the Review button.
  10. When the validation ends, click the Create button.
  11. Once the deployment of the storage account is complete, click the Go to resource button or open up the home page for the new storage account.
    Azure Storage- Create Storage Account.png
  12. In the Security + networking section of the left sidebar, click on Access Keys.
  13. On a notepad, copy the Storage account name and the key1 and save them.
    Azure Storage- Access keys.png

Important

The storage account name and key are required for endpoint creation in MigrationWiz projects where Azure Storage is required or custom Azure Storage is an option.

When creating the container within MigrationWiz:

  • We recommend creating a container named "migrationwiz" and uploading the PST files into this container. If you name the container something else, it will be necessary to enter the Advanced Options for the MigrationWiz archive project and set the bucket name to be the same as the Azure storage container name. If the container name is created as "migrationwiz", then this step is not required, since the default expected bucket name for migration is preset to be "migrationwiz".
  • If the container is created with a name other than "migrationwiz", and the MigrationWiz Advanced Option bucket name is not changed, the migration will fail.

Azure storage components

Storage Account vs. Containers

A Storage Account is what owns the containers where your data resides or will reside. The name of the Storage Account can be found by logging in to your Azure portal and navigating to Storage Accounts. The Storage Account name is entered when setting up your Endpoint in MigrationWiz. 

A Bucket Name is the name of the logical container found within the Storage Account. The Bucket Name can be found by clicking Containers under the heading Blob Service when viewing the details of your Storage Account. If you use an alternative name to 'migrationwiz' you must enter this name in the project's Advanced Options depending on the migration scenario.

Storage Keys

A storage access key is used to authenticate an Azure Blob storage account in a migration project.

Follow the steps below to view the storage access keys for an Azure Blob storage account:

  1. Sign in to the Azure dashboard.
  2. In the navigation pane, click All Resources.
  3. Choose the desired storage account.
  4. Click the key icon to view the access keys for the storage account.
  5. Each storage account has two storage access keys. Copy both. 
  6. To copy a storage access key, click the copy icon next to the key you want to copy.

Delete a storage key after migration

Regenerate the Azure Blob storage access key once the migration project is complete if you don’t plan on reusing the access key. This ensures the storage access key cannot be used to access the Azure Blob storage account when the migration project is complete.

Follow the steps below to regenerate the storage access key for an Azure Blob storage account:

  1. Sign in to the Azure dashboard.
  2. In the navigation pane, choose 'All Resources'.
  3. Choose the desired storage account.
  4. Click on the Key icon to view the access keys for the storage account. Each storage account has two storage access keys.
  5. Click on Regenerate for the desired storage access key.

Regenerating your access keys affects virtual machines, media services, and any applications that are dependent on the storage account. All clients that use the access key to access the storage account must be updated to use the new key.​

Adding files to Blob storage

Uploading files

There are several options available. If metadata information or permissions are needed from an On-Premises environment, like FileServer, use the BitTitan UploaderWiz tool.

Use BitTitan's UploaderWiz tool to upload data to your own Azure storage account in a public blob container. This blob must be a block blob.

When uploading PST files, you could also use UploaderWiz to place them into the BitTitan Azure storage account, but this is limited to 100GB. YOu could also use a utility such as Azure Storage Explorer or use a preferred third-party uploader utility. Upload the files into the blob container that was previously created.

Use the Microsoft Azure Import/Export Service to transfer data to the public blob storage or create and use your own PowerShell scripts to upload files.

As an alternative, you can use a utility such as AZcopy. More information on how to use this with Azure can be found here.

Added files into a MigrationWiz project

Once you have files in either BitTitan storage or your own Azure storage account, you can add them to your MigrationWiz project by following these steps:

From your project dashboard:

Choose Quick Add to manually add the names of the files that have been uploaded into Azure into your project. If using Quick Add, define the full path to your files (filename included), for example: Filename.pst or Foldername/filename.pst.

  • Do not include the URL from BitTitan storage.
  • File names in Azure are case-sensitive.

Or

Click on the AutoDiscover Items green bar to AutoDiscover, and import the names of the files from BitTitan storage.  AutoDiscover is the recommended and easiest option to choose.

  • Click on the blue Start Auto Discovery bar in the left-hand panel.
  • Once the PST files have been discovered, click on the green + Import Items button.

Now choose the Destination to ingest each file into. For example, for PST migrations you will edit the Destination mailbox. For OneDrive migrations, you will choose the Office 365 account to ingest into.

Estimating Azure Costs

Using Azure for your migration will incur a fee from Microsoft only for the Azure storage. Data transfer fees are only incurred with cross-region, and total egress, from Azure traffic. As explained below, there should be no outbound data transfer fees for this migration, because your Azure storage needs to be in the same region as the Destination tenant, for the migration.

Important

If your Azure storage is in the same region as the tenant, then there will be no outbound storage fees, regardless of the number of transfers per project.

When does MigrationWiz transfer data more than once?

Under certain conditions, MigrationWiz will transfer data more than one time. These are some of the scenarios in which MigrationWiz will transfer data from your blob storage more than one time:

  • Restarting a migration after the maximum error count is reached
  • Restarting a migration after the maximum license consumption is reached
  • Both of the above limits are set in the project's Advanced Options screen.
  • Restarting a migration after a failed pass
  • Restarting a migration after pausing it

In each of these scenarios, when you restart the migration, MigrationWiz starts from the beginning. 

Useful Microsoft Azure URLs

Microsoft Azure website (to purchase a subscription): Microsoft Azure website

Estimating storage costs: Microsoft Azure Pricing Calculator 

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