Liscaragh Migrate › Help › API throttling and bandwidth limits

API throttling and bandwidth limits

A migration moves data through Datto Workplace's API and Microsoft's Graph API, not directly down your internet line. Both providers limit how many requests they accept per second, on their side, regardless of how fast your connection is. This page explains what that means in plain language, then in full technical detail.

Why your internet connection is not the bottleneck

It helps to separate two different things that both get called "speed":

Bandwidth

How much data your internet connection can carry per second. This is what an ISP sells you, and it is entirely under your control: upgrade the line, and this number goes up.

Request rate

How many individual API calls (list a folder, start an upload, check a file) Datto or Microsoft will accept from you per second. This is entirely under the provider's control. It has nothing to do with your bandwidth, and no amount of bandwidth upgrades it.

A migration is made up of thousands or millions of small API calls, not one continuous stream of bytes. Each file transfer involves several: list it, request it, confirm it landed. Once the number of calls per second hits the provider's ceiling, extra bandwidth has nowhere useful to go, the connection simply sits idle between the calls it is allowed to make. This is exactly the same reason a motorway with more lanes does not help if the traffic lights at the end only let one car through per light.

Datto Workplace's limit

Datto publishes a general guide of roughly 2 requests per second for its API, and returns an HTTP 429 ("too many requests") response, with a Retry-After value, when a client exceeds whatever the real limit is for that account. Datto does not publish a firm, guaranteed number that applies to every account: the 429 and its Retry-After are the only concrete signal any client actually gets back.

Liscaragh Migrate does not hardcode a fixed delay based on the published figure. A hardcoded number would be wrong for almost every tenant: too slow for one that tolerates more, and still not slow enough to avoid throttling one that tolerates less. Instead, it learns the real limit for your account at run time:

• It starts reading at a reasonable pace and watches for a 429.
• Each time it gets one, it widens the gap between requests by 50% and treats that wider gap as a floor, not a one-off pause.
• After around 30 seconds without a 429, it cautiously probes about 5% faster, in case the account can sustain more.
• Over the course of a run this settles on a steady rate that fits your account's real tolerance, without you having to configure anything.

On one measured account this settled at roughly 3 reads per second (about 342 ms between requests). That is an example of the mechanism working, not a number you should plan around: every Datto Workplace account can settle at a different rate, and a fast result on one tenant says nothing about another.

Microsoft 365's limit

Microsoft Graph, which handles the SharePoint and OneDrive side, works differently. It does not publish a fixed requests-per-second figure at all: its throttling is dynamic, and depends on your tenant, the specific API being called, and what else is happening in that tenant at the time. Microsoft's own guidance is simply to expect throttling, to back off when told to, and to retry rather than treat it as a failure.

Liscaragh Migrate's uploads are built around exactly that expectation. When Microsoft signals that it wants the tool to slow down, it automatically reduces how many files it is uploading at once, then gradually increases again once the pressure has cleared. This is the Auto ease-off when throttled setting described in the Performance and tuning section of the main guide, and it is on by default. Turning it off is not recommended: it does not make Microsoft's limit go away, it just makes the tool ignore the signal to slow down, which tends to make a run slower overall by triggering repeated throttling instead of settling into a sustainable pace.

What this means when you are planning a migration

Three practical consequences follow from all of the above:

• A faster internet line will not shorten a migration once you are API-bound. If the run is already limited by Datto's or Microsoft's request rate, extra bandwidth sits unused. Where bandwidth genuinely helps is the initial stretch of a run, or a migration with unusually few, very large files, where the connection itself can still be the limit.
• Two projects running at once share one Datto account's limit, even across different Microsoft 365 tenants. The Parallel projects setting runs each project as a separate process with its own rate learner that cannot see the others. Two of them can together push roughly twice the request rate against a Datto account that only ever had one real limit, which is more likely to trigger throttling than to finish faster. Leave this at 1 unless you specifically understand and accept that risk.
• Timings from one account do not transfer to another. Because both Datto's and Microsoft's real limits vary by account and are learned at run time, how fast a previous migration ran is not a reliable estimate for the next one, even for a similarly sized job.

None of this needs manual tuning in the normal case. It is described here so that a slow-looking run reads as "the API is the limit, exactly as designed" rather than as something wrong with your connection or the tool. Planning around API limits, alongside your own bandwidth, is part of what the customer responsibilities the EULA sets out cover.