This article is a chapter from Quadrotech’s popular eBook, ‘Everything You Need To Know About Office 365 Tenant to Tenant Migrations’.
SharePoint Online (SPO) and OneDrive for Business (ODFB) are part of the core workloads present in Office 365, providing the ability to not only to store documents and information but also to build modern workplace solutions and services on top of both services.
Similar to the other Office 365 core workloads (Exchange Online and Skype for Business), we have the following common scenarios when considering the migration of SPO and ODFB information and contents structures between two or more Office 365 tenants:
- Divestiture scenario: A Business Group that currently uses Office 365 decides to disincorporate one or more companies that are part of the Group and each of these companies wants to keep using Office 365. They need to move all the SPO and ODFB data from the Business Group Office 365 tenant to the new subscriptions created for each company.
- Merger or acquisition scenario: Two or more companies already using Office 365 are integrated into a new company that will also use Office 365 (one of the existing Office 365 tenants or a brand new one). Under this scenario, it might be required that they migrate existing SPO and ODFB contents and information structures from the source Office 365 tenants to the definitive tenant.
- Change of brand name scenario: A company already using Office 365 decides to change business name and migrate all the data to a new Office 365 tenant that uses the new brand name.
- Change of data residency scenario (change of data center): A company based on one continent, using an Office 365 provisioned to the corresponding datacenter region, decide to move their headquarters to another continent so they are required to provision a new Office 365 in a local datacenter due to compliance regulations. Under this scenario in which geo-replication is not an option, the company will need to migrate SPO and ODFB data to the new Office 365 tenant.
- Common requirement to split data geographically. Over the last few years, several countries in the world have passed legislation requiring that the data generated in the country, must stay in the country. In this case, the information in the main tenant should be identified and moved to the local tenant(s).
- Data and contents structures migration scenario from a pre-production/staging tenant to production tenant: A company started to use Office 365 in a pre-production/staging/test tenant and needs to migrate data and contents structures to the definitive Office 365 subscription.
Approaches for a SPO and ODFB Tenant to Tenant migration
We can consider two main approaches when migrating SPO and ODFB information and content structures between two Office 365 tenants:
- Manual approach: Information and content structures are moved from the source to the target tenant following manual steps. This approach is time consuming and error-prone.
- Automatic approach: Once some configuration steps have been taken, information and contents structures are moved between tenants without the need of human intervention. This approach implies the use of a third-party migration tool or having a team of migration engineers that will design and build the required migration solution.
For each of these approaches, we have one or more migration techniques (Table 1) that can be used in an SPO and ODFB Tenant to Tenant migration.
| Migration Approach | Migration Techniques |
| Manual Migration | Technique #1: Manual download and upload the files and folders that need to be migrated. Download and upload operations are done by means of a modern Internet browser. Technique #2: Local synchronization of the files and folders to be migrated using the ODFB Sync client and copying them to the target site / or ODFB using the ODFB Sync client. |
| Automatic Migration | Technique #1: Migrate information and content structures using any of the Office 365 APIs available for migration scenarios. Those APIs can be used on a custom .NET solution or in a PowerShell script. Technique #2: Move information and content structures between tenants using a third-party migration tool. |
Table 1.- Migration Techniques for each migration approach described.
Each migration technique has its advantages and disadvantages. Some of them are reflected in Table 2.
| Migration Technique | Advantages | Disadvantages | |
| Manual Migration Approach | Manual Download / Upload | Migration can be done without investing in a third-party tool or a custom solution. | Document versions and metadata are not preserved. File permissions are not migrated. It’s a time-consuming technique. Lists and list items cannot be migrated – only document libraries. Contents structures (Site Collections | Sites | Lists and Document Libraries) must be created first. |
| ODFB Sync Client | Migration can be done without investing in a third-party tool or a custom solution. | Document versions and metadata are not preserved. File permissions are not migrated. This technique can consume a considerable part of the available bandwidth. It’s a time-consuming technique. Contents structures (Site Collections | Sites | Lists and Document Libraries) must be created first. | |
| Automatic Migration Approach | Office 365 APIs | Migration can be done without investing in a third-party tool or a custom solution. It allows you to preserve document versions and metadata. File permissions can be migrated. Content structures can be recreated as part of the developed migration solution. | Good knowledge of Office 365 APIs is required in order to build a custom migration solution. Good knowledge of SPO and ODFB is required. Various particularities must be considered when designing and building the migration solution, for instance, the throttling performed by SPO and ODFB in scenarios with a lot of requests to both services. Developing a custom migration solution requires a significant time investment. It may be necessary to hire the services of an Office 365 Developer to code the migration solution. Requires intensive testing to ensure the quality of the migrated data. |
| Third-party migration tools | A third-party migration tool has been specifically designed and built to simplify SPO and ODFB migration processes. A third-party migration tool is supposed to use Office 365 APIs following best practices and development patterns. The solution will preserve document versions and metadata. File permissions can be migrated. It provides the ability to re-create content structures. A third-party migration tool is ready to handle SPO and ODFB particularities such as the built-in throttling mechanism. Special SharePoint functionality, such as Workflows, for example, can also be migrated. | Budget is required to buy the third-party migration tool. Some training on how to use the tool can be required. Alternatively, a migration consultant should be hired for the migration using the third-party tool. |
Table 2.- Advantages and disadvantages of each migration technique.
Although it’s usually recommended to use an automatic migration approach for an SPO and ODFB Tenant to Tenant migration, there may be scenarios where a manual approach for migration is not feasible. Table 3 demonstrates when to use each approach depending on the migration scenario.
| Criteria | Manual Approach | Automatic Approach (Custom Solution) | Automatic Approach (Third-party tool) |
| No budget restrictions | ✔ | ✔ | |
| Budget restrictions | ✔ | ||
| Budget restrictions, but there are resources (developers) available for the migration | ✔ | ||
| Time restrictions for doing the migration | ✔ | ||
| No time restrictions for doing the migration | ✔ | ✔ | |
| Migration errors and issues should be minimized | ✔ | ||
| Batched migration is possible and easy to setup | ✔ | ✔ | |
| Migration of metadata, document versions and permissions are not required | ✔ | ||
| Migration of metadata, document versions and permissions are required | ✔ | ✔ | |
| Migration of Lists is required | ✔ | ✔ | |
| Migration of special SharePoint instruments (Workflows, Managed Metadata, etc.) | ✔ | ✔ |
Table 3.- When to use each migration approach.
Thanks for the helpful article, also I would to share 2 ways for migrating SharePoint Online and OneDrive for Business:
– SharePoint Migration Tool: The SharePoint Migration Tool is a free migration tool provided by Microsoft that allows you to migrate content from SharePoint Server, file shares, and OneDrive for Business to SharePoint Online and OneDrive for Business. The tool supports bulk migrations as well as delta migrations, where only changes made since the last migration are migrated. The SharePoint Migration Tool also provides a user-friendly interface that allows you to select the content you want to migrate, map metadata and permissions, and monitor the migration process.
– Third-party migration tools: There are several third-party migration tools available that can help you migrate SharePoint Online and OneDrive for Business. These tools often provide additional features and functionality beyond what is available in the SharePoint Migration Tool, such as support for custom metadata, incremental migrations, and pre-migration assessments. Some popular third-party migration tools include Gs Richcopy 360 , ShareGate, Metalogix, and AvePoint.