Structure and content
Copy schema and content together
The thorough clone. It builds the lists and libraries on the destination (their columns, content types, views and folder structure) and then fills them with every item, file, version and permission. This is the mode for moving a site to another tenant, or standing up a copy of one that already exists.
What it does
- Lists and libraries are created on the destination with their schema, so nothing has to exist there first.
- Files arrive with their version history, and with Created By and Modified By intact rather than showing you as the author.
- Permissions and SharePoint groups come across, with users and groups mapped where the destination tenant names them differently.
- On a whole-site copy with Include child subsites ticked (off by default), subsites are copied too. The tree is passed over more than once so a column a content type needs is there before the item that uses it.
How it runs
- Sign in to both ends. Source and destination sign in independently, because they are frequently different tenants with different accounts. Both are asked for up front, not halfway through the run.
- Pick the source and the destination. One site each. The destination can be an existing site or one created for the run.
- Choose the scope. The whole site, or only the lists and libraries you tick. Each list can be set to Copy, Structure only, or Do not copy.
- Answer the questions up front. Where existing objects collide, how to map users and groups, and what to do about items already on the destination. All asked before the run, not during it.
- It runs, and it says what it is doing. Per-list progress with a live item list and a separate log. Cancel offers Finish the current item, Stop now, or Keep running. Nothing is left half-written: an item is either done or not started.
- Read the report. Every item that moved, every item that did not, and why. Compare items, on the Reports menu, is the independent check afterwards.
How it works
Before anything is written, the run checks both ends. On the source, if the account that reads it is not a site collection administrator, the run tries to make it one, which works when that account is a SharePoint administrator; that grant is left in place afterwards. If it cannot, the run carries on with a warning that some content may be missed. The destination site is created if you asked for a new one. If the destination already existed, or this is a resume, and any list the run is about to write into is already there, you are asked once, for the whole run, what to do about content already on the destination. Read-only checks of both tenants then run, and a blocking finding stops the run before anything is written.
The structure stage creates any subsites first, then works through every web in passes, finishing each pass everywhere before the next begins, so a lookup in one web can point at a list in another: site features; site security (permission levels, SharePoint groups and their members, the site's own permissions); the managed metadata term sets the site uses, created where missing; site columns, content types and lists; then the columns that depend on other things (lookups, people, managed metadata, calculated); then content types are completed with their columns; then views, column and view formatting, folders, Document Set and Document ID settings, and the site's title, logo and regional settings. When this run created the destination web, its permissions are replaced with the source's; when it is merging into a web that already existed, the source's permissions are added and nothing is removed. A subsite that fails is counted and skipped along with its children, its siblings carry on, and no content is imported into a web whose structure did not finish.
Content then goes list by list through Microsoft's Migration API. Items are read from the source in folder-sized batches; each batch's files are downloaded, packaged with their metadata (version history, Created and Modified, Created By and Modified By, and permissions when you chose them), encrypted, and uploaded to a storage container SharePoint provides for the import, and SharePoint imports the package into the destination list. Before importing, the destination list's version limit, content approval and required check-out are relaxed so they cannot interfere, and afterwards they are set back to match the source, together with unique-value rules and lookup delete behaviour. Files above a size threshold skip the Migration API and are uploaded directly after the batches, with their current version only. Items SharePoint would refuse (a name with characters it does not allow, a blocked file type, a file checked out to someone) are taken out of the batch and listed, so they cannot fail the items around them.
Where the app has tenant administrator access, two temporary changes are made for the content stage. The identity that creates the import jobs is made a site collection administrator of the destination if it is not one already, and that grant is removed at the end only if this run added it. If the destination blocks custom scripts, that setting is switched off for the content stage so site pages can be imported, and switched back afterwards; the original value is saved to disk first, so it is restored on the next start if the app stops mid-run. When the theme option is on, the source tenant's custom themes are added to the destination tenant once per run.
After each batch imports, the destination is checked for what that batch sent; anything missing or empty is sent once more, and anything still missing, or that could not be checked, is reported as failed rather than copied. At the end of each web, every list's item count is compared on both sides and a shortfall is reported. Only when every web's content is in does the run write what links into content: references between pages in different webs, each web's home page, and navigation, because SharePoint refuses a navigation link to a page that does not exist yet. Hub site membership follows the source where it can, and never fails the run. Alerts are listed in the report, never recreated. Each run gets its own row in Migration history and its own log, which the downloadable report is built from, and completed batches are checkpointed so an interrupted run can be resumed. On a trial licence about one file in ten is deliberately left out and listed as skipped.
What you need
- Site collection administrator on the source and on the destination. A clone reads permissions, which ordinary read access does not reach.
- Enough storage quota on the destination tenant. Version history is usually the part that surprises people.
What it will not do
- A large site is a long run, measured in hours rather than minutes. It reports throughput as it goes rather than going quiet.
- An interrupted run resumes from where it stopped. It does not start again from the beginning.
- Nothing is deleted on the source, ever. The destination is only added to unless you explicitly chose to overwrite.
- Some things SharePoint simply will not let anything copy, such as workflow history. Those are listed in the report rather than passed over silently.