Preserving permissions during EXO migration

Hi,
Here is some more context about permissions and migrating to EXO

There are three core rules;

1. only explicit permissions migrate:
   On-premises mailboxes permissions such as Send AS, Full Access, Send on Behalf, and folder permissions that are explicitly applied on the mailbox are migrated to Exchange Online. Inherited (non-explicit) mailbox permissions and permissions granted to objects that aren't mail-enabled in exchange online are not migrated.
2. Full Access is supported cross-permises, Send As is not.
   Exchange hybrid deployments support the use of the full access and Send on Behalf permissions between mailboxes located in an on-premises Exchange organization and mailboxes located in Exchange online. Additional steps are required for Send As permissions.
3. Send As is never synchronized automatically. Entra ID Connect doesn't support automatically synchronize Send As permission between on-premises Exchange and Microsoft 365, so cross-premises Send As permissions aren't supported. Send AS must always be reapplied in Exchange online via Powershell after migration

Putting this together in the following scenarios:

Scenario 1 User mailbox and shared mailbox migrated in the same batch (Recommended)
This is the safest approach. You can preserve existing delegated rights if all mailboxes in the delegation relationship are migrated in the same migration batch.

• Full Acces => Preserved. Both objects land in Exchange Online together, eliminating any cros-premises dependency.
• Send AS => The permission entry migrates with the mailbox object, but mus be manually verified and re-added in Exchange Online via Add-RecipientPermission, since it is never synchronized.
• Auto-mapping => Auto-mapping will only work for individual users granted the proper permissions and will not work for any kind of group. Auto-mapping is also not preserved post-migration and must be reconfigured if needed.

Scenario 2 User mailbox first (Batch1), shared mailbox later (Batch 2) Risk on Send AS

• Full Access => Continues to function cross-premises during the interim period, as Microsoft supports Full Access between on-premises and Exchange Online in a properly configured hybrid. Once the shared mailbox moved in Batch 2, Full Access is preserved.
• Send As => Broken during the entire interim period. Cross-premises Send As is not supported. Once both mailboxes are in Exchange online, it must be manually re-added.
• Auto-mapping => Not functional Cross-premises

Scenario 3 is the same as Scenario 2, with the difference that shared mailboxes are Batch1 and user mailboxes are Batch 2

Scenario 4 Direct assignment vs Security groups 
This is a critical difference and the most misunderstood point.

Mailbox permissions such as Send As, Receive As, and Full Access that are explicitly applied on the mailbox are migrated to Exchange Online. Inherited (non-explicit) mailbox permissions and any permission on non-mailbox objects, such as distribution list or a mail-enabled user, are not migrated

In plain terms

Assignment method                       Full Access                    Send AS
--------------------------------------------------------------------------------------------
Direct (explicit) on mailbox             Migrated                       Must be re-added in EXO
--------------------------------------------------------------------------------------------

Via security group (inherited)         NOT Migrated               NOT Migrated

--------------------------------------------------------------------------------------------

users with mailboxes created directly in Microsoft 365 may still not be able to open a shared mailbox when access is granted ia a mail-enabled security group rather than directly on the mailbox.

Conclusion: security group-based permissions will not survive migration regardless od batch sequencing. They must either be converted to direct explicit assignment before migration, or fully re-applied in Exchange online after migration using PowerShell.

Practical recommendations:

1. Migrate user and shared mailbox in the same batch wherever possible, this is the only approach that avoids a Send As disruption window entirely.
2. Audit Send As permissions before migration and build a PowerShell scrip to re-apply them in Exchange Online post-migration.
3. Convert all security group-based permissions to direct explicit assignment before any migration batch run, otherwise they will silently disappear.
4. Ensure ACLablelSyncedObjectEnabled is correctly configured and that Microsoft Entra Connect is on the latest version to support cross-premises Full Access.

Last there are multiple suppliers that have tooling. which are able to preserve the permissions.

Hi,

Best practice is to migrate the user mailbox and shared mailbox in the same batch whenever possible.

If they are migrated in different batches, permissions such as Full Access may continue working, but Send As is more likely to have delays or require revalidation during coexistence.

Using security groups can work well, but adds sync timing and membership variables. Direct permissions are usually easier during migration.

My recommendation:

• Migrate dependent users + shared mailboxes together
• Export permissions before migration
• Validate Full Access / Send As after each batch

This gives the cleanest experience in hybrid environments.

Hope this helps.