Forum Discussion
Moving Folder between sites stop progressing, but resume even after cancelling it
I wanted to move a folder which contain 4500 Files, of total size 60 GB. now i selected the folder and i define to Move it to another site. the process started , but hanged on 76% as follow:-
it kept on the same progress for about 2 hours. and i have noted that it hangs on a source file which have total size of 37.5 GB
where the file on the destination only got 16 GB:-
so inside the Progress popup, i clicked on Cancel button. and i started to move the folders one by one , and i skip the above large file. but after i finished the manual work, i noted that the large file and its parent folder no longer exists inside the source site...and when checked the destination site i noted that the file had the full size on the destination.. so what had actually happened? why/how the large file consume the move even that i cancelled the move process? also as per this documentation about the SharePoint limitations:-
https://learn.microsoft.com/en-us/office365/servicedescriptions/sharepoint-online-service-description/sharepoint-online-limits#moving-and-copying-across-sites
that the max file size for the move is 15 GB .. so how the file got moved in our case, even that its size is 37.5 GB??
any advice?
The most accurate advice here would be: avoid relying solely on the UI "Cancel" for large operations, especially when large files are involved. Always verify source and destination content before taking further action. Also, be aware that SharePoint may support larger file moves than officially documented, but without warnings or clear feedback in the interface. For critical content, consider breaking down moves into smaller batches or using PowerShell with SharePoint migration tools that offer better logging and control.
The "Cancel" button in the Move process in SharePoint can give the impression that the operation has stopped, but in reality, some backend processes may continue, especially if the move is already in progress for large files. SharePoint and OneDrive use background operations via Azure BLOB storage, which can resume or complete transfers even if the UI is cancelled, especially for large files that already began copying. While Microsoft documentation mentions a 15 GB limit for cross-site moves, this limitation might not strictly apply in all scenarios due to backend improvements or inconsistencies in enforcement, and SharePoint may not always notify users when trying to move files larger than the documented limit. This behavior can lead to confusion, as the UI lacks clear communication about what is happening behind the scenes, especially with large files.
Here are some guesses as to what might have happened, without knowing for sure.
Why Did the File Continue Moving After Cancelling?
- Background Processing in SharePoint:
- When moving large files (especially across sites), SharePoint doesn't move them instantly but instead uses a background job to handle the transfer.
- Even if you cancel the move, SharePoint may continue processing already queued files in the background.
- Resumable Transfers in SharePoint:
- Large files are moved using chunked uploads, meaning parts of the file are copied in small sections.
- Since your file was already partially transferred (16GB out of 37.5GB) before cancellation, SharePoint may have decided to resume and complete the move instead of rolling it back.
- Delayed Deletion from Source Folder:
- Sometimes, the source file isn’t immediately deleted until SharePoint verifies the file transfer is complete on the destination.
that the max file size for the move is 15 GB .. so how the file got moved in our case, even that its size is 37.5 GB??
You're right that the SharePoint Online documentation states a 15GB max file size limit for moves across sites.
However, here are possible explanations for why it worked:
Your SharePoint Tenant Has Increased Limits:- Microsoft sometimes increases limits based on tenant configurations or updates (some tenants support up to 250GB per file).
- Check if your organization has a higher file size limit by running:
Get-SPOTenant | Select-Object -Property MaxFileSize
- If your IT admin has a custom setting, it may allow larger files.
Move Happened via "Copy + Delete" Instead of Direct Move:
- If a file exceeds the limit, SharePoint sometimes copies the file first, then deletes the original.
- This can bypass the limit because SharePoint is not technically "moving" the file but copying it instead.
Using OneDrive Sync or Another Method in the Background:
- If OneDrive or another file sync tool was involved, it may have assisted in moving the large file in chunks.
Your case likely happened due to chunked transfer resuming even after cancellation, and the file move method bypassing the normal 15GB limit. SharePoint sometimes processes large file moves differently than expected. If you need full control, moving files manually or via Power Automate might be a safer option. The text was created with the help of AI.
My answers are voluntary and without guarantee!
Hope this will help you.
thanks for the reply. but if we cancel the process by clicking on the "Cancel" button, but at the same time it will resume in the background then what is the idea of having the "Cancel" button?
Second question, Also , if Microsoft has a limitation of 15 GB for single files when doing the Moveto, then why it did not show any message that we have a file larger than the allowed limit? before we started or before allowing us to do the MoveTo?Your questions are completely valid, and they highlight some of the frustrating inconsistencies in SharePoint's handling of large file moves. Here’s why these issues occur:
1. Why Does the Move Resume Even After Clicking "Cancel"?
The "Cancel" button in SharePoint MoveTo doesn't always work the way users expect. Instead of an immediate halt, here’s what likely happens:
- Backend Queuing: SharePoint moves files using Azure-based background jobs. If a large file transfer is already in progress, the "Cancel" request might only stop new files from starting but not affect ongoing file transfers.
- Chunked Transfers: Large files are moved in chunks. If enough chunks have already been transferred, SharePoint may decide to finish the move instead of rolling it back—especially to avoid data inconsistency.
- No Rollback for Partial Moves: Unlike traditional file transfers, SharePoint doesn’t necessarily delete a partially moved file if the process is canceled. Instead, it may continue and complete the operation in the background to ensure data integrity.
The Real Problem: Misleading UI
The presence of a "Cancel" button gives users the impression that they have full control, but in reality:
- It only cancels new files from being moved and does not necessarily stop large files in progress.
- There's no clear feedback to inform users that a file is continuing to move after cancellation.
This is a design flaw that Microsoft should improve by giving users better visibility into background operations.
2. Why Did SharePoint Allow Moving a 37.5GB File Despite the 15GB Limit?
Microsoft's documentation states a 15GB file limit for cross-site moves, but in reality:
- This limit may not be strictly enforced across all tenants.
- Backend improvements may have quietly increased this limit without updating the documentation.
Possible explanations for why it worked:
1. Your Tenant Might Have a Higher Limit
Some Microsoft 365 tenants support larger file sizes (up to 250GB per file for uploads). You can check your current limit by running:
powershell
Get-SPOTenant | Select-Object -Property MaxFileSize
If this setting is above 15GB, SharePoint might have allowed the move without warning.
2. SharePoint Used "Copy + Delete" Instead of "Move"
Sometimes, when moving large files, SharePoint internally copies the file first to the new location and then deletes the original.
- This bypasses the "move" limit since it's treated as a copy operation instead of a direct move.
- The move process might have failed the direct "MoveTo" action but silently switched to "Copy + Delete" without notifying you.
3. UI Doesn’t Show Warnings for Unsupported Moves
One of the biggest issues in SharePoint is that it does not always warn users when a file exceeds a stated limit. Ideally, before starting the move, SharePoint should:
- Check file size against the documented 15GB limit.
- Display a warning if a file is too large.
- Prevent the move from starting instead of letting it fail midway.
However, Microsoft does not enforce this consistently, which can lead to unexpected behaviors like what you experienced.
Final Thoughts & Best Practices
Your experience highlights two main issues in SharePoint:
- The Cancel button is unreliable for stopping large file moves.
- The 15GB move limit may not be strictly enforced, leading to inconsistencies.
Best Practices to Avoid This Issue in the Future:
Use PowerShell for Large Moves: It provides more control and logs what happens.
Manually Copy, Then Delete: If a file is very large, manually copy it first and delete the original instead of relying on MoveTo.
Check Limits in Your Tenant: Run Get-SPOTenant to verify your max file size settings.
Monitor Background Jobs: SharePoint may not stop ongoing transfers even if the UI shows otherwise.All comments and possibilities were taken from the AI and from some Microsoft pages.
My answers are voluntary and without guarantee!
Hope this will help you.
