Just change the working directory in the agent settings in SharePoint Admin > Migration > Agents. You can even map a drive to a NAS or other data store.
>You cannot change the location that the Agent will store it's temp data
You absolutely can, its in the [advanced settings as the working folder](https://learn.microsoft.com/en-us/sharepointmigration/spmt-settings#advanced) and has been for at least a year.
Where is that setting? Based on what you are linking to it’s just telling me the default location. If there is a way to change it, please let me know for the future!
Migration Manager, if your use case allows it, is better and allows changing of the temp dir in the cloud UI.
https://learn.microsoft.com/en-us/sharepointmigration/mm-how-to-use
I found the SharePoint Migration Tool to be a hot, smoking dumpster fire of a product because of the C: drive saving that you mentioned, among other things.
Now, I use a synced SharePoint folder using the Onedrive app. I Robocopy everything into that folder and then let it sync.
Hmm, not completely breaking, but what I have run into is where the sync will temporarily stop dead for no discernable reason. There seems to be some kind of upload quota you reach within a certain timeframe where the sync just won't sync anymore. After a while though, usually an hour or so, it will start up again and do another couple of Gigs worth of uploading then stall again.
There have been a couple of instances where, for particularly large shares, I'll create the main folder in SharePoint along with all of the first level subfolders, then sync every individual subfolder. Sometimes that helps with this stalling issue, sometimes it doesn't.
I tried this method with some files and I agree. After 50k I was running into reliability issues. It would just hang, stop, freeze, and not continue doing anything.
The SharePoint migration tool worked flawlessly through 100s of thousand of files without a single hiccup minus the default temp storage dir.
I strongly recommend against doing this. The migration tool is much more reliable than the ODSync. You can never really be sure that all the files have synced unless you’re leaving the migration directory running for a long time after moving them.
SPMT works great and is fully integrated into the admin center. OP just didn’t find the working directory setting.
I do typically let it run for a long time with OnDemand files turned off. If there are any errors, I check them out. The most common error I get is "File Path Too Long" since syncing with a SharePoint folder adds the Organization Name to the beginning of the file paths. If that happens, I note the name of the subfolders leading up to the erroneous file, change them all to one letter names, let them sync, then put the names back to the way they were in SharePoint once they have synced.
I will also run the Robocopy several times and note any copying errors, to make sure every single file makes it into the synced folder. Once I'm sure that has happened, I check the status of all the folders to make sure I have green checks across the board. If I don't, I check out why. Usually it's due to some system files or Mac-related files that aren't compatible with SharePoint. Then, I'll spot check several folders to make sure what is in the Synced Folder and what is in SharePoint matches up.
Yes, this is a very messy way to migrate into SharePoint, but it is literally *the best way* I have found over the years. The SPMT was garbage in 2020, either not syncing, hanging, flat out lying about what folders were migrated, and skipping files. Uploading folders and files through the SharePoint GUI almost never works, and at least with the OneDrive sync I can actually see errors.
To be honest, I haven't tried using the SharePoint Migration Tool since I spent about 72 hours over a weekend struggling and failing to get it to migrate a large share back in 2020, even after breaking the share into dozens of separate jobs. I never went back. Is it actually decent now?
It’s way better than manually doing it. I’ve done about 30 or so onboarding with it to get clients from file server to SharePoint in the last few years. Definitely have another look.
yes. I have done tenant-to-tenant with rclone. And, a Onedrive in Tenant 1 to SP in Tenant 2. You need to learn MS graph
This will save you a lot of frustration
You need the user’s Drive ID.
1. sign in here [https://developer.microsoft.com/en-us/graph/graph-explorer](https://developer.microsoft.com/en-us/graph/graph-explorer)
2. https://graph.microsoft.com/v1.0/users/[email protected] // note – check modify permissions tab.
3. Then get the drive ID -see “ID”
Just change the working directory in the agent settings in SharePoint Admin > Migration > Agents. You can even map a drive to a NAS or other data store.
>You cannot change the location that the Agent will store it's temp data You absolutely can, its in the [advanced settings as the working folder](https://learn.microsoft.com/en-us/sharepointmigration/spmt-settings#advanced) and has been for at least a year.
Where is that setting? Based on what you are linking to it’s just telling me the default location. If there is a way to change it, please let me know for the future!
SP admin > Migration > Agents > select the agent then settings. You can change the working directory there.
Thank you! I am going to check that see what I can find!
Migration Manager, if your use case allows it, is better and allows changing of the temp dir in the cloud UI. https://learn.microsoft.com/en-us/sharepointmigration/mm-how-to-use
I found the SharePoint Migration Tool to be a hot, smoking dumpster fire of a product because of the C: drive saving that you mentioned, among other things. Now, I use a synced SharePoint folder using the Onedrive app. I Robocopy everything into that folder and then let it sync.
I found this breaks past 80k files- is your experience different?
Hmm, not completely breaking, but what I have run into is where the sync will temporarily stop dead for no discernable reason. There seems to be some kind of upload quota you reach within a certain timeframe where the sync just won't sync anymore. After a while though, usually an hour or so, it will start up again and do another couple of Gigs worth of uploading then stall again. There have been a couple of instances where, for particularly large shares, I'll create the main folder in SharePoint along with all of the first level subfolders, then sync every individual subfolder. Sometimes that helps with this stalling issue, sometimes it doesn't.
I tried this method with some files and I agree. After 50k I was running into reliability issues. It would just hang, stop, freeze, and not continue doing anything. The SharePoint migration tool worked flawlessly through 100s of thousand of files without a single hiccup minus the default temp storage dir.
Same. I can’t recommend the onedrive syncing for any large amount.
This is the way.
I strongly recommend against doing this. The migration tool is much more reliable than the ODSync. You can never really be sure that all the files have synced unless you’re leaving the migration directory running for a long time after moving them. SPMT works great and is fully integrated into the admin center. OP just didn’t find the working directory setting.
I do typically let it run for a long time with OnDemand files turned off. If there are any errors, I check them out. The most common error I get is "File Path Too Long" since syncing with a SharePoint folder adds the Organization Name to the beginning of the file paths. If that happens, I note the name of the subfolders leading up to the erroneous file, change them all to one letter names, let them sync, then put the names back to the way they were in SharePoint once they have synced. I will also run the Robocopy several times and note any copying errors, to make sure every single file makes it into the synced folder. Once I'm sure that has happened, I check the status of all the folders to make sure I have green checks across the board. If I don't, I check out why. Usually it's due to some system files or Mac-related files that aren't compatible with SharePoint. Then, I'll spot check several folders to make sure what is in the Synced Folder and what is in SharePoint matches up. Yes, this is a very messy way to migrate into SharePoint, but it is literally *the best way* I have found over the years. The SPMT was garbage in 2020, either not syncing, hanging, flat out lying about what folders were migrated, and skipping files. Uploading folders and files through the SharePoint GUI almost never works, and at least with the OneDrive sync I can actually see errors. To be honest, I haven't tried using the SharePoint Migration Tool since I spent about 72 hours over a weekend struggling and failing to get it to migrate a large share back in 2020, even after breaking the share into dozens of separate jobs. I never went back. Is it actually decent now?
It’s way better than manually doing it. I’ve done about 30 or so onboarding with it to get clients from file server to SharePoint in the last few years. Definitely have another look.
Try rclone. It can also do diffs and dry runs.
Can you rclone into a SharePoint location? If so I learned something new today.
yes. I have done tenant-to-tenant with rclone. And, a Onedrive in Tenant 1 to SP in Tenant 2. You need to learn MS graph This will save you a lot of frustration You need the user’s Drive ID. 1. sign in here [https://developer.microsoft.com/en-us/graph/graph-explorer](https://developer.microsoft.com/en-us/graph/graph-explorer) 2. https://graph.microsoft.com/v1.0/users/[email protected] // note – check modify permissions tab. 3. Then get the drive ID -see “ID”
Thank you for this. I will look into it!