Moving Folder between sites stop progressing, but resume even after cancelling it

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.