> For the complete documentation index, see [llms.txt](https://moverdocs.files.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://moverdocs.files.com/migration-behavior/performance-and-rate-limits.md).

# Performance and Rate Limits

Migration duration depends on the number of folders that must be listed, the number and size of files, network latency, both connections' performance, and limits imposed by the remote services. A migration containing many small files can take longer than a migration with the same total data in a few large files.

## Provider Rate Limiting

Every remote service can limit requests, but Box, Dropbox, Google Drive, and SharePoint are especially likely to throttle a migration with many files. Throttling can affect either direction because Mover uses the provider's API to list, inspect, download, and upload items. A rate-limited run can remain in progress for much longer than its data size alone suggests.

When a service returns a recognized rate-limit or connection-limit response, Mover reduces the number of simultaneous operations and retries the affected action after progressively longer delays. If the service continues rejecting the action after the automatic retries, Mover records the item as failed and the run can finish with a partial failure. Rerunning the migration retries files that are still missing or report a different size.

Google Drive lookups require complete folder listings because Drive permits duplicate filenames. Box performance also declines as folders grow. These migrations can take substantially longer than migrations between object-storage services such as Amazon S3, Azure Blob Storage, or Google Cloud Storage.

## Controls Available in Mover

Mover does not expose scheduling or concurrency controls for Box, Dropbox, Google Drive, or SharePoint. The *Max Connections* setting on FTP and SFTP connections applies only to those server types. The Files.com Agent's `transfer_rate_limit` setting is a customer-applied bandwidth cap and does not control a cloud provider's API limits.

To reduce the effect of provider throttling:

* Divide a large source into non-overlapping migrations by selecting narrower source paths or using include and exclude patterns. Run the batches one at a time.
* Avoid running several migrations against the same provider account or folders at once. Other applications using the account can consume the same provider quota.
* Run migrations when users and other integrations are making fewer changes to the source and destination.
* Use a dry run for each batch, then review and rerun failed items rather than recreating the entire project as a new migration.
* Check the provider account or license plan when throttling persists. Some providers assign different limits by account or plan without publishing an exact threshold in advance.

A dry run still makes listing and metadata requests and can itself be rate-limited. Apply the same batching and activity recommendations to slow dry runs.