Office 365 Shared Mailbox to Exchange Migration

Moving an Office 365 Shared mailbox to an on-premises Exchange Server can support a data-center consolidation, cloud exit, regulatory operating model, merger, divestiture, or application dependency. The decision should follow an environment assessment rather than a general assumption that one platform is always more secure, scalable, or economical.

• Infrastructure control: Operate mailbox storage, maintenance windows, backup, and server configuration within the organization’s Exchange environment.
• Application dependency: Place shared mailbox content closer to line-of-business systems that require an on-premises Exchange connection.
• Tenant consolidation or separation: Move departmental mail into the Exchange organization that will own the service after a merger, divestiture, or restructuring.
• Data-location requirements: Align mailbox hosting with an approved governance or contractual model after legal and compliance review.
• Shared inbox continuity: Recreate the required Shared mailbox address and delegated access for teams such as support, finance, or operations.

• Duplicate mailbox objects: An active mailbox in both Exchange Online and on-premises Exchange can produce inconsistent mail routing in a hybrid organization.
• Incorrect target mapping: Similar display names or aliases can result in content being copied to the wrong destination mailbox.
• Permission differences: Full Access, Send As, Send on Behalf, folder permissions, and automapping behavior must be documented and validated for the target design.
• Message-size and service limits: Large items can exceed the configured limits on the target Exchange Server.
• Throttling and network conditions: Microsoft service controls, Exchange configuration, bandwidth, and latency can affect migration duration.
• Premature cutover: Changing MX, Autodiscover, addresses, or subscriptions before validation can interrupt mailbox access or mail flow.

EdbMails provides a guided workflow for connecting to the source Office 365 tenant and target Exchange Server, loading mailboxes, reviewing mappings, transferring selected supported mailbox content, and checking migration reports.

The first run processes the selected source scope. When the same source, target, mappings, project context, and migration computer are retained, a subsequent pass can process supported items that were not migrated previously. Parallel mailbox processing can help organize larger projects, but completion time still depends on mailbox size, network conditions, source-service controls, and target Exchange configuration.

This workflow copies mailbox content into the mapped destination. It is not the same as a Microsoft hybrid remote move, directory-object conversion, or automatic transfer of every mailbox permission and infrastructure setting.

• Inventory the source Shared mailbox addresses, aliases, size, folder count, item count, permissions, holds, forwarding, rules, and business owners.
• Decide whether each source Shared mailbox will map to a Shared mailbox or another supported mailbox type on the target Exchange Server.
• Confirm the supported target Exchange version, server health, storage, accepted domains, certificates, virtual directories, and mail-flow connectors.
• Document Full Access, Send As, Send on Behalf, automapping, and any required folder-level permissions for post-migration configuration.
• Choose a pilot mailbox, migration batches, validation owners, maintenance window, and rollback or coexistence approach.
• Keep DNS and subscription changes outside the data-transfer phase until the target has passed acceptance testing.

Confirm that the source Shared mailboxes are visible to the selected Office 365 connection and that the account or registered application has the documented permissions. Prepare the target Exchange environment before loading production data.

• Source access: Complete the applicable automatic or manual application registration and verify that the intended Shared mailboxes can be loaded.
• Target server: Check the supported Exchange version, cumulative update, operating system, storage, certificates, internal and external URLs, accepted domains, and Send/Receive connectors.
• Destination objects: Create and mail-enable the required target mailboxes, or verify the available EdbMails automatic-creation workflow before relying on it.
• Access method: Configure the required target Exchange connection, impersonation rights where applicable, EWS settings, throttling policy, and message-size limits.
• Mapping: Verify the full SMTP address and mailbox type for every source-to-target pair rather than relying only on display names.
• Pilot: Migrate a representative mailbox and validate content, permissions, client access, and mail flow before processing the remaining batch.

1. Review the migration report: Investigate completed, warning, skipped, and failed items before accepting the mailbox.
2. Validate mailbox content: Compare representative folders and counts, then open selected messages, attachments, contacts, calendars, and other migrated supported items.
3. Configure and test permissions: Apply the approved Full Access, Send As, Send on Behalf, and required folder permissions on the target.
4. Test Exchange access: Confirm Outlook and Outlook on the web access, internal and external mail flow, replies from the Shared mailbox, Sent Items behavior, and Autodiscover.
5. Perform the approved cutover: Update MX, Autodiscover, accepted domains, aliases, or routing only when the target is ready and the migration plan requires those changes.
6. Retire the source carefully: Remove licenses, subscriptions, domains, or source objects only after business acceptance and after confirming that no users, applications, retention requirements, or routing dependencies remain.

• If a mailbox does not load, verify the selected connection type, application consent, account access, and source Shared mailbox visibility.
• If the target mailbox is missing, confirm that it is created and mail-enabled, or review the automatic mailbox-creation configuration.
• If mapping fails, compare the complete SMTP addresses and ensure that the intended target mailbox type is available.
• If items fail, review the report for target message-size limits, permissions, throttling, service availability, or unsupported conditions.
• If mail flows to the wrong location, check for duplicate mailbox objects, accepted-domain settings, connectors, MX records, and Autodiscover.

Correct the reported cause before rerunning the affected mailbox. Do not change a verified mapping merely to clear an error.