Office 365 Group Mailbox to Shared Mailbox Migration
An Office 365 Group mailbox and a Shared mailbox support different collaboration models. A Group brings conversations together with connected Microsoft 365 services, while a Shared mailbox is designed for several users to monitor and respond from a common address in Outlook. Organizations commonly move Group mailbox content when a department needs delegated mailbox permissions, a shared inbox workflow, or a simpler destination for historical conversations.
This process is a mailbox-content migration, not an in-place conversion of the Microsoft 365 Group object. Create the destination Shared mailbox first, map it to the correct source Group mailbox, and verify the selected supported data after migration. Connected SharePoint files, Teams content, Planner plans, membership, and Group-level settings require separate assessment.
EdbMails Office 365 Migration Tool connects to the source and target with modern authentication, lets you review mailbox mappings, migrates selected supported mailbox items, and provides progress details and reports for validation.

Why migrate a Group mailbox to a Shared mailbox?
The change is useful when the destination needs to operate as a team-managed inbox rather than as a Microsoft 365 Group. Typical reasons include:
- Delegated mailbox access: Assign Full Access, Send As, or Send on Behalf permissions to the people responsible for the mailbox.
- Shared inbox workflows: Let support, sales, finance, or operations teams work from a common address in Outlook.
- Centralized message handling: Keep operational conversations in a mailbox that designated users can monitor and manage.
- Historical content retention: Move required supported mailbox content before retiring or repurposing the original Group.
- Organizational change: Place departmental mail in the correct target during a tenant consolidation, divestiture, or service redesign.
Choose the correct migration route
Define the required destination before changing the source. The mailbox migration handles mailbox content; it does not automatically redesign every service connected to a Microsoft 365 Group.
| Condition | Correct route | Why |
|---|---|---|
| The requirement is to retain Group mailbox messages and supported mailbox folders in a shared inbox | Migrate the selected Group mailbox content to a pre-created Shared mailbox | This page covers that mailbox-content scenario. |
| The Group also contains SharePoint documents, Teams conversations, Planner plans, or other connected services | Plan those workloads separately before retiring the Group | Connected workloads are not the same as Exchange mailbox content. |
| The destination Shared mailbox could exceed 50 GB or needs archive, hold, or advanced compliance features | Verify the applicable Microsoft 365 license and configuration before migration | Shared mailbox capacity and features depend on licensing and service configuration. |
| The same SMTP address must be reused at the destination | Plan address removal, assignment, and mail-flow cutover in the correct order | The same proxy address cannot remain assigned to conflicting objects. |
| Group membership, owners, or delegated access must be retained | Document and configure destination permissions separately | Mailbox data migration does not replace Group membership with Shared mailbox delegation. |
Prerequisites for Group mailbox to Shared mailbox migration
- Confirm that the source Microsoft 365 Group mailbox is accessible and identify the mailbox content that must be retained.
- For Auto Registration, use an appropriate administrator account with the required tenant access. For Manual Registration, complete the documented application registration and consent requirements.
- Create the destination Shared mailbox before mapping and assign the required Full Access, Send As, or Send on Behalf permissions according to the operating model.
- Verify the destination mailbox capacity and licensing requirements. A Shared mailbox without a separate license is normally limited to 50 GB; additional features or greater capacity can require a license.
- Record each source-to-target mapping and run a pilot with a representative Group mailbox before starting a larger batch.
Steps to migrate from Office 365 Group mailbox to Shared mailbox
Step 1: Download and set up the EdbMails application
- Download and install the EdbMails Office 365 migration tool on your computer.
- Once the installation is complete, login using your email address and password or click ‘Start Your Free Trial’ to proceed.
See the detailed system requirements for Office 365 Group Mailbox to Shared Mailbox Migration.
- Choose ‘Office 365 Migration’ from the main dashboard to continue.
- Select the ‘Office 365 to Office 365 Migration’ option.
- You can keep the default job name or select ‘New Job’ to create a custom one.
- Then, click ‘Next’ to move forward.
Step 2: Connect to the source Office 365 account
- Click ‘Add New Connection’ to set up a new source Office 365 connection, or choose an existing connection and select ‘Connect to Existing’ to continue.
- Select ‘Connect to Primary/Shared Mailboxes’ and click ‘Next’
- Select an authentication method and click ‘Login’ to proceed.
- Authenticate on Microsoft sign-in page.
- Once authentication is successful, select a method to load the mailboxes. EdbMails automatically loads 100 mailboxes into the interface. If you have more than that, you can load those mailboxes using a CSV file.
Step 3: Select source Office 365 Group mailboxes
- Choose the Group mailboxes you want to migrate to the target and click ‘Next’.
Step 4: Connect to Target Office 365 Tenant
- Click ‘Add New Connection’ to create a new connection with the target Office 365 account. To use an existing connection, select it from the list and click ‘Connect to Existing’.
- Choose Connect to Primary/Shared Mailboxes and then click ‘Next’ to proceed.
- Choose a secure OAuth 2.0-based modern authentication method to connect to the target server.
- Then, click ‘Login’ to continue.
- Sign in on the Microsoft login page.
- Select a method to load the mailboxes. If the target shared mailboxes do not appear when using the automatic loading option, you can manually import them by uploading a CSV file.
Step 5: Map source and target mailboxes
- Choose the mapping option that suits your requirements.
- EdbMails automatically maps mailboxes between the source and target servers. You can also manually map source Office 365 Group mailboxes to target Shared mailboxes if needed.
Step 6: Start Office 365 Group mailbox to Shared mailbox migration
- After verifying every source-to-target mapping, click ‘Start Migration’ to initiate the migration process.‘Start Migration’ to begin transferring the selected supported mailbox content.
- Monitor the job and click ‘View Logs’ to review the migration report for folder-level item counts, warnings, skipped items, and errors.
Post-migration validation and cutover tasks
- Review the migration report for completed, skipped, warning, and failed items. Resolve errors before accepting the result.
- Compare representative folders and item counts, then open selected messages, attachments, and calendar entries in the destination Shared mailbox.
- Assign and test Full Access, Send As, and Send on Behalf permissions for the users who will operate the Shared mailbox.
- Confirm the destination email addresses, aliases, reply behavior, Sent Items settings, and any required automatic replies.
- If the migration is part of a tenant or domain change, update mail routing and DNS only during the approved cutover window. A same-tenant mailbox-content migration does not normally require an MX-record change.
- Retain the source Group and migration reports until the business owner approves the destination mailbox.
Common migration challenges and practical responses
- Incorrect target mapping: Similar display names can lead to the wrong Shared mailbox being selected.
Response: Verify the complete source and destination addresses, record the mapping, and test a pilot before processing a batch.
- Target capacity or licensing mismatch: A destination can reach its service limit or require licensed features.
Response: Check the current mailbox size, expected growth, archive requirements, hold settings, and target license before migration.
- Connected Group workloads are overlooked: Documents, Teams data, plans, and membership are managed separately from mailbox content.
Response: Inventory every connected workload and create a retention or migration plan for each one before decommissioning the Group.
- Microsoft service throttling: Exchange Online can reduce request rates during sustained activity.
Response: Monitor progress and reports, avoid repeatedly restarting a healthy job, and schedule sufficient time for the service to process the migration.
- An interrupted or incomplete run: Connection, permission, or service conditions can leave items pending.
Response: Correct the reported cause and run a subsequent pass with the same source, target, mapping, project context, and migration computer.
How EdbMails supports this mailbox migration
- Modern authentication:
Connect to the Microsoft 365 environments using OAuth-based authentication and the permissions required for the selected connection method.
- Explicit mailbox mapping:
Review automatic matches or manually pair each source Group mailbox with the intended destination Shared mailbox before migration.
- Batch processing:
Load and select multiple source mailboxes, including CSV-assisted loading where required, and monitor them within the migration project.
- Pause and resume controls:
Use the documented pause and resume option when an operational window requires the job to be stopped and continued later.
- Subsequent migration passes:
After a first run, a later pass can process supported items not migrated previously when the same source, destination, mappings, project context, and computer are retained.
- Progress and reporting:
Use status information and migration logs to identify warnings, skipped items, or failures that need review.
Validate the destination Shared mailbox
Do not treat a completed status as the only acceptance check. Review the final report and confirm the destination with a representative sample.
- Confirm every Group mailbox was mapped to the intended Shared mailbox.
- Compare representative folder and item counts with the migration report.
- Open selected messages, attachments, and calendar items in the destination.
- Test Full Access, Send As, and Send on Behalf permissions with designated users.
- Check the Shared mailbox address, aliases, Sent Items behavior, and mail flow.
- Resolve warnings or failures and complete any required subsequent pass before retiring the source.
Frequently Asked Questions
Is migrating a Microsoft 365 Group mailbox the same as converting it to a Shared mailbox?
No. This workflow copies selected supported mailbox content into a Shared mailbox that has already been created. It does not convert the Microsoft 365 Group object or automatically transfer its connected services.
What data should be assessed before moving a Group mailbox to a Shared mailbox?
Assess the mailbox messages, folders, calendar data, and other supported mailbox items required at the destination. Review connected SharePoint files, Teams content, Planner plans, Group membership, owners, and settings separately.
Can I migrate several Office 365 Group mailboxes in one project?
Yes. You can load and select multiple source Group mailboxes and map each one to its intended destination Shared mailbox. Verify the mappings and complete a representative pilot before running a larger batch.
Does a target Shared mailbox require a Microsoft 365 license?
A Shared mailbox without a separate license is normally limited to 50 GB. A license can be required for greater capacity or features such as an archive, litigation hold, or certain compliance capabilities. Verify the current Microsoft requirements for the destination.
Can I rerun the migration after correcting an error?
Yes. Review the report, correct the connection, permission, mapping, or service issue, and rerun the affected mailbox. Keep the same source, destination, mapping, project context, and migration computer so the subsequent pass can process supported items not migrated previously.







