Move / Copy
Same tenant, server-side
Within one tenant, SharePoint can move and copy content itself without the bytes ever leaving the service. That is much faster than a migration, and it is what this uses. Pick the libraries, folders or files, say where they go, and choose move or copy.
What it does
- Whether each item arrived, per item, rather than a single overall total.
- What a move would take away from the source, before it does it.
- Where an interrupted run stopped, so it can resume rather than restart.
How it runs
- Sign in. One tenant, one sign-in. Both ends are inside it.
- Pick the two sites. Source and destination, in the same tenant.
- Choose how to specify the work. Browse and pick for a one-off, or a CSV of source and destination folder pairs for many at once.
- Choose move or copy. Move is SharePoint's server-side move: each item goes first into a temporary __temp folder in the destination library, then into place, and it leaves the source in the first step. Afterwards ShareMaster checks that the source is gone and the item is at its new location. Copy leaves the source alone.
- It runs. Server-side, with per-item progress. 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
Move / Copy hands the transfer to SharePoint's own server-side copy and move jobs, so file contents never pass through this computer. Both sites must be in the same tenant (a OneDrive counts as the same tenant as its SharePoint), and that is checked before anything is planned. Document libraries, folders and files are offered; plain lists are not.
Every run starts by writing a run map: one row for each item to copy or move and where it lands, built by reading the source and the destination. A folder missing at the destination is planned as one row that carries everything inside it. The map also records what each source folder contained and each file's size, before anything moves, so a moved folder can still be checked after its source is gone. Before the first item moves, the run makes sure every folder it lands into exists (creating it where it can, or asking you), warns about any item whose final path would be longer than SharePoint allows, and, for a move between libraries that keep versions differently, asks whether to change a versioning setting, run as it is, or stop. The map is saved after every change, with backups and a separate append-only journal, so an interrupted run resumes from the map rather than starting again.
A copy is one SharePoint copy job per row, and SharePoint's copy takes the latest version of each file only. A move goes in two steps: each item is first moved into a staging folder, __temp, inside the destination library, under a folder for this run, and then moved from there to its final place, so nothing appears at its final place until the second step. A move carries the file's version history, as a SharePoint move does. A row counts as done only when the run has checked for itself: for a copy, that the item is at its landing; for a move, that it is at its landing and gone from the source. When every move has landed, this run's staging folder goes to the recycle bin, and the shared __temp folder only if it is then empty.
Unique item permissions are not carried. Created By and Modified By are whatever SharePoint's job sets, unless you turn on the option to put the source's values back afterwards, which writes them from the record taken when the map was made and confirms each by reading it back. A move can also leave a .url shortcut at each moved item's old location that opens it in its new one, if you ask. When SharePoint refuses an item, the run waits and tries again; if it is still refused and you are at the screen, the item is held on the map and you are asked: try again, copy its latest version instead (keeping or recycling the original), move it to a location you type, or leave it.
Undo builds a reverse plan from the map: a copy's landed files, and folders the run itself created once nothing else is in them, go to the recycle bin; a move's items are moved back. Check results reads where every file is now (destination, staging, still at the source) and changes nothing. Every run is recorded in Migration history, and its report is built from the map. Nothing is ever deleted outright: every removal goes to a recycle bin. On a trial licence about one in ten of the files planned as rows of their own is deliberately left out and listed as skipped; files inside a folder that travels whole are not held back.
What you need
- One account with write access to both sites. This is a same-tenant operation, so there is only ever one sign-in.
- A bearer token, which means a cookie-only sign-in cannot drive this feature. The app says so rather than failing partway.
What it will not do
- Same tenant only. Across two tenants, use one of the clone modes.
- A move takes the item out of the source when SharePoint moves it. It does not pass through the source's recycle bin, and the check afterwards confirms the move rather than deciding whether it happens.
- Whole-site moves are not offered here. Libraries, folders and files are.