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

john john Pter 1,590 Reputation points
2026-10-08T09:47:27.9566667+00:00

We have a NAS drive with 64 GB of data, and we are using the SharePoint Migrtion tool to migrate the files to sharepoint, but the job took 70++ hours, and still only 75% of the files got migrated as follow:-

User's image

so what is the reason ? and what other options we have to do the migration is a faster way ? as we are planning to do the live migration over the week end , so it can not take more than 72 hours !!

Thanks

Microsoft 365 and Office | SharePoint | For business | Windows
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Kristen Tran 2,285 Reputation points Independent Advisor
    2026-10-08T10:45:33.9366667+00:00

    Hi john,

    Thank you for sharing the migration details.

    Based on the screenshot, the migration has been running for over 70 hours and is currently 78% complete.

    While the total data size is only around 65 GB, the source contains more than 66,000 items, which can significantly impact migration performance, especially when many of the files are small.

    Additionally, the report shows 25,511 items with scan issues. Since these items appear to be excluded from the eligible migration count, they may not be migrated successfully unless the issues identified in the Scan Summary Report are resolved.

    I recommend reviewing the Scan Summary Report (via View Reports) to identify the affected items. Common causes include invalid file names, unsupported characters, excessive path lengths, blocked file types, or permission-related issues.

    For the planned weekend cutover, I recommend the following approach:

    • Review and resolve as many scan issues as possible before the cutover.
    • Complete the bulk migration ahead of the weekend.
    • Minimize changes to the NAS during the cutover period.
    • Run an incremental migration (delta sync) during the weekend to transfer only new or modified content.
    • Use a migration machine with adequate resources and a stable high-speed network connection.
    • If feasible, split the migration into multiple tasks to improve throughput.

    You may also consider using Migration Manager, which supports multiple migration agents and can help distribute the workload. However, changing tools alone may not significantly improve performance, as migration speed is still affected by source storage performance, network conditions, file composition, and SharePoint throttling.

    Although the current estimate shows approximately 16 hours remaining, this may change depending on source performance, retries, network conditions, and service-side processing. Given that the current test has already exceeded 70 hours, completing a full migration from scratch within a strict 72-hour maintenance window cannot be guaranteed.

    Therefore, the safest approach would be to pre-stage the majority of the content before the weekend and use the cutover window for the final incremental migration and validation.

    For additional guidance, please refer to:

    I hope this helps clarify the migration behavior and assists with your planning. If you have any questions or concerns, please let me know. I'll be happy to assist further.

    Was this answer helpful?

  2. AI answer

    2026-10-08T09:48:01.84+00:00

    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.
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.