Fixing Shared Mailbox Access Denied During Migration

The user mailboxes migrated fine. Then the batch hit the shared mailboxes and every single one failed with Access denied or The specified mailbox does not exist for this user. The migration account is a Global Admin, it has Full Access on every user mailbox, and yet the shared mailboxes refuse it. Three things cause this, all at once sometimes: missing Full Access on the shared mailbox itself, automapping interference, and the often-forgotten 50GB license rule on Microsoft 365.

Why shared mailboxes are a separate problem#

Exchange treats shared mailboxes as distinct objects with their own permission ACL. Granting your migration account Global Admin or even Exchange Admin gives it the right to manage shared mailboxes — to assign permissions, change quotas, modify settings. It does not give it the right to read or write the contents. That is a per-mailbox permission called Full Access (or equivalent on other platforms) and you have to grant it explicitly.

This catches people out because the same Global Admin can do anything they want via the admin UI, including managing the mailbox they cannot open. The IMAP layer enforces the mailbox-level ACL strictly.

Cause 1: missing Full Access on the shared mailbox#

The most common cause. The fix on Microsoft 365 sources or destinations:

Add-MailboxPermission -Identity "shared@example.com" `
  -User "migration@example.com" `
  -AccessRights FullAccess `
  -InheritanceType All `
  -AutoMapping $false

The same operation in the Exchange admin center: open the shared mailbox, mailbox delegation, add the migration account to Read and manage. The web UI does not let you disable automapping; if that matters (see next section), use PowerShell.

On a Gmail / Google Workspace source side, the equivalent is a Delegate setting in the user's account, granted by an admin via the Admin SDK or via the user's own settings if you have the password.

On self-hosted IMAP, the model varies. Dovecot uses ACLs via the acl plugin and the dsync tool with admin override. Cyrus uses cyradm with setaclmailbox. Plain IMAP servers without ACL plugins do not really have a shared mailbox concept — the "shared" mailbox is just a regular mailbox whose credentials are known to multiple humans.

Cause 2: automapping is interfering#

Automapping is the Exchange feature that automatically attaches any mailbox you have Full Access to in your Outlook profile. For a migration account, that is exactly what you do not want — your migration tool opens IMAP sessions against the shared mailbox directly, and the automapped Outlook profile can hold file locks or contend for connection slots.

Symptoms of automapping interference during migration:

• Intermittent Too many simultaneous connections against the shared mailbox.
• Slow open of the shared mailbox on the migration account's IMAP session.
• MailboxInTransition or similar transient errors that resolve on retry.

The fix: always grant Full Access with -AutoMapping $false. If you granted it without that flag, remove the permission and re-add it with automapping disabled.

Remove-MailboxPermission -Identity "shared@example.com" `
  -User "migration@example.com" `
  -AccessRights FullAccess `
  -Confirm:$false

Add-MailboxPermission -Identity "shared@example.com" `
  -User "migration@example.com" `
  -AccessRights FullAccess `
  -AutoMapping $false

You will lose access for the propagation window (a few minutes) but you avoid the long-tail flakiness automapping causes.

Cause 3: the shared mailbox exceeds 50GB on Microsoft 365 without a license#

Microsoft 365 lets shared mailboxes exist unlicensed up to 50GB. Above that, you need an Exchange Online Plan 2 license attached, or the mailbox is essentially read-only and your migration writes will fail. The error wording varies — quota exceeded, mailbox is full, or a generic access denied depending on which API path your migration tool uses.

To check:

Get-MailboxStatistics -Identity "shared@example.com" |
  Select-Object DisplayName, TotalItemSize

If TotalItemSize is anywhere close to 50GB and you are migrating into this shared mailbox, attach a license before continuing. If the size is well below 50GB, this is not your cause.

The same rule applies if In-Place Archive is enabled on the shared mailbox. Archived items count toward a separate quota and require Plan 2 regardless of primary mailbox size.

Cause 4: ApplicationImpersonation removed#

If your migration was working last month and is failing now on shared mailboxes, Microsoft's deprecation of the ApplicationImpersonation RBAC role may be your cause. Microsoft removed it from Exchange Online in early 2024–2025. Tools that relied on it to assume identity across mailboxes now need either per-mailbox Full Access (as above) or app-only auth via Microsoft Graph.

For an IMAP-based migration tool like Mailbox Taxi, this rarely applies — IMAP migrations use Full Access directly. For tools using EWS or older Microsoft Graph paths, the fix is to re-grant Full Access mailbox by mailbox.

A working order of operations for shared mailboxes#

1. List every shared mailbox in scope

   Get the full set from the source admin console before you start.

2. Grant Full Access on the source

   Add your migration account with AutoMapping disabled at the source for read access.

3. Grant Full Access on the destination

   Same operation on the destination side for write access.

4. Verify license on Microsoft 365 destinations

   Attach Exchange Online Plan 2 to any shared mailbox you expect to exceed 50GB.

5. Wait 10–15 minutes for permission propagation

   Hitting it sooner usually fails. Use the time to confirm other pre-flight items.

6. Run a single-mailbox test migration

   Pick one shared mailbox and migrate it before queuing the rest.

7. Queue the remaining shared mailboxes

   Run them in a batch separate from user mailboxes so the permission and licensing context is consistent.

8. Revoke permissions after completion

   Remove Full Access from the migration account post-migration.

For post-migration delegate access issues that often appear alongside shared mailbox problems, see the delegate access fix. Tenant-to-tenant moves have additional permission wrinkles — the tenant-to-tenant migration guide covers the cross-tenant identity model. The Exchange to Office 365 guide covers the broader migration path, and the Office 365 migration guide the larger landscape. For other access errors during migration, the email migration troubleshooting hub is the index.