Why Faster Migrations Can Mean More Throttling, and What to Do About It

November 3, 2026

MigrationWiz is moving data faster than it ever has. Over the past several releases, BitTitan has rebuilt key parts of the back end to dramatically increase speed and throughput, and for most projects, that means shorter migration windows and fewer late nights.

There is one side effect worth understanding. Because MigrationWiz can now pull data so much faster, more projects are reaching the limits that source platforms like Microsoft 365 and Google Workspace place on how quickly data can be read. When that happens, the source slows the migration down. This is called throttling, and in this post we’ll explain what it is, why you may be seeing more of it, and how to plan around it.

What throttling is and where it comes from

Throttling is a deliberate slowdown applied by a cloud service when a client sends more requests, or moves more data, than the service allows in a given window. Instead of failing outright, the service tells the client to wait and try again later.

It’s important to be clear about where throttling happens in a migration:

• BitTitan does not throttle. MigrationWiz transfers data across the Microsoft Azure network, and BitTitan has no throttling policy of its own.
• Microsoft and Google do. Both Microsoft 365 and Google Workspace enforce throttling policies to protect the health of their services and keep performance fair for every tenant.

In practice, throttling almost always shows up at the source, the environment you are migrating data out of, because that’s where MigrationWiz is making the heaviest volume of read requests.

Why faster MigrationWiz means more throttling

Throttling isn’t new, but you’re likely to see it more often now, and that’s a sign of how much faster MigrationWiz has become.

Think of it like a highway on-ramp. When traffic trickles in, the metering light stays green. Once cars arrive faster than the highway can absorb them, the light starts cycling red. BitTitan’s back-end improvements mean MigrationWiz now arrives at the source’s on-ramp with far more traffic than before, so it reaches Microsoft’s and Google’s limits sooner and more often.

The bottom line: when you see throttling, it usually isn’t MigrationWiz slowing down. It’s the source platform asking MigrationWiz to wait because it’s moving data faster than the source allows.

Throttling in Microsoft 365

Microsoft throttles requests across Exchange Online, OneDrive, and SharePoint when an application exceeds its limits for a given time window. When that happens, the service returns an HTTP 429 (Too Many Requests) or 503 (Server Too Busy) response with a Retry-After value telling the application how long to wait before trying again (Microsoft Graph throttling guidance).

A few things about Microsoft’s approach are worth knowing:

• Limits apply at several levels. For OneDrive and SharePoint, Microsoft enforces limits per user, per application per tenant, and across the whole tenant. Example per-user limits include 3,000 requests per 5 minutes and 100 GB of egress (data read out) per hour (Avoid getting throttled or blocked in SharePoint Online).
• Tenant size matters. Per-app and tenant-wide allowances scale with the number of licenses, so smaller tenants hit their ceiling sooner.
• Time of day matters. Microsoft notes that throttling is more likely during business hours in the tenant’s region and less likely on nights and weekends.
• Ignoring it makes it worse. Throttled requests still count against usage, and persistent overuse can lead Microsoft to block an application temporarily.

Microsoft publishes these as default values and may change them, so treat any specific number as a guide rather than a guarantee.

Throttling in Google Workspace

Google applies its own limits to both Gmail and Google Drive, and they are enforced per user as well as per application.

The 750 GB daily cap is the one MigrationWiz users are most likely to notice. Google is the destination in many of these projects, but the same principle applies when Google is the source: once a user’s quota is consumed, Google pauses that user’s traffic, and the migration waits until the window resets.

How to recognize throttling in your migration

Throttling rarely looks like a hard failure. More often, it looks like a migration that is still running but moving more slowly than expected. Common signs include:

• Throughput that starts strong, then drops off sharply partway through a pass
• Items or files that retry several times before succeeding
• Error or log messages that reference “429,” “503,” “too many requests,” “server busy,” or “rate limit exceeded”
• Slowdowns that cluster during the source tenant’s business hours and ease overnight
• For Google Drive sources or destinations, a user’s transfer stalling after a large volume of data moved in a single day

Editor’s note: add the exact MigrationWiz status and error text users will see, plus a link to the relevant BitTitan Help Center article.

Best practices to plan around throttling

You can’t turn off a source platform’s throttling, but you can plan so it has far less impact on your timeline.

1. Build throttling into your schedule. Faster engines mean source limits become the pacing factor. Add buffer time to cutover plans, especially for large mailboxes and data-heavy OneDrive or Drive accounts.
2. Run heavy passes off-hours. Schedule large pre-stage passes for nights and weekends in the source tenant’s time zone, when Microsoft says throttling is less likely.
3. Pre-stage early. Move the bulk of historical data well before cutover so the final pass only needs to pick up recent changes.
4. Stagger large users. Rather than launching every large user at once, spread them across batches so no single user, app, or tenant limit is hit all at the same moment.
5. Plan around Google’s 750 GB daily cap. For users with more than 750 GB in Drive, expect the transfer to span multiple days and schedule accordingly.
6. Let retries do their work. When the source says “wait,” restarting or re-submitting items only adds more requests against the same limit. Give the migration time to resume.
7. Talk to the source administrator. Make sure other heavy workloads on the source tenant, such as backup tools or sync jobs, aren’t competing for the same limits during your migration window.

The bottom line

Seeing more throttling is a byproduct of a faster MigrationWiz. BitTitan doesn’t throttle your data, and the Azure network moving it doesn’t either. The limits come from Microsoft and Google, and they exist to keep those platforms healthy for everyone.

With a little planning, such as off-hours scheduling, early pre-staging, and staggered batches, you can take full advantage of MigrationWiz’s speed while staying within each source’s limits.

Have questions about throttling on a current project? Contact BitTitan Support or visit the BitTitan Help Center for more guidance.