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
The IT Leader's Guide to Multicloud Readiness
This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.
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)