Bypassing Microsoft 365 Graph API Throttling During Multi-Terabyte OneDrive Transfers

Moving multiple terabytes of OneDrive data through Microsoft Graph can become a throughput problem long before the network connection reaches its theoretical maximum. A migration engine may have sufficient CPU, memory, storage I/O, and bandwidth, yet still spend significant time waiting because Microsoft 365 is applying API throttling.

For large OneDrive transfers, the objective should not be to eliminate throttling completely. A more practical goal is to control request pressure, recover intelligently from 429 responses, maximize useful concurrency, and keep the transfer pipeline continuously productive.

Microsoft Graph documents throttling as a service-protection mechanism. A request that exceeds an applicable threshold can receive HTTP 429 Too Many Requests, with a Retry-After value indicating how long the client should wait before retrying. Microsoft also notes that throttling can occur even when an application has not obviously exceeded a published limit because service load and workload characteristics can affect behavior.

Why Multi-Terabyte OneDrive Transfers Hit Graph Throttling

A multi-terabyte migration is rarely a simple sequence of large file uploads. A migration engine normally performs many operations:

• Enumerating users and drives

• Discovering folders

• Listing children

• Reading metadata

• Creating destination folders

• Checking whether files already exist

• Creating upload sessions

• Uploading file fragments

• Updating metadata

• Retrying transient failures

• Recording migration status

• Validating transferred content

Consequently, a migration involving 5 TB of data can generate millions of individual operations even when the actual amount of user data is relatively modest.

The critical distinction is between data throughput and request throughput. Increasing concurrent workers can increase throughput initially, but beyond a certain point it simply creates more requests competing for the same service capacity.

Therefore, using a simple calculation such as:

130,000 requests / 10 seconds = 13,000 requests per second

as the expected OneDrive migration rate would be misleading. The global Graph limit is not a practical throughput target for a OneDrive migration.

Understand 429 Responses Before Increasing Concurrency

The first mistake in a throttled migration is often increasing the number of threads immediately after observing low throughput.

If 20 workers are producing 429 responses and we increase them to 50, the migration does not necessarily become faster. The additional workers may increase contention, create more failed requests, and produce a larger retry queue.

A typical throttling response should be treated as a control signal:

HTTP/1.1 429 Too Many Requests Retry-After: 15

The correct response is to respect the server-provided delay rather than immediately retrying.

Microsoft Graph guidance explicitly recommends waiting for the Retry-After value before retrying. If the request is throttled again, the client should continue following the recommended delay. When Retry-After is unavailable, Microsoft recommends an exponential backoff strategy.

A simplified retry algorithm looks like this:

send request if success: continue if HTTP 429: wait Retry-After retry if HTTP 5xx: exponential backoff retry if permanent error: record failure continue with next item

The important point is that retrying is not the same as resuming full-speed operation. A migration engine should dynamically reduce pressure when throttling appears.

Use Adaptive Concurrency Instead of a Fixed Thread Count

For multi-terabyte transfers, fixed concurrency is rarely optimal.

Suppose a migration starts with:

Concurrent workers = 16

If the transfer remains healthy, the engine can gradually increase concurrency:

16 → 20 → 24 → 28

If 429 responses begin increasing:

28 → 24 → 20 → 16

This creates an adaptive concurrency controller.

A useful strategy is to monitor:

• Requests per second

• Successful requests per second

• 429 rate

• Average Retry-After

• 5xx rate

• Average request latency

• Upload throughput

• Queue depth

• Bytes transferred per worker

The objective is not maximum thread count. The objective is maximum sustained successful throughput.

For example:

WorkersThroughput429 RateInterpretation8320 Mbps0.1%Under pressure threshold12510 Mbps0.4%Healthy16670 Mbps1.1%Good20690 Mbps5.8%Diminishing return24655 Mbps13.7%Excessive throttling

In this hypothetical benchmark, 20 workers look attractive if we only examine throughput. However, 16 workers may provide a better sustained operating point because the workload produces fewer retries and spends less time recovering.

Benchmark successful throughput, not raw request volume.

Batch OneDrive Transfers by Logical Work Units

Batching is one of the most effective ways to make a large migration manageable.

Instead of allowing every worker to select arbitrary files from the entire tenant, divide the migration into predictable units such as:

• User

• OneDrive

• Top-level folder

• File-size class

• Destination workload

• Migration phase

For example:

Batch 01: User 001–100 Batch 02: User 101–200 Batch 03: User 201–300

Within each batch, the migration engine can maintain a controlled number of workers.

This makes throttling easier to diagnose because request activity can be associated with a defined workload.

It also prevents a single extremely large OneDrive from monopolizing all available workers.

Do Not Treat Every File as the Same Workload

A directory containing 500,000 small files can generate substantially different request behavior from a directory containing a few hundred large files.

