Strategies for Optimizing Migration Performance

Updated October 28, 2025 15:57

It's important to note that increasing certain operational parameters within the service manager, such as the number of concurrent migration batches or threads, may require a thorough review and potential upgrade of your migration servers' underlying system specifications (including CPU, RAM, disk I/O, and network bandwidth) to prevent performance bottlenecks.

This guide provides strategic and technical advice for optimizing your migration project. While general performance factors are outlined in the article What Affects Migration Speed?, this document focuses on actionable strategies and settings you can implement to ensure a fast and efficient migration, especially for large-scale deployments.

Core Performance Factors (Quick Recap)

To set the stage, remember that migration speed is a combination of these key factors:

Network & Bandwidth: The most common bottleneck is upstream bandwidth.
Infrastructure: Your migration workstations' CPU, RAM, and disk speed are critical.
Data Characteristics: The sheer volume and number of items (e.g., emails, files, calendar entries) directly impact duration.
Destination System Limits: Throttling, rate limiting, and API quotas imposed by platforms like Google and Microsoft are the most common causes of slowdowns.

Operational Strategies for Concurrency

The most significant performance gains come from efficiently utilizing resources through concurrency. CloudM Migrate is designed to run multiple user migrations at once.

Understanding Concurrency

Concurrency refers to the number of migrations running simultaneously. Increasing this number is the most powerful way to boost migration speed.

CloudM Migrate Service Manager: This is where you configure the number of concurrent migrations. The default is typically 20 threads running concurrently.
System Requirements: It is crucial to note that increasing these operational parameters (e.g., more threads) requires a thorough review and potential upgrade of your migration servers' underlying system specifications to prevent bottlenecks.

How to Control Concurrency

You can manage concurrency through these key settings:

Simultaneous migrations per configuration limit: This setting allows you to cap the number of migration threads used per batch. This is a vital tool for distributing the migration workload more evenly across concurrent batches and secondary servers. You can find it in the UI under Configuration > Advanced Settings > System.
Multi-Farm Deployments: For very large migrations (typically involving 25,000+ users or 10 million+ objects), a single-farm deployment can become a bottleneck. A multi-farm strategy distributes the workload across multiple, independent environments to achieve significantly higher throughput.

Proactive Throttling Management

Throttling from a source or destination platform is the single most common cause of migration slowdowns. Per How Does CloudM Migrate Handle API Throttling and Quotas?, while our tool is built to handle throttling reactively, the most effective strategy is to take preventative steps to increase API throughput before you start your migration.

Microsoft 365: Proactively disable EWS throttling in the Microsoft 365 Admin Center for the duration of your project. This is a crucial step that can dramatically increase migration speeds.
Google Workspace: Google imposes daily API quotas to maintain service stability. While it is possible to request an increase directly to Google, these requests are not frequently granted. The most effective way to manage Google's API quotas is to stick to the recommended system specifications and environments outlined in our documentation. By doing so, you can rely on the tool's default settings to stay within the daily API limits for optimal performance.

For detailed instructions on how to handle throttling for a specific platform, please see the relevant articles in our Related Resources section.

Migration Running Order & Priority

Understanding the order in which users and data items are processed is crucial for predicting migration performance and completion times. This section outlines the default running order for users/items and the internal processing order for different data types within a batch.

User/Item Processing Order

The list of users or items to be migrated for a batch is processed in a specific, predictable order.

Default Order: Users/items are processed based on their Export Name field. This follows an alphanumeric sort:
- Numerals First: $0 \rightarrow 9$
- Letters Next: $A \rightarrow Z$
Priority Exception: You can override the default order by "prioritizing" (or starring) specific users/items in your Items to Migrate list.
- Prioritized items always start first.
- They maintain the same $0-9-A-Z$ sort order amongst themselves.
- All non-prioritized items will only begin once every prioritized item has completed.

Note: Use the prioritization feature sparingly for the best overall migration performance. Over-prioritizing can backlog other important migrations.

Data Type Migration Order

For each user or item, the selected data types are migrated in a specific parallel and sequential order to ensure dependencies are met and to maximize efficiency.

Parallel Migration (Starts First):
- Mail
- Drive/Files
Sequential Migration (Starts After Mail): Once Mail migration is complete, the remaining data types will begin in this sequence:
1. Contacts
2. Calendars
3. Tasks
4. Chats/Conversations

Detailed File (Drive) Migration Process

File migration is a multi-step, sequential process repeated in every run (full or delta).

Scanning Drive: A mandatory scan of the source and destination folder structures.
Processing Folders: Analyzing and preparing the folder structure.
Create Folders: The folder structure is built on the destination platform.
Migrate Files: Individual files begin migrating only after all folders are successfully created.

Important Note on Size Reporting: The size visible will only show the total size of file-only data that has been processed. You will see item counts only until the folder creation process (Step 3) is complete.

Batch and Configuration Options

These settings are available to both Self-Hosted and Hosted users and provide powerful ways to manage your migration flow.

Prioritize/Star Entities: This Items to Migrate feature allows you to prioritize specific users or entities. While entities typically migrate in alphanumeric order, prioritization ensures designated entities migrate first. This is useful for migrating key executives or small user groups to complete them rapidly.

Advanced Infrastructure (Self-Hosted)

For very large-scale self-hosted migrations, dedicated infrastructure can prevent bottlenecks.

Primary Service Virtual Memory
It's recommended to change the Virtual Memory setting on the Primary service (found via Advanced system settings > Advanced > Performance > Settings > Advanced > Virtual Memory > Change) to either:
- Choose System Managed size, and reboot, or;
- Change the Custom size to 2 times the available RAM of the server, and reboot.
Dedicated SQL & Redis Servers: A separate, dedicated PostgreSQL server and a Redis server may be required to prevent a single setup from becoming a bottleneck.

CloudM Migrate Hosted: Key Considerations

CloudM Migrate Hosted offers a fully managed, auto-scaled infrastructure. While CloudM provides and manages the underlying backend migration infrastructure (including core settings like Maximum User Migrations), the specific batch-level settings mentioned above are accessible to you directly within the CloudM Migrate application's user interface.

Backend Settings: You will not have direct access to the CloudM Migrate Service Manager. The default settings are:
- Maximum Complete Migrations: 2-4
- Maximum User Migrations: 20
In-App Settings: The batch-specific settings (Prioritize/Star Entities, Simultaneous migrations per configuration limit) are configured within the application's user interface when you create or edit a migration batch.

Related Resources