The single biggest benefit of this new Migration PowerShell API is speed. Close to 5 times faster than CSOM calls. The new API was released today and is available for public consumption.
- Source – file share, SharePoint on-prem, potentially any other data source
- Package – create package for the API to be able to accept it
- Azure temporary holding storage – use power of Azure to bring content faster in MSFT network
- SharePoint /OD4b final destination – timer job based import in a scalable way that will not hurt the service using back-end resources
We take you through 10 best practices, considerations, and suggestions that can enrich your Microsoft Teams deployment and ensure both end-user adoption and engagement.
Who is it for?
IT admin and developers
On-prem and file shares in OD4B
Why use API?
- Resources dedicated to ISV and IT admin
- Limited calls to end user entry points, meaning this won’t get impacted by the CSOM throttling.
- Better equipped to scale to the demand
What about Speed?
Type of content does impact the rate of ingestion; using backed resources; lots of small, scenario specific, tweaking that can help get best out of API, preliminary data suggest 5X the speed of CSOM before throttling.
- Package is created
- Gets uploaded to azure blob storage
- One CSOM call is made to start the migration process
- Azure queue gets real time updates
- Once complete the logs in the package get updated
Generate the appropriate XML to go with the files – resemble a lot to the PRIME package, 8 xml in a package + the content (don’t preserve taxonomy, workflow metadata)
Upload to Azure Blob
For each package you’ll need to have two containers: 1 for manifest and 1 for content. It uses the same queue for all packages.
The Queue and Logs
Use same queue for multiple packages – will get update for job started and completed. The log file is stored in each manifest container (will get error and warning for each log)