Consider two hypothetical datasets:

Dataset A

2 TB 500,000 files Average file size: ~4 MB

Dataset B

2 TB 20,000 files Average file size: ~100 MB

Although both contain approximately 2 TB, Dataset A may generate significantly more metadata and file operations.

This is why migration benchmarking should measure at least:

GB/hour files/hour requests/second 429 responses/hour average Retry-After

A single GB/hour measurement is insufficient for diagnosing Graph throttling.

Optimize Large Files With Upload Sessions

Large files should use Microsoft's resumable upload-session mechanism rather than attempting to transfer the entire file in one request.

Microsoft recommends resumable transfers for files larger than 10 MiB. For OneDrive upload sessions, Microsoft documents a recommended fragment size of 5–10 MiB, with 10 MiB described as optimal for stable, high-speed connections. Fragment sizes must be multiples of 320 KiB.

For example:

File size: 2 GB Chunk size: 10 MiB Approx. chunks: 205

The upload session also makes recovery more efficient because a failed connection does not necessarily require restarting the entire file.

Microsoft Graph exposes nextExpectedRanges, which can be used to determine which byte ranges still need to be uploaded.

A migration engine should therefore preserve upload-session state wherever practical.

Avoid Restarting Large Files After Transient Failures

One of the most expensive migration mistakes is restarting a multi-gigabyte file after a temporary network or service failure.

Microsoft recommends retrying interrupted uploads and transient 5xx responses such as:

500 Internal Server Error 502 Bad Gateway 503 Service Unavailable 504 Gateway Timeout

with an exponential backoff strategy. A 404 during resumable upload can indicate that the upload session no longer exists, in which case the upload needs to be restarted.

The migration architecture should therefore distinguish between:

Transient failure ↓ Resume/retry Expired upload session ↓ Create new session Permanent failure ↓ Record and continue

This distinction can dramatically reduce wasted bandwidth.

Calculate API Pressure From the Migration Pipeline

A practical migration benchmark should estimate request pressure before scaling workers.

Suppose one worker averages:

12 requests/second

With:

20 workers

the approximate request rate becomes:

12 × 20 = 240 requests/second

If each worker starts performing additional metadata checks, existence checks, and retries, the actual rate may become considerably higher.

For example:

Normal requests: 240/sec Metadata requests: 80/sec Retry requests: 30/sec Validation requests: 50/sec Total: 400/sec

The important number is therefore total API pressure, not merely the number of upload workers.

This calculation should be performed separately for:

• Read operations

• Write operations

• Metadata operations

• Upload-session creation

• Upload fragments

• Validation requests

• Retry requests

Use Logs to Identify the Actual Throttling Pattern

Migration logs should capture enough information to distinguish network limitations from Graph throttling.

A useful structured log entry might look like:

2026-09-08T10:22:14Z operation=upload_fragment user=user123 file=archive.pst bytes=10485760 status=429 retry_after=12 worker=17 duration_ms=841

Another successful request might appear as:

2026-09-08T10:22:27Z operation=upload_fragment user=user123 file=archive.pst bytes=10485760 status=201 worker=17 duration_ms=924

From these records, we can calculate:

429 rate = 429 responses / total requests × 100

and:

Successful throughput = successfully transferred bytes / elapsed time

If throughput remains flat while worker count increases, but 429 responses increase sharply, the migration has likely passed its useful concurrency point.

Do Not Retry Immediately

An immediate retry creates a particularly harmful pattern:

Request ↓ 429 ↓ Immediate retry ↓ 429 ↓ Immediate retry ↓ 429

The migration consumes additional request capacity without transferring additional data.

Instead:

Request ↓ 429 ↓ Read Retry-After ↓ Wait ↓ Retry

Microsoft explicitly recommends using the Retry-After value because it represents the service's suggested recovery delay.

If no Retry-After value is available, exponential backoff can be implemented, for example:

1 second 2 seconds 4 seconds 8 seconds 16 seconds 32 seconds

with an appropriate maximum delay and retry limit.

Separate Network Throttling From Microsoft 365 Throttling

A 500 Mbps transfer rate does not automatically indicate Microsoft Graph throttling.

Before changing concurrency, measure the complete path:

Source storage ↓ Migration server disk ↓ CPU / memory ↓ Internet connection ↓ Microsoft Graph ↓ OneDrive

If the network interface is already saturated, increasing Graph concurrency cannot improve throughput.

Similarly, if the migration server has high disk latency, additional Graph workers may simply create more local I/O contention.

Tune Bandwidth Without Creating API Pressure

Bandwidth controls and API concurrency controls solve different problems.

A bandwidth limiter controls:

MB/s

while a concurrency controller controls:

requests in flight

Both should be adjustable independently.

For example:

