The Office 365 Import service was the first method to migrate content into Office 365 in order to take advantage of Blob storage. It is available in the data import section of the tenant administration website. It lets you create the Blob storage and associated parameters to be used for the uploads and monitor the progress and result of each upload package.

Being able to take advantage of an existing Blob storage might be necessary in scenarios where the content and destinations are in different locations (you can select the region where the Blob storage will be set up). You can access the logs and monitor job status either through the tenant administration website or through the Azure Blob storage explorer.

A disadvantage of this method is that the content is not encrypted while in Blob storage. The documentation on the administrator website shows you how to create upload containers and how to access them through their shared access signature (SAS) URL. These are generated through the data import wizard and are private, so encryption of the content might not be a problem unless it is for very sensitive information.
The main issue with this approach is that you need to generate the SAS URLs and containers for each package individually, making it suitable for a handful of destinations but not for a large-scale migration where full automation is needed.

As the focus of this book is on achieving tasks through scripting, we will review an alternative approach that leverages the Office 365 Import service through the SPO API. The main difference is that, instead of generating SAS URLs for each file container through the website wizard, we will use the Azure Blob storage account instead as well as the key that will let us create the containers through PowerShell.