Office 365 Batch Migration

What Is Batch Migration in EdbMails?

A batch is a defined group of mailboxes that EdbMails migrates together as a single set, rather than moving every mailbox in the tenant as one undifferentiated block. Instead of starting one migration job that includes everyone, you decide how mailboxes are grouped, by department, by location, by priority, or by any other logic that fits how the organization is rolling out the migration, and each group runs as its own batch. Mailboxes can be added to a batch in two ways: selected directly from the list of available source mailboxes, or imported in bulk using a CSV file. The CSV method is useful for larger organizations where the list of users to migrate already exists in an HR system or directory export; it removes the need to search for and select each mailbox individually.

Once a batch is defined, it behaves as its own unit throughout the migration. It can be configured, filtered, mapped, scheduled, and reported on independently of every other batch, whether or not those other batches are running at the same time. This is what makes batching practical for large-scale migrations: rather than treating a thousand-mailbox migration as one enormous, hard-to-manage job, it becomes a series of smaller, trackable stages that can be planned, sequenced, and verified one at a time.

For details on preparing a mailbox list for batch import, see CSV-based mailbox import.

Why Use Batch Migration for Microsoft 365?

Large Microsoft 365 migrations are easier to manage when mailboxes are divided into smaller migration groups. Batch migration allows administrators to plan migration waves based on departments, locations, priorities, or organizational requirements.

• Phased migration planning: Organize mailboxes into planned migration groups based on departments, locations, priorities, or migration phases.
• Pilot migration support: Test migration with selected mailboxes before moving larger groups.
• Better migration control: Manage large Microsoft 365 mailbox migrations by dividing users into smaller, trackable batches.
• Flexible batch configuration: Apply separate mailbox mapping, filters, and migration settings for each batch.
• Batch-level reporting: Review migration results and reports for each completed batch.

With EdbMails, each batch can be configured, monitored, and validated independently throughout the migration process.

How to Run a Batch Migration

Running a batch migration in EdbMails follows a straightforward sequence, but each step carries choices that affect how the batch performs.

1. Build the batch: Select mailboxes directly from the source server, or import a mailbox list using a CSV file. At this stage, the batch is just a named group; nothing has been migrated yet.
2. Configure the batch: Apply filters if only certain data should be included, such as a date range or specific item types, and set up folder mapping if the migrated data needs to land in particular target folders. These settings apply only to this batch, so a second batch built afterwards can be configured completely differently.
3. Set mailbox mapping: Confirm how source mailboxes correspond to target mailboxes. EdbMails can handle this automatically for the batch, or it can be adjusted manually where a specific pairing is needed.
4. Start the batch: Once configured, the batch can be run immediately or scheduled to start later, which is useful for running large batches during off-peak hours to reduce impact on daily operations. If needed, a running batch can also be paused and resumed without losing progress.
5. Monitor and validate: As the batch runs, its report shows progress in real time: mailboxes completed, items transferred, and any items that need attention. Once the batch finishes, the report can be checked before moving on to the next one, which is particularly useful when a migration is split into several sequential batches.

This structure means a large migration doesn't have to be planned and executed as one continuous operation. Each batch can be built, tested, and confirmed working before the next one starts, which reduces risk on large projects where an error affecting the entire tenant at once would be costly to undo.

Running Multiple Batches at Once

Large Microsoft 365 migrations can be organized into multiple batches based on departments, locations, priorities, or migration phases. Each batch can have its own mailbox selection, filters, mapping settings, and migration reports. When organizations need to process different mailbox groups at the same time, EdbMails can be installed on multiple computers, allowing administrators to run separate migration jobs for different batches in parallel. This approach helps distribute large migration projects while maintaining control over each mailbox group and its migration progress.

Automate Large-Scale Office 365 Mailbox Migration

Automation matters most when the number of mailboxes gets large, and that's exactly where batching is used. Rather than manually creating each target mailbox and mapping it to its source one at a time, EdbMails applies automatic mailbox creation and mapping across every mailbox in a batch as soon as the batch is defined. This means adding a hundred mailboxes to a batch doesn't mean a hundred manual setup steps. The target accounts are created and matched to their source counterparts automatically, based on the mapping rules set for that batch, so the administrator's work stays the same whether the batch has five mailboxes or five thousand. Batches can also be scheduled to run during off-peak hours, letting large automated batches complete with minimal impact on daily operations. Learn more about the underlying features: Automatically create target mailboxes and Automatic mailbox mapping.

Office 365 Batch Migration for Organizations of All Sizes

EdbMails is capable of performing migrations of any size, starting with a few mailboxes to as large as thousands of mailboxes. Its flexible design accommodates any type of migration requirement. This flexibility ensures successful migration in any situation, regardless of the size of the project.

