These limitations have a significant impact not only on what is possible with migrations of on-premises SharePoint and other content to SPO, but also on performance of migrations to SPO.
Microsoft continues to expand these APIs, and it is likely that many but not all of these limitations will be removed over time
Microsoft continues to expand these APIs, and it is likely that many but not all of these limitations will be removed over time
Limitation and Impact
| LIMITATION | IMPACT |
|---|---|
| Limited APIs. Migrations to on-premises and private cloud (e.g. Azure/Amazon/O365-D) implementations of SharePoint support the use of the full SharePoint Server Object Model, the richest API available for SharePoint, or a thin web services layer that exposes the SharePoint Server Object Model (Metalogix Extensions Web Services/MEWS), for both reading, and writing SharePoint Content. Due to the multi-tenant nature of SPO, Microsoft cannot expose the full SharePoint Object Model in SPO. |
Limited automation and controls around migration and provisioning. Microsoft currently expose three, relatively limited API’s that are useful for migrations: The Client Side Object Model (CSOM) The Native Web Services (NWS) API The REST based interfaces to the CSOM |
| Inability to connect at the Farm/Tenant level (CSOM) – With the full SharePoint Object Model or MEWS, users can connect at the Web Application or Farm level. With the CSOM adapter users cannot connect at the closest equivalent, which is the Tenant level | Users have to create Site Collections in the SPO admin page prior to connecting to them. Using 3rd party migration tools, users may have to create a separate connection for each Site collection in SPO. Users are unable to browse/search for all root level Site Collections, and may require more steps to promote Sites to Site Collections. |
| Inability to preserve Item IDs in lists | Lists with dependencies on other lists such as Lookup columns rely on Item IDs in the Lookup lists. Because the CSOM does not support retaining the Item ID of list items, some 3rd party tools have created workarounds that may impact performance. |
| Copying MySites can only be done one MySite at a time, and does not include User Profile information. | Unlike on-prem to on-prem migrations where MySites can be moved in a single operation, in SPO admins must first create each MySite. Admins then need to connect to each MySite Site Collection separatey, and then copy the content from the source, pasting it into the target MySite. Admins cannot copy MySite profile information. |
| Versioning limitations in the CSOM API. | No support for migration of minor versions of documents Authorship information for rejected versions in a document library with approval is lost. |
| Nintex workflows cannot yet be migrated to Office 365 due to these same CSOM limitations. | Nintex workflows must be recreated using the Nintex SPO offering to the best extent as possible. |
| Most on premises 3rd party solutions are either not available in SPO, or their functionality is greatly reduced | Work with vendor to understand product roadmap and capabilities. Other options are to build using out of the box capability. |
| Inability to troubleshoot issues | Required to work through Microsoft support and SLAs. Retrieving a correlation ID for a error could take days/weeks |
Summary
So let summary. Before you do the migration, make sure you understand the limits of the platform, and map these limitations against your SharePoint inventory. Also, prioritize the impacts to each site and team, and develop a mitigation plan for each.