Maximum bandwidth: 700 Mbps Maximum workers: 16 Chunk size: 10 MiB

If the network is underused but 429 responses are increasing, increase bandwidth only after reducing request pressure or optimizing request behavior.

Conversely, if the API is healthy but the network is saturated, adding workers will not solve the problem.

Use a Ramp-Up Test Before the Full Migration

For a multi-terabyte transfer, avoid starting with the highest possible concurrency.

A controlled benchmark can use:

Phase 1: 4 workers Phase 2: 8 workers Phase 3: 12 workers Phase 4: 16 workers Phase 5: 20 workers

Run each phase long enough to obtain stable measurements.

Record:

Workers Files/hour GB/hour Requests/sec 429 % Average Retry-After 5xx % Network utilization CPU utilization

Then plot throughput against concurrency.

The optimal point normally appears where additional workers stop producing meaningful throughput improvements while throttling begins increasing.

A Practical Multi-Terabyte OneDrive Transfer Architecture

A robust migration pipeline can be structured as follows:

Migration Controller | +-------------+-------------+ | | | Batch A Batch B Batch C | | | Worker Pool Worker Pool Worker Pool | | | Graph Requests / Upload Sessions | Retry + Backoff Controller | OneDrive

The controller should maintain separate limits for:

1. Maximum concurrent users

2. Maximum concurrent files

3. Maximum requests in flight

4. Maximum bandwidth

5. Maximum retry attempts

6. Maximum per-user concurrency

This provides much better control than a single global thread-count setting.

When Throttling Continues Despite Backoff

Persistent throttling should not automatically be interpreted as a software defect.

Microsoft states that throttling can occur under service load and that limits can vary by service and request characteristics.

At this point, examine:

• Whether multiple migration processes use the same application identity

• Whether multiple workloads share the same tenant

• Whether the migration is concentrated on a small number of OneDrives

• Whether metadata calls are unnecessarily repeated

• Whether polling is too frequent

• Whether retries are counted as additional traffic

• Whether concurrency is globally or per-user controlled

• Whether the application is generating unnecessary list operations

Microsoft's Graph guidance also warns that continuously polling resources and repeatedly scanning collections can increase the likelihood of throttling.

Practical Optimization Checklist

Before launching a multi-terabyte OneDrive migration, verify the following:

• Use upload sessions for large files.

• Use 5–10 MiB fragments where appropriate for OneDrive upload sessions.

• Keep fragment sizes aligned to the required 320 KiB multiple.

• Implement Retry-After handling for HTTP 429.

• Use exponential backoff when an applicable Retry-After value is unavailable.

• Retry transient 5xx errors intelligently.

• Avoid immediate retries.

• Preserve resumable upload state.

• Batch users and files into manageable migration units.

• Start with conservative concurrency.

• Increase workers gradually.

• Reduce concurrency when throttling rises.

• Monitor successful throughput rather than raw request volume.

• Measure files/hour as well as GB/hour.

• Log HTTP status codes and retry delays.

• Separate bandwidth limits from API concurrency.

• Avoid unnecessary metadata calls.

• Avoid aggressive polling.

• Benchmark small-file and large-file workloads separately.

Professional Choice for Accurate Data Transfer

For organizations handling large-scale OneDrive migrations, Shoviv OneDrive Migration provides a practical approach to transferring data accurately while maintaining the original folder structure and essential metadata.

It supports batch migration, allowing administrators to process multiple OneDrive accounts efficiently rather than handling users individually. The software is designed to simplify complex transfers and reduce manual intervention during large data movements.

Its incremental migration capability can also help transfer newly added or modified data without repeatedly moving the entire dataset. By combining automation, controlled processing, and migration-focused features, Shoviv OneDrive Migration can be considered a professional choice for organizations planning reliable OneDrive data transfers.

Conclusion

Successfully transferring multiple terabytes from or to OneDrive through Microsoft Graph is less about finding a single maximum thread count and more about controlling the entire request pipeline.

The most reliable approach combines batching, adaptive concurrency, resumable upload sessions, intelligent retry handling, bandwidth management, and detailed telemetry. Microsoft Graph's 429 responses should be treated as feedback from the service rather than as failures to fight with increasingly aggressive retries.

The most useful benchmark is not the number of requests generated per second. It is the amount of data successfully transferred over time while maintaining a low and controlled throttling rate.

For a production migration, the ideal operating point is therefore:

High successful throughput + Low unnecessary API traffic + Controlled concurrency + Fast recovery from transient failures = Predictable multi-terabyte migration

By measuring these variables continuously and adapting the migration workload accordingly, large OneDrive transfers can remain productive even when Microsoft 365 applies throttling controls.

The final “always write this” text was not included in the prompt, so it could not be appended. The technical figures above are based on current Microsoft Graph documentation rather than invented benchmark claims.