Migrating 64 GB from network driv to sharepoint is taking 70 ++ hours

The elapsed time is not explained by total size alone. The main factors in this case are likely the item profile, source read speed, network path, and throttling.

From the screenshot, the biggest immediate signal is this:

• 66,022 items scanned
• 25,511 items with scan issues
• 29,845 migrated out of 40,511

That means the job is not just moving 64 GB of data. It is also spending time scanning, validating, and handling a large number of items and issues. SharePoint migration performance is strongly affected by:

• Small files and high file counts: smaller files usually migrate slower than larger files because of higher per-file overhead.
• Source computer/NAS read performance.
• Migration computer disk/RAM performance.
• Network speed between the migration computer and Azure blob storage.
• SharePoint API throttling, especially during weekday daytime hours.
• Anti-virus or other processes competing for CPU, disk, or network.

A few important points apply directly here:

1. Small files migrate slower than large files. Microsoft states that larger file sizes generally migrate faster, while small files create more overhead and processing time.
2. Source reading is often the bottleneck. Microsoft telemetry says the typical bottleneck is source reading, including source disk performance, agent computer performance, RAM, competing consumers, anti-virus, and network speed.
3. Throttling cannot be turned off. Microsoft does not disable migration throttling, and opening a support ticket does not lift it.
4. Weekend and evening hours are better. Background apps such as migration tools get higher throughput during evening and weekend hours for the region.

For a faster weekend migration, use this approach:

1. Open the Scan Summary report first
   • The screenshot shows 25,511 items with scan issues.
   • Resolve those issues before the live cutover where possible, because problematic items slow the process and reduce completion rate.
2. Check whether the data set contains many small files
   • 64 GB with tens of thousands of files often performs much slower than 64 GB made of large files.
   • If the NAS content is mostly small files, slow throughput is expected.
3. Run the migration during evening/weekend hours only
   • This aligns with Microsoft guidance because weekday daytime has tighter throttling for migration workloads.
4. Improve the migration workstation path to Microsoft 365 and Azure
   • Use a migration computer with fast network access.
   • Stop other applications that compete for bandwidth.
   • If possible, avoid running the migration from a slow workstation or over a congested network path to the NAS.
5. Check the source bottleneck
   • Since the source is a NAS, verify NAS disk performance and whether other users or processes are actively using it.
   • Anti-virus scanning on the migration computer or source path can also slow the job.
6. Split the migration into multiple tasks where practical
   • Microsoft recommends running parallel tasks against different site collections, if possible.
   • Do not over-queue requests; Microsoft recommends not having more than 5,000 migration jobs/requests in the queue at one time.
   • Also make sure each task completes before uploading new migration requests.
7. Package efficiently
   • Microsoft recommends packaging at least 250 files per transfer, with package sizes of at least 100 MB and less than 250 MB for better throughput. SPMT automates packaging, but the guidance explains why some content patterns perform better than others.
8. Estimate before the live run
   • Use the Migration Time Estimator in Migration Manager as a preliminary estimate. It is not exact, but it helps gauge whether the weekend window is realistic.

On faster alternatives: the provided guidance does not list a different Microsoft migration method that is guaranteed to be faster than SPMT for this NAS-to-SharePoint scenario. The supported optimization path in the available guidance is to improve source read speed, migration computer performance, connectivity, task design, and timing.

If the weekend window is strict, the safest plan is:

• run a full scan now,
• fix the scan issues,
• test with a representative subset,
• schedule the final migration for evening/weekend hours,
• use a high-bandwidth migration machine with minimal competing load,
• and split work into parallel tasks only where the destination design allows it.

• General migration performance guidance
• General migration performance guidance
• Migration time estimator tool in Migration Manager
• Improve migration performance when using SPMT or Migration Manager