Fixing Lost Delegate Access After Email Migration

The migration completed clean. Mailbox content checks out, folders match, sent items are intact. Then the executive assistant calls — she can no longer open her boss's calendar or send mail on his behalf. The boss's PA from another team has lost access to the shared project mailbox. Half the helpdesk tickets in the first 48 hours after a migration are about delegate access, and the cause is almost always the same: delegation permissions do not migrate, and nobody captured the map before cutover.

Why delegations are lost#

Delegate access is metadata about who can act for whom. Each provider stores this metadata in its own format:

• Exchange / Microsoft 365: stored in Active Directory / Entra ID and on the mailbox object. Three flavors: Send As (AD attribute), Send on Behalf (mailbox attribute), and Full Access (mailbox permission ACL).
• Gmail / Google Workspace: stored in the Gmail Settings API and exposed as the delegation list per user.
• IMAP standard: there is no delegation. IMAP itself has no concept of "user A may send as user B."

When you migrate mailbox content, you move messages, folders, flags, and labels. You do not move the delegation maps because:

1. The source's delegation format is not compatible with the destination's.
2. The destination identities the delegations refer to may not exist yet at the time the source data is read.
3. IMAP, the transport for most migrations, has no protocol-level concept of delegation.

The result: even a perfectly executed content migration leaves delegations behind. You have to re-grant them on the destination after the identities exist.

Capture the source map before cutover#

The single most important thing you can do is run a delegation export before migration starts. Once the source is decommissioned, that information is harder to recover.

For an Exchange / Microsoft 365 source, capture three things per mailbox:

# Full Access
Get-Mailbox -ResultSize Unlimited | ForEach-Object {
  Get-MailboxPermission -Identity $_.Identity |
    Where-Object { $_.User -notlike "NT AUTHORITY\*" -and $_.IsInherited -eq $false }
}

# Send As
Get-Mailbox -ResultSize Unlimited | ForEach-Object {
  Get-RecipientPermission -Identity $_.Identity |
    Where-Object { $_.Trustee -notlike "NT AUTHORITY\*" }
}

# Send on Behalf
Get-Mailbox -ResultSize Unlimited |
  Select-Object PrimarySmtpAddress, GrantSendOnBehalfTo

For a Gmail / Google Workspace source, the Admin SDK Users.delegates endpoint returns the per-user delegate list. Loop the user list, capture delegates, and store the result as a CSV alongside the mailbox migration manifest.

For Exchange folder-level permissions (calendar delegates being the most common case):

Get-Mailbox -ResultSize Unlimited | ForEach-Object {
  Get-MailboxFolderPermission -Identity "$($_.PrimarySmtpAddress):\Calendar" |
    Where-Object { $_.User.UserType.ToString() -ne "Default" }
}

Store all three maps as flat CSV. You will use them as the input to the re-grant script.

Mailbox-level vs folder-level delegation#

Two flavors of delegation behave differently and need re-granting differently:

• Mailbox-level: Full Access, Send As, Send on Behalf. Applies to the whole mailbox. On Microsoft 365 destinations, granted via Add-MailboxPermission, Add-RecipientPermission, and the GrantSendOnBehalfTo property.
• Folder-level: per-folder ACL, used heavily for calendar sharing and for "give me access to your Sent Items folder" scenarios. Granted via Add-MailboxFolderPermission with a role like Editor, Author, Reviewer.

Calendar delegation specifically is folder-level, not mailbox-level. The Add-MailboxPermission cmdlet does not affect calendar sharing. This is one of the most common post-migration surprises: an EA gets Full Access on the boss's mailbox and still cannot open the calendar with the same delegation behaviour, because Outlook's "calendar delegation" feature writes folder-level Editor with specific flags that pure Full Access does not replicate.

The fix for full calendar delegation behaviour on Microsoft 365:

Add-MailboxFolderPermission -Identity "boss@example.com:\Calendar" `
  -User "ea@example.com" `
  -AccessRights Editor `
  -SharingPermissionFlags Delegate

The SharingPermissionFlags Delegate is the part that makes Outlook treat the EA as a true delegate rather than just a calendar viewer.

Re-granting cleanly on the destination#

1. Confirm destination identities exist

   Every delegator and delegate in the source map needs a corresponding identity on the destination. If you renamed any accounts, build a mapping table before re-granting.

2. Apply Full Access first

   Full Access is the broadest permission and resolves the most user-facing pain (cannot open the mailbox at all). Grant it with AutoMapping disabled for migration accounts and AutoMapping enabled for end-user delegates who want the mailbox to appear in Outlook.

3. Apply Send As and Send on Behalf

   These are independent of Full Access. A user can have Full Access without Send As. Apply both based on the source map.

4. Apply folder-level permissions

   Calendar delegates need folder-level Editor with Delegate sharing flags. Apply per-folder using the source map.

5. Force a permissions sync

   On Microsoft 365, permissions usually apply within a few minutes but can take up to an hour. Communicate this window to users so they do not file a ticket at minute 5.

6. Verify with at least one delegate per mailbox

   Have a real human open the delegated mailbox, read a message, and send a test email. Calendar delegates should open the boss's calendar and create a test event.

When the destination is a different provider#

Cross-provider delegation re-granting is harder because the model differs. A few common patterns:

• Gmail to Microsoft 365: Gmail "delegates" are full-access readers and senders. They map cleanly to Microsoft 365 Full Access + Send As. Calendar sharing is independent — Google Calendar sharing settings do not move.
• Microsoft 365 to Google Workspace: Microsoft 365 Send As does not exist in Gmail. The closest equivalent is a delegate who can compose messages, which surfaces with a "sent on behalf of" line by default. Calendar delegates map similarly but with reduced fidelity.
• Tenant to tenant within Microsoft 365: this is the cleanest case because the model is identical. You still need to re-grant because the destination identities did not exist when the source delegations were created, but the cmdlets and semantics are the same.

The tenant-to-tenant migration guide covers the cross-tenant identity model in depth.

Related context#

Delegate access problems often appear alongside shared mailbox issues — the same migration that loses delegations frequently loses shared mailbox permissions too. The shared mailbox access fix walks through that one. For the broader Microsoft 365 migration path, the Office 365 migration guide covers it end to end, and the email migration troubleshooting hub is the index for every related error class.