Introduction

A shared mailbox that disappears from Outlook after migration is usually not a generic Autodiscover problem. In most cases, the mailbox exists, Exchange Online is healthy, and the real issue is one of three things: the mailbox is not actually in a clean shared state, the user lost direct Full Access permission, or Outlook is holding onto stale profile data from before the migration.

Treat this as a mailbox state, permission, and client cache problem. Do not start with DNS cutover checks if the mailbox migrated and other mailboxes are already working.

Symptoms

  • The shared mailbox exists in Microsoft 365, but it does not appear in Outlook
  • Some users can see the mailbox, but others cannot
  • The user can open the shared mailbox in Outlook on the web, but not in desktop Outlook
  • The mailbox was visible before migration and disappeared afterward
  • Manual add works inconsistently or shows an empty folder tree
  • Send As or Full Access works in some clients but not in the primary Outlook profile

Common Causes

  • The mailbox was not fully converted to a shared mailbox after migration
  • Full Access permission is missing, stale, or still assigned through a group
  • Automapping was lost during migration or permission rehydration
  • Outlook is using a stale profile, cached mailbox GUID, or old OST data
  • Hybrid remnants or old Exchange attributes are still attached to the object
  • The mailbox is oversized, disabled, or in an unexpected licensing state

Step-by-Step Fix

  1. Confirm the mailbox object is healthy in Exchange Online and make sure it still exists, is not soft-deleted, and is actually set as a shared mailbox, because Outlook behavior stays inconsistent if the object came across as the wrong mailbox type.
  2. Check that the affected user has direct Full Access permission to the mailbox, because group-based access can grant permissions but often does not auto-map the mailbox into Outlook the way direct assignment does.
  3. Remove and re-add Full Access if the permissions were migrated or recently changed, because reapplying the permission often rebuilds the mailbox mapping cleanly after migration.
  4. Test the mailbox in Outlook on the web with the “Open another mailbox” flow before touching the desktop client, because if it opens there, Exchange Online permissions are mostly correct and the remaining problem is usually client-side.
  5. Manually add the shared mailbox in classic Outlook if automapping still does not return, because waiting for auto-mount can waste time when migration-side metadata is delayed or never rebuilds correctly.
  6. Clear stale Outlook profile data by removing old saved credentials and testing with a fresh Outlook profile, because older profiles can keep pre-migration mailbox mappings and refuse to mount the new shared mailbox cleanly.
  7. Check for hybrid leftovers or conflicting Exchange attributes if the environment recently moved from on-premises Exchange, because stale remote mailbox data or conflicting addresses can break shared mailbox visibility without being a true Autodiscover failure.
  8. Validate mailbox size, conversion state, and licensing assumptions, because oversize shared mailboxes or incorrect conversion and licensing states can create inconsistent Outlook behavior even when permissions look correct.
  9. Document whether the mailbox opens in Outlook on the web, whether direct Full Access is present, whether manual add works, and whether a fresh profile fixes it, so escalation to Microsoft 365 support or the migration vendor starts with the real failure point instead of generic first-line checks.