#Migration Execution

Refer to the following sections to execute the migration.

#1. Configure projects and mappings in Fly

To configure projects and mappings, refer to Create a Project and Create Migration Mappings for details.

To migrate Recoverable Items folders, note the following:

• If you want to migrate only the data in SubstrateHolds, Versions, Purges, and DiscoveryHolds folders, configure the MigrateLegalHoldFolder customized feature in the migration policy. Refer to Customized Features for Exchange Online Migration for details.

• If you want to migrate Deletions folders, select the Recoverable Items folders option in the migration policy and make sure the MigrateLegalHoldFolder customized feature is not configured.

#2. Perform regular full migrations

Before running the job, we recommend you verify the mappings to ensure that the mappings are available for migration. Refer to Pre-analyze Mappings for details.

Then you can run a full migration job to migrate the objects based on your configured migration policy. Refer to Run Migrations to Migrate Objects for details.

#3. Perform regular incremental migrations

Handle new, updated, and failed data. Refer to Run Migrations to Migrate Objects about how to perform regular incremental migrations.

#4. Add X500 email addresses to the destination

In some cases following migration, end users may be unable to update events. When migrating auto-complete lists, there can be LegacyExchangeDN entries from source mailboxes. If end users directly use migrated auto-complete lists when sending emails, the emails may not be sent, and end users will get a non-delivery report (NDR).

The issues above can be resolved by adding the X500 email address to destination mailboxes. To add X500 email addresses to the destination, refer to User Guide for details.

#5. Validate migration results

Check the following:

• Mapping report. If the mapping fails or finishes with exceptions, you can check the error code and comment for the mapping in the Migration error section. You can click the error code to view the details and recommendations of the code in the Troubleshooting Guide, which can assist you in resolving or avoiding the error.

• Migrated data in the destination.

• Item count and permissions in the destination.

• Linkage between the organizer and the attendee.

• Linkage between users already migrated to the destination with users still in the source due to multiple-wave migration via forwarding setup at both sides.

• New data can be created in destination mailboxes.

• Functions can work normally, such as mail reply, forward, etc.

• Meeting/recurrence meeting functions work normally.

#6. (Cutover) Configure email forwarding for coexistence

Email forwarding is needed if there are additional waves to be migrated.

The email forwarding needs to be enabled in both source and destination:

• Set up two-way forwarding

  • For all source users migrated to destination, forward from source to destination.

  • For all source users to be migrated to destination, forward from destination to source.

    • At each wave, you need to alter forwarding for those users migrated over at this wave.

    • This forwarding can be set before the wave starts if needed.  

• Set up global contacts

  • Set up new email addresses in the destination for all users migrated over as global contacts in the source tenant.

    This is to allow calendar updates from the organizer who is already migrated to the destination tenant.

  • Set up all source users as global contacts in the destination tenant.

    This is to allow calendar updates from the organizer still in the source to attendees who are already migrated to the destination tenant.

#Forwarding Setup in Microsoft 365

By default, Microsoft 365 will block forwarding outside the organization. To make sure forwarding is working, modify the Outbound spam filter policy in Anti-spam settings and set automatic forwarding to On to allow users to automatically forward messages outside the organization. Refer to control automatic external email forwarding in Microsoft 365 for details.

To set email forwarding, you can select Email forwarding in Post-migration, or use the following PowerShell command:

Set-Mailbox -Identity user@contoso.com -DeliverToMailboxAndForward $false -ForwardingSMTPAddress "user@anothercontoso.com"

Refer to configure email forwarding for a mailbox for details.

#7. Hide/unhide users’ email addresses from the destination global address list

When the source mailboxes are still in use, and destination mailboxes are not put in use, you can hide users’ email addresses from the destination global address list to avoid destination users from viewing the newly added email addresses in the global address list. Refer to the step 6 in Prepare for Migrations for details. You can also unhide users’ email addresses from the global address list when the migration of source mailboxes is finished, and the destination mailboxes are ready for use. Refer to Unhide Users’ Email Addresses from the Destination Global Address List (GAL) for details.

#8. Perform the final incremental migrations for current wave

Ensure all source data are migrated to the destination.

#9. Perform migrations for all other waves

This step is only needed if you have separated the migration plans into multiple waves.

#10. Reduce DNS TTL

It is recommended to reduce the DNS time-to-live (TTL) to one hour or below to reduce the delay of emails sent from people outside of the organizations on cutover.

#11. Perform the final cutover

Remove all forwardings, modify Exchange MX records, etc. It can take up to 72 hours (related to the TTL mentioned in the previous section) for your email systems to recognize the changed MX records. After the cutover, the email addresses in project mappings will be changed. If you want to run a final incremental job to ensure updates of source data are migrated to the destination, you can use Change mapping domain in Fly to modify the email addresses in project mappings.

#12. Post migration

When all data has been migrated to the destination, you can run a post migration job to migrate shared calendar permissions to make sure the shared users can manage the migrated shared calendars in the destination. Refer to Post-migration for details.