For migrations between Microsoft 365 tenants, see our Office 365 tenant to tenant migration guide.

EdbMails Office 365 Migration Software takes the complexity out of batch migration. Bulk and concurrent migration capabilities, combined with automated workflows and scalable solutions, work together to keep the process moving — so your Office 365 migration gets done without the usual back-and-forth and delays.

Re-Running a Batch Without Duplicating Data

Batches aren't one-time operations. If a batch needs to run again, for example, when new mailboxes are added to a department later, or when the first run was interrupted, EdbMails checks what was already migrated for that specific batch and transfers only the new or changed items. This means you can treat a batch as an ongoing group rather than a single pass: add mailboxes to it over time, re-run it on a schedule, and each run only picks up what's changed since the last one. For large organizations onboarding users in phases, this keeps every batch current without re-migrating data that's already there. The underlying mechanism is EdbMails' incremental migration engine; see Office 365 incremental migration for details on how it detects and transfers only new items.

Setting Filters and Folder Mapping Per Batch

Every batch in EdbMails can carry its own filter settings, independent of any other batch running at the same time. This means the finance department's batch can be scoped to a specific date range while the sales team's batch, running concurrently, pulls a completely different set of item types, calendars only, for example, without either configuration affecting the other. Filters can be applied by date, sender, recipient, subject, attachment presence, or message status, and combined with AND/OR logic to narrow a batch down to exactly the data it needs.

This is particularly useful when a batch is defined around a business reason rather than just a list of mailboxes: a compliance-driven migration might need only emails after a certain date, while a straightforward department move might need everything. Target folder mapping also applies at the batch level. Administrators can choose where each batch's data lands in the destination mailboxes, keeping migrated content organized according to the structure the receiving team expects, without having to configure that folder mapping mailbox by mailbox. For the complete list of available filter conditions, see Office 365 migration filter settings.

Advanced Filter Settings

With EdbMails Office 365 Migration is made precise by migrating only the essential data. Using Advanced Filter Settings to either include or exclude emails, calendars, contacts, and other items based on the date range, sender, recipient, subject, attachments, and message status. These Filter Settings help cut the migration time and optimize the space occupied, thereby reducing the useless data migration. The user can apply flexible AND/OR conditions as per need with EdbMails Office 365 Migration.

Tracking Progress Batch by Batch

When migrations are organized into batches, tracking progress at the batch level matters more than tracking it mailbox by mailbox. EdbMails generates a report scoped to each batch, showing how many mailboxes in that batch completed successfully, how many items were transferred, and which items or mailboxes need attention. This makes it possible to validate one batch before moving on to the next, which is especially useful in phased rollouts. If the first batch of fifty mailboxes completes cleanly, the report confirms it's safe to proceed with the next group; if a handful of items failed, the report identifies exactly which ones, so you can address them without re-running the entire batch. For organizations running several batches over time, this also creates a clear audit trail: each batch's report stands on its own, making it easy to look back and confirm exactly what was migrated and when. For a full breakdown of what each report includes, see Detailed Migration Reports.

Frequently Asked Questions

1. What is Office 365 batch migration?

   Office 365 batch migration is the process of migrating multiple mailboxes in predefined groups instead of moving all users in a single operation. Administrators can organize batches based on departments, locations, priorities, or migration phases.

2. Can different migration batches use different settings?

   Yes. Each batch can have its own mailbox selection, filters, folder mapping, mailbox mapping, and migration settings.

3. How many mailboxes can I include in a single batch?

   There's no fixed cap on how many mailboxes a batch can hold. Batches can range from a handful of mailboxes to several thousand, depending on how you choose to organize the migration. Most administrators size batches around a practical grouping, such as a department or location, rather than a technical limit.

4. Can I create more than one batch for the same migration project?

   Yes. A single migration project can be split into as many batches as needed. This is common when migrating a large tenant in phases, for example, running one batch per department or per office location, so each group can be configured, scheduled, and validated on its own.

5. Do all batches need to use the same settings?

   No. Each batch keeps its own filters, folder mapping, and mailbox mapping, independent of any other batch. This means one batch can be scoped to a specific date range while another batch, built separately, migrates everything with no filters applied.

6. Can I add mailboxes to a batch after it's already been created?

   Yes. A batch isn't locked once it's built. Mailboxes can be added to an existing batch later, and the next run of that batch will only pick up the new additions along with any changed items, without re-migrating what's already been transferred.

7. How do I know if a batch completed successfully?

   Each batch generates its own report showing how many mailboxes completed, how many items were transferred, and which items, if any, need attention. This report can be checked before starting the next batch in a phased migration.