Forum Discussion
Solved
Moving or Copying Files: Painfully Slow, Loss of Data
Hello All!
Our company transitioned over to SharePoint Online about a year ago.
One of the largest complaints I have to date, is the time it takes to move or copy files. In cases of one or two files, the time is minimal. But in cases where larger file moves are taking place - the pace of transfer is painfully slow.
For example, today it took approx. 30 mins to transfer only 45.8 MB.
Earlier this month, an employee spent the entire day waiting for files to transfer, only for her computer to stop responding, and have to re-start the entire process the next day. On our previous server based environment, the same transfer would take less than 30 minutes.
Additionally, in some of these larger file moves, users have reported large losses of data. The files were moved, and confirmed, only to come in the next day and they have disappeared.
This issue is decreasing adoption and causing our IT team multiple headaches.
Any suggestions or helpful feedback?
If you're using "Open in Explorer" I think that may be part of the issue, and I'm assuming that you're using Internet Explorer. From personal experience I never really got on with the piece of functionality. It worked well back in 2007 when I first used it, but now there are much better options available.
Option 1 - Move To
When you visit a document library in the modern experience, you can click on the ellipsis against the document and select move to (see attachment "Modern-MoveTo.docx". In Figure 1, you can see the option to move to, and then in Figure 2 you can see that you have a number of options to either move it to OneDrive for Business or to another SharePoint site. When I tested this with a document of approx 1mb it took about 5 seconds to get itself warmed up and then do the move.
Option 2 - OneDrive Sync
The alternative option which has been mentioned before is to use sync (see attachment Modern-Sync.docx). In Figure 1, you can see the ability to Sync your library to your local file system using the OneDrive Sync Client. By hitting the sync button, you'll see it connect to your sync client (Figure 2), and then it will be available from your Windows Explorer windows (Figure 3). Once it's been synced, you can copy and paste documents between synced libraries in the same way as you would with normal files. Again this took only a few seconds to copy, paste and sync between the libraries.
I hope this approaches are useful and that they work. If not, please let us know and we'll see what else we can come up with.
Hillary Barter I'm with you all on this non-sense from Microsoft.
I tried copying 1855 files/folders from one folder to another on the same SharePoint site. It's been already 8 hours and it's still processing with no warnings or errors. Not sure how much longer I have to wait. I migrated all this data and much more for a client with about 480GB in Box using MultCloud tool.
MultCloud is a terrific tool to move data from any cloud to any cloud. The price is reasonable and the support even via email is really good. I should have used MultCloud to move the data inside SharePoint online, but didn't think it was going to take this long. Another option to map a SharePoint site to a virtual drive on your File Explorer is a tool called ZeeDrive from Thinkscape. I've been using it with a client with lots of data sucessfully.
Experiencing lots of issues with very basic Move and Copy commands (within same site, not even between sites) in the modern web interface. Even when it's just a few subfolders with no files, it gets stuck at 0%. We specifically have controls in place to prevent syncing/downloading with client app, why can't the web interface handle extremely basic file operations?
Is there any way to get a detailed report or view the history of Move and Copy operations? Seems like once you leave the page, you can't get any info about the previous Copy and Move tasks?
A question on the process of moving the files. I've read through this post about the amount of time it takes, and I agree... it seems to be quite long in some instances. However... I have another question... Because it is browser based, and I've initiated the move... what happens if I have to shutdown while it is in the process of moving. In my current case, I'm at 81% complete (it did really well up until then), but hasn't moved in a while... if I have to disconnect now... what happens?
Christopher ORPHAL I wondered exactly this. When I had to do the same, it seemed to have continued and completed even with a shutdown. The only issue I have had is when files are open (or Sharepoint thinks a file is open) and they get left behind. I’ve switched to a more labor-intensive process of moving smaller sub-folders, to make the cleanup of unmoved files more manageable.
My experience has been 50/50, half the time it stops and the other half it does move over even if the computer is shutdown. I tried to move 12 folders, each folder had 300 files, all under 1MB. I noticed when I kept refreshing, it was moving 1 file per second. 60 files per minute, 3600 in 60 mins via web browser. We have Office 365 E5, i'm assuming the sharepoint library is on microsofts end, so telling it to move from 1 sharepoint to another, I was hoping it would be fast.
I have a big project at the moment, we built a new sharepoint site and I am task to move all the folder/files from another sharepoint into the new one. Total storage used up is 300GB. Hundreds of folders, thousands of files.
- Having the same issue here, infact we have two issues in our organisation.
We have a number of sharepoints set up usually through the teams app. We then sync these to our desktop and treat them like typical one drive. If used in isolation they are great. However if we move a folder from one sharepoint to another from the desktop syncs, forget it, one drive just melts down and nothing happens until onedrive is reset and a long wait to get it all back to normal.
A microsoft rep with nothing better to suggest said to do it via a browser (I use Edge) moving the folder between sharepoints seems straight forward but we can be waiting hours for folders of a couple of hundred meg to move and of course on occasion accidently close the browser or what ever.
They need to sort this out.- The Move To in browser isn't also a viable solution, as it has number of files and timeout limits that always fires for a few thousand files. You would be hours/days repeating the task to achieve the move, and would need to go down the folders' tree, creating subfolders manually to get all the files transfered. I'm using OneDrive client sync, moving folder by folder and it is taking days. Each folder I move (about 5,000 files, 600 MB) takes many hours to sync with OneDrive client status stalled as "Moving sync files". I have another folder with 200,000 files to move, I will try sync with OneDrive Client, always keep on this device and then, use the migration tool to upload it to the new SP library.
Hillary Barter What is really frustrating about this is that Microsoft has an excellent program for moving files into Sharepoint in the first place. The Sharepoint Migration Tool is free and works great to migrate from the computer, network shares, etc. It is rock solid, handles errors gracefully and retries, etc. It will let you migrate from a local folder or a network share to an online Sharepoint library. It will let you move files from a Sharepoint 2010, 2013, or 2016 server. However, it won't let you migrate folders from one Sharepoint online library to another.
If Microsoft would just add that support, we would be all set!
brianhawthorne Check that all subdirectories are copied as it only copies a couple deep.
- We abandoned the "move" proces. With moving from one Sharepoint group to another (or from Onedrive to Sharepoint), it moves all history files, and it takes forever. Fastest way for us was to first sync all files on file explorer (always keep on this device option), copy them on new Sharepoint group, and then delete files from old location.
Goximus I'm not surprised. After this experience, I won't be using it again. We have a big restructure coming up and we'll do it another way. We *would* prefer to preserve metadata and version history but at the moment, it's unusable for a small number of files, let alone if we tried to move terabytes. Moving using the web interface isn't viable either as we have many folders to move - it needs to be scripted.
Don't fully trust one vendor as well so we backup our entire M365 stack using Veeam. That's good but incredibly slow because of the way Veeam has to interface with M365. So once again, a step backwards from good old Windows file servers.
The cloud is great but in some areas, like this, it's a step backwards. I don't know why traditional file locking couldn't be revisited esp. with pretty fast internet access these days.
- Although even if you sync the source and target folders then using something like robocopy you then get long periods of OneDrive "processing" or worse, just a spinning cog. They really need some more debugging/diagnostic functionality.
The biggest flaw does appear to have been fixed - whereby if you logged onto a computer that you'd not used for ages or restored a snapshot/computer image, the restored computer assumed it was the master and deleted any edits made after it was last turned on. Deleting updated, new and deleted files. Horrible!
- We have the same problem.
From one SharePoint Site Collection moving to another. It copies extremely slow. If I move them in my file explorer, the OneDrive client collapses when there are more then a couple of thousand files to migrate at once.
It is embarrassing for Microsoft to not be able to provide a good solution for such a basic function. But then again, it's Microsoft :).- Shocking that this flaw is still present THREE years later. I've just moved just 750 files/161MB from a OneDrive folder to a Microsoft 365 group. The files have disappeared from the source OneDrive folder locally/in file explorer but they are still there in the document library in SharePoint. They have been uploaded to the new M365 group but OneDrive has been saying "moving shared items" for three hours now. So right now we're in real risk of people accessing/updating the left copy. It's now 11pm in UK. Hopefully it'll actually do the move by start of working day in UK.
I despair at the stability of OneDrive in business. It's a critical component in the M365 stack but it's simply not good enough. They need to poach the Google Drive team and ask them to rewrite it!Rob Nicholson I agree, onedrive for business has always been a half developed tool, pretty much useless for the task, full of promise but, typically, failing at the middle hurdles. I have observed over the past 8 years that M$ don't seem to have the technical expertise to fix it. Shame really but oh well there ya go!
- Same here, moving is almost impossible slow - not moving via Online Sharepoint, but with file explorer and Onedrive sync. I downloaded all files in one group (Always keep on this device), and transfered them in another group. Its 15.000 scanned PDF-s (so it doesn't have versioning), about 10GB in size, after more than two days of syncing I can't wait any longer (internet speed is 100/100 Mbps here), preparing to stop it all, and use copy instead.
- 2021, this is still an issue. SP Online, attempt to move folders from one SharePoint site to another in the same tenant often does not move all the files of leaves a mess of mostly empty folders.
Trying the same process with OneDrive, the files moved locally but OneDrive is in a state of "Moving Shared Items" after 24 hours.
This simple, most basic task of file maintenance needs to be easy and reliable. I am frustrated how this does not work.- We are also seeing major problems doing basic file moves. Even on moderate folders with a few hundred files in the tree, using the Move To, runs, says it is complete. The source folder and many files and sub folders are still there. Over time some additional folder move but it never seems to complete.
We are left with a mess of some un-copied files and some duplicates left behind in the source. Non of these are that large. Simple files like a 70k XL file are left behind.Can we get an official response from someone at MS? I have read and agree with all the above statements. I am currently migrating a companies data from a onedrive business folder to their sharepoint library on the same account. They have 1.1 TB of data. I would be better off downloading all 1.1 TB of data and re-uploading it from scratch than moving the data piecemeal at a time. It is taking forever. However, I want to keep all the versioning for them so this isn't an option.
I dont want to use one drive sync. I am not downloading an end users data to my server. I am simply using your tools, being a cloud provider, to move data from 1 cloud location to another.
And why do you make it so difficult to see file data, size, etc?
Every answer I see from a MS Rep or Volunteer, "Oh just use one drive sync and File explorer".
Why even have the online piece then?
Hillary BarterI recently uploaded 3.48 GB of data and here is what I found. It took several hours to upload (drag and drop), but the biggest problem is the properties listed on the file jump drive verses SharePoint don't match. I went through every folder and completed a comparison and the files matched! What doesn't make sense, if the files are there, why are they not being counted in the properties size or contains xxx files, xxx folders? I completed the whole transfer a second time, completed the same review and one again the files properties don't match or the number of files and folders. It seems Microsoft has an issue with cloud storage. Has any one else experienced this issue?
OK but what I have found is, if you choose to "Always keep on this device" then at least the document Origin and Content details do come across as unchanged:
So I guess MSs answer would be something like Oh yes, this is intended behaviour, isn't it beautiful?! They would see it as no problem at all because all you have to do is to choose "Keep on this device" for all your files. Like everyone is going to rush to do that.
So I just had the thought that M$ want us to use the web interface to get file details (and therefore possibly access the details via PowerShell) but looking at the file details via the web interface is woeful:
Those two panels there are the sum total of the details you get on a file. Maybe we have access to the document metrics via PowerShell. I haven't tried that.
KarlInOz1 RE: if you choose to "Always keep on this device" then at least the document Origin and Content details do come across as unchanged:
Yeah, I found out the same thing, as monthly or so I am trying to relocate large media files off of SP storage and move them over to ODFB storage.
First step is to sync a SP location (which goes somewhere on, but not in, my ODFB), wait for that...doesn't take long since it just builds the structure/stubs. Then I mark a group of those files "Always...", then wait until they sync down. Then I copy those to the target ODFB location, wait for that to complete. Then I go back to the synced ODFB and "Free up space" on the SP files, wait for that to complete. Then finally delete the SP files (stubs) from my synced ODFB location which removes them from SP.
RPITA
Hi Angel105, yes I'm seeing exactly the same - not one of the file attributes is left unchanged, except the file type, in the transfer. Looking at file properties within File explorer. In my screenshots below the properties on the left are from the original file on our file server and the right from the same file on SP. The file has not been modified in any way since moving from the file server so all changes in the properties are from moving to SP.
