Upload
Local files into a library
Files and folders from this computer into a SharePoint document library, through the same Migration API a tenant-to-tenant clone uses. That is why it can preserve Created and Modified dates and the original author instead of stamping everything with today and you.
What it does
- Whether each file arrived, per file, with its folder tree rebuilt on the destination.
- Created and Modified dates as they were on disk, not the moment of upload.
- The original author, where you can map a folder or a file to a person.
- Anything refused, and why, rather than a count that quietly does not add up.
How it runs
- Sign in. The destination tenant, asked when you click the tile.
- Choose how to specify the work. Browse and pick for a one-off into a single place, or a CSV to map many local paths to many destination URLs.
- Set the options. Author mapping and whether to keep dates. A browse-and-pick upload always checks the destination first: a file already there at the same size is skipped, and one at a different size is uploaded again, replacing it.
- It runs. Per-file progress with a live list. Cancel offers Finish the current item, Stop now, or Keep running. Nothing is left half-written: an item is either done or not started.
How it works
Upload reads your selection from disk first. A file or folder whose name or path SharePoint will not accept fails on its own row (nothing inside a refused folder is uploaded) and everything else carries on. The destination library must already exist. Because the Migration API only takes work from a site collection administrator, the run checks the identity that creates the import jobs on the destination; if it is not one, the run tries to grant it for the run and removes only a grant it added.
Folders that already exist at the destination are reused; the rest are created first, as their own import, so every file that follows has its folder. Files then go in size-limited batches: each batch's files are encrypted and uploaded to a storage container SharePoint provides, and SharePoint imports them with the dates from disk (when you keep them) and the author (when you map one). With author mapping, each file's Windows owner is matched to a person, who becomes both Created By and Modified By; without it, SharePoint records the account that ran the import. A file over the Migration API's per-file limit fails on its own row.
By default the destination is not checked first, and a file already at the same path is replaced by the import. Turn the check on and files already there are skipped before anything is staged. Choose to update changed files and an existing file is uploaded again only when its size differs, or, on an incremental re-upload, when it was edited on disk after the previous run started. Nothing on this computer is changed.
If SharePoint cancels an import job on its own, the batch is sent again after a pause. After an import with errors, the destination is asked file by file what actually landed at the right size, and only the files that did not are counted as failed. Those files are kept for Retry failed files, which uploads only them and skips any that turn out to be there. Migration history records the run as Completed only when every file arrived. On a trial licence about one file in ten is deliberately left out and listed as skipped.
What you need
- Write access to the destination library.
- Enough storage quota on the destination.
What it will not do
- SharePoint refuses some file names and some paths that Windows allows. Those are reported per file rather than failing the run.
- Very large files are uploaded in chunks. A dropped connection resumes rather than starting the file again.
- It adds. It does not mirror, so a file deleted locally is not deleted on the destination.