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.
An Overview
- 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
Who is it for?
IT admin and developers
Best Sources
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.
The Flow
- 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
Create Package
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)
