SharePoint Online's native Move To and Copy To behave very differently from each other. The table below shows at a glance what each operation preserves.
| Property | Move To (same site) | Move To (cross-site) | Copy To |
|---|---|---|---|
| File content | Preserved | Preserved | Preserved |
| Version history | Preserved | Preserved | Not preserved (version 1 only at destination) |
| Column metadata values | Preserved | Preserved if column exists at destination | Preserved if column exists at destination |
| Content type | Preserved | Preserved if content type exists at destination | Preserved if content type exists at destination |
| Unique permissions | Preserved | Removed; item inherits from destination library | Removed; item inherits from destination library |
| Sharing links | Retained | Broken | Broken |
| Timestamps (Created / Modified) | Preserved | Preserved | Reset to time of copy operation |
| Author (Created By field) | Preserved | Preserved | Reset to user performing the copy |
| Files that are checked out | Must be checked in first | Must be checked in first | Must be checked in first |
Move To within the same site: full fidelity
Moving a file within the same site is the closest SharePoint Online gets to a lossless relocation. Version history, column values, unique permissions, timestamps, and sharing links all survive intact. The file simply appears in the new location. This makes within-site Move To appropriate whenever you are reorganising a library structure, splitting a large library into sub-libraries, or repositioning folders without wanting to lose audit history or access controls.
The one requirement: the file must be checked in. Files checked out to another user cannot be moved. An owner or site collection administrator can discard the check-out if the user is unavailable.
Move To across sites: what changes at the site boundary
Cross-site moves preserve version history and timestamps, but three things do not survive the boundary.
Unique permissions are dropped. If the file had broken permission inheritance (its own explicit access list), those settings are removed at the destination. The file inherits permissions from the destination library instead. For background on unique permissions and the limits that govern them, see the unique permissions limits reference.
Sharing links are broken. Any "Anyone with the link" or specific-person sharing links tied to the original file become invalid after the move. Recipients who click an old link get a not-found error. Sharing links need to be recreated at the new location if they are still needed.
Column values may not map. If the destination library lacks the same columns as the source (different content type, fewer metadata fields), the values for unmapped columns are silently dropped. Before moving files cross-site, compare the column schemas of source and destination. The guide to moving files between SharePoint sites covers the preparation steps.
Copy To: what you always lose
Copy To is not a migration tool. It creates a brand-new file at the destination; the original stays in place. Three properties are always absent from the copy, regardless of whether the destination is in the same library or a different site:
- Version history. The copied file begins at version 1 at the destination. All prior versions exist only on the original.
- Timestamps. The Created date and Modified date on the copied file show the time of the copy operation, not the original file's dates.
- Author. The "Created By" field records the user who ran the copy, not the original document's author.
This matters most when compliance or audit processes depend on file provenance. If a record needs to reflect its actual creation date or its original author, Copy To is the wrong operation. Use Move To where the original location can be vacated, or a migration tool that preserves source metadata.
Copy To is the right call when you need the original to remain in place and want a fresh duplicate as a working copy or template instance.
Practical limits of the native operations
| Limit | Value | Notes |
|---|---|---|
| Items per operation (native browser UI) | 500 items | Selecting more than 500 items in the SharePoint file browser and using Move To or Copy To is not supported. Large batches should be split into segments or handled via PowerShell or ShareMaster. |
| Maximum file size per file | 250 GB | Same as the general SharePoint Online upload limit. Files larger than 250 GB cannot be uploaded or moved within SharePoint Online. |
| Files checked out to another user | Blocked | The checked-out user must check in the file (or a site owner must discard the check-out) before a move or copy can proceed. |
| Cross-tenant operations | Not supported | Native Move To and Copy To cannot transfer files between two different Microsoft 365 tenants. Cross-tenant transfers require a migration tool such as Clone Master. |
| Files in a library with a required field with no default | May be blocked | If the destination library has a required column with no default value and the source file does not have a value for that column, the operation may fail or leave the column blank depending on the SharePoint version. |
Choosing the right operation
Use Move To when you need to preserve version history and the original location can be vacated. Same-site moves are fully lossless. Cross-site moves lose unique permissions and sharing links, so check both before starting.
Use Copy To when the original must stay in place, and when version history, original timestamps, and author attribution are not important at the destination.
For operations on more than a few hundred items, or when you need to move content systematically across many libraries or sites, the native browser UI becomes slow and error-prone. The comparison of methods for moving files between SharePoint sites covers the native UI alongside PowerShell and ShareMaster's resume-safe Copy To and Move To tools side by side.