Script Limitations to Migrating +400K Users from custom CIAM to Microsoft Entra External ID

Question

Script Limitations to Migrating +400K Users from custom CIAM to Microsoft Entra External ID

Jinki Lee 100

We are attemping to migrate our customer data from our custom CIAM to Microsoft Entra External ID. Our backend migration script (400K users) is hitting throttling limits. For example, 3,500 customers migrated in 3.5 minutes before the process paused and asked to wait 150 seconds.

Is it possible to increase this limit or optimize the script during migration testing and the actual migration?

Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-06-08T15:05:06.3633333+00:00
Hello Jinki Lee,

For a migration of 400K users, the throttling behavior you're seeing is expected. Microsoft Entra External ID and Microsoft Graph enforce service protection limits, and these limits generally cannot be increased on request. When throttling occurs, the service returns a 429 Too Many Requests response along with a Retry-After value that your migration process should honor before continuing.

To improve migration throughput and reduce throttling:

Implement retry logic with exponential backoff and respect the Retry-After header.

Limit the number of concurrent requests, as excessive parallelism can trigger throttling more quickly.

Process users in manageable batches instead of sending large bursts of requests.

Monitor throttling responses and adjust concurrency levels based on observed behavior during testing.

Minimize unnecessary Microsoft Graph calls during migration to reduce overall request volume.

For large-scale migrations, it is recommended to design the process with throttling in mind and validate performance using smaller pilot batches before running the full migration. This helps identify an optimal request rate while maintaining a stable and reliable migration process.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-06-09T12:53:23.4533333+00:00

Hello Jinki Lee,

Please confirm if you still have further queries on this

1 answer

Your answer

Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-06-08T15:05:06.3633333+00:00

Hello Jinki Lee,

For a migration of 400K users, the throttling behavior you're seeing is expected. Microsoft Entra External ID and Microsoft Graph enforce service protection limits, and these limits generally cannot be increased on request. When throttling occurs, the service returns a 429 Too Many Requests response along with a Retry-After value that your migration process should honor before continuing.

To improve migration throughput and reduce throttling:

Implement retry logic with exponential backoff and respect the Retry-After header.

Limit the number of concurrent requests, as excessive parallelism can trigger throttling more quickly.

Process users in manageable batches instead of sending large bursts of requests.

Monitor throttling responses and adjust concurrency levels based on observed behavior during testing.

Minimize unnecessary Microsoft Graph calls during migration to reduce overall request volume.

For large-scale migrations, it is recommended to design the process with throttling in mind and validate performance using smaller pilot batches before running the full migration. This helps identify an optimal request rate while maintaining a stable and reliable migration process.
Sridevi Machavarapu 33,820 Reputation points Microsoft External Staff Moderator

2026-06-09T12:53:23.4533333+00:00

Hello Jinki Lee,

Please confirm if you still have further queries on this

Answer 1

Microsoft Entra External ID and Microsoft Graph enforce throttling limits that can't be disabled, but migration can be optimized within those limits.

Key points from the documented limits and guidance:

Understand the limits
- External tenants have request limits such as:
  - Maximum requests per IP per external tenant: 20 per second
  - Maximum requests per external tenant: 200 per second
  - Maximum requests per external trial tenant: 20 per second
- Administrative CRUD operations (like bulk user creation) via Microsoft Graph are subject to Graph throttling limits and Graph throttling guidance.
- Total objects per tenant is 300,000 by default; to increase this, Microsoft Support must be contacted.
Optimize the migration script
- Follow the migration guidance for Stage 1: Migrate user data:
  - Read users from the legacy CIAM.
  - Create users in External ID via Microsoft Graph.
  - If plaintext passwords are unavailable, set random passwords and handle password migration later.
- For large one-time directory operations like your 400K-user migration:
  - Use Microsoft Graph batch operations to increase throughput.
  - Use up to six application registrations to perform Graph operations in parallel. This can increase throughput but also risks hitting tenant-level limits, so must be used carefully.
- When throttling occurs, follow the Graph throttling guidance (respect Retry-After, backoff, and pacing logic in the script).
Design for throttling and request limits
- Ensure the script:
  - Caps the per-second request rate to stay under the documented limits (per IP and per tenant).
  - Implements exponential backoff and honors Graph throttling responses.
  - Uses batching to reduce the number of HTTP calls (for example, multiple user creates per batch request).
- For very large migrations, consider splitting the migration into phases and running during off-peak times to reduce contention with other workloads.
When to contact Microsoft Support
- If the 300,000 object per tenant limit is a blocker, Microsoft Support can be contacted to request an increase.
- For Graph resource types with stricter throttling limits, Microsoft notes that mitigations can be planned case-by-case via a support ticket.

There is no supported way to turn off throttling, but by using Graph batch operations, multiple app registrations (up to six), proper backoff, and respecting the documented per-tenant and per-IP limits, the migration script can be optimized to move 400K users reliably.

References: