Sharegate >
Glossary
>
Concurrent migrations

What are concurrent migrations?

Concurrent migrations mean running multiple migrations at the same time across different workstations to increase throughput on large or deadline-driven projects.

Also known as

Parallel migrations

Definition

By default, a migration runs sequentially—one task at a time, on one machine. That works for smaller environments.

For large migrations with tight deadlines, running concurrent migrations means more machines working in parallel, which increases the data throughput and accelerates migration.

Concurrent migrations segment workloads, which makes it easier to manage resources and maintain business continuity. The project finishes faster and if one migration stalls, the other keeps going.

tip

Start with one migration on a single machine. Add machines incrementally and watch what happens to performance. That's how you find your actual throttling threshold.

Why it matters

Running migrations in parallel can save weeks on large projects. Here's where the decisions actually matter.

  • Throughput: A single machine can only move so much data at once. Concurrent migrations split the workload across different workstations, so the overall project moves faster, especially when you're up against a tight deadline.
  • Throttling risk: Hit Microsoft's throttling limits and your migration stalls. Throttling is a security mechanism Microsoft uses to prevent your system from overloading. with the right planning, concurrent migrations help you work around it.
  • Optimization: A shorter migration means less downtime, faster time to value, and a project that stays on budget.

Commonly confused with: Uncoordinated migrations

Concurrent migrations run multiple tasks at the same time, but that doesn't mean without structure. Each machine needs its own clearly assigned workload. Wave planning and dependency management still apply.

ShareGate field notes:

What we see out there

Throttling is the first question on every large migration.

When multiple machines are pushing to the same tenant, the first concern is always throttling. And when you’re migrating a 20–30 TB SharePoint environment with a four-to-six week window, the concern isn’t just speed. It’s also finishing without hitting Microsoft's limits and stalling mid-project.

Frequently asked questions

How many migrations can run at once?

It depends on your environment, your hardware, and your Microsoft 365 tenant's throttling thresholds. Start with one machine, add more incrementally, and let performance tell you when you've hit the limit. Plan heavy waves for evenings and weekends when Microsoft's throttling limits are less restrictive.

What affects throughput?

Several things impact throughput: source disk performance, network speed between your migration machine and Azure, file size (larger files move faster than many small ones), and Microsoft throttling. The ShareGate help doc recommends starting at Normal performance settings and adjusting cautiously. Pushing too hard too fast is how you hit throttling.

How does Microsoft throttling work during a migration?

Throttling is Microsoft's way of saying “Whoa, you’re taking more than your fair share.” It’s a security mechanism Microsoft leverages to prevent your system from overloading. You’ll know you’re being throttled if you see error codes like 429 (Too Many Requests) or 503 (Service Unavailable), slowing down your migration.

Throttling can't be turned off or bypassed. The practical response is to schedule heavy migration waves during evenings or weekends, use distinct credentials per machine, and enable ShareGate's Insane Mode to leverage Microsoft's Migration API, which resists throttling considerably.

What should be validated after a concurrent migration?

Each machine's output should be checked independently. Confirm content was migrated completely and accurately, and that permissions match the intended state at the destination. Review migration reports for errors and warnings. ShareGate flags these clearly so you can run an incremental migration to fix what didn't work without starting over. Plan time for this. Concurrent migrations move faster but the validation work runs in parallel too.