Cutover migration - unanswered questions RRS feed

  • Question

  • I'm about to complete a cutover migration and I'm experiencing a similar issue to my previous dozen or so cutover migrations: manual triggering an incremental sync does absolutely nothing. Forcing individual mailbox sync does nothing. It appears that we just have to wait for the 24-hour automatic sync to occur.

    I also have a point of contention with the oft-referenced Cutover Migration Guide:

    Step 4 instructs us to start the migration batch and run it until its status is Synced. That's fine, and usually done well in advanced. The guide should also state that incremental syncs are done automatically every 24 hours.

    OK, now it's time to actually cutover.

    Step 5 instructs us to change the MX record, and not to perform Step 6 for 72 hours. That's hardly realistic these days. Also, what about the fact that in the time between the sync being performed, and changing the MX record, messages will have been delivered to the original mail server? These messages need to be synced.

    What if I want to cut over this evening? I can just force an incremental sync by clicking the Resume button on the migration batch (or start via powershell). It looks like it's doing stuff, but when status is completed/synced again, I look at each mailbox and none of the "last successful sync dates" have updated. If I individually force a sync on the user mailbox, nothing happens.

    So - how do I actually force an incremental migration? 

    Just say I'm happy to wait for the daily incremental sync to take place, what are the requirements for the migration batch to still retain connection with the on-prem server? Can I change the autodiscover record (it's already been discovered, and the DNS record for the server will still be in place) so that end-users can connect to their mailboxes? Will the migration batch still be able to perform its incremental sync?

    This is all very important and basic information that shouldn't be skipped in the instructions. There seems to be no mention of these details online anywhere.

    Thursday, November 14, 2019 11:19 AM

All replies

  • Hi nayl3r,

    Incremental synchronization continues until the administrator stops or deletes the migration batch. If you want to stop incremental synchronization, you can use Stop-MigrationBatch command to stop the processing of a migration batch that's in progress. Then use Start-MigrationBatch command to start the processing again.

    After administrator has verified that routing has changed and cutover migration batch is deleted, they can assigns licenses to users and creates an Autodiscover Domain Name System (DNS) record.

    For details, you can read from this link


    Beverly Gao

    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact

    Friday, November 15, 2019 9:46 AM
  • If incremental sync is continuous, why were mailboxes reporting a last successful sync date of 2-3 days prior (ie: the last time I manually clicked the Start migration button? Despite being active mailboxes in a production environment?

    At my preferred cutover time, I clicked the Start button again to force a sync, but after 20-30 minutes of syncing, the process completed with no change to the last successful migration date on a majority of the mailboxes. However, 2-4 hours later, I checked again and found that the date and time had changed. 

    It certainly isn't a continuous "live" sync at all - it's periodic and you can't seem to manually force a sync - despite that being an option: "Force mailbox sync". 

    Monday, November 18, 2019 9:41 AM
  • Hi nayl3r,

    According to this article, on-premises mailboxes and the corresponding Office 365 mailboxes are synchronized every 24 hours during incremental synchronization. 

    Do you get any further questions? What's going on with your migration now?


    Beverly Gao

    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact

    Thursday, November 21, 2019 10:12 AM
  • Hi Beverly,

    That's what I found - it's not "continuous" at all - it's once per day. And despite there being a "Sync" button on the batch job, and a "Force sync" option on each mailbox, it appears to do nothing. Why bother having them there at all?

    And exactly what does a 24-hour sync period mean? Does the sync start at the same time each day, corresponding with the time of the first sync, or does the next sync start 24 hours after the last sync finished? We either have to plan the initial sync with a view to the final intended cutover time, or just get lucky.

    It so happens that my cutover completed, but I had to spend 6 hours overnight waiting for the final sync to take place instead of being able to force the final sync. Absolutely ridiculous.

    Thursday, November 21, 2019 10:33 AM
  • Hi nayl3r,

    It means once per 24 hours. The delta sync took place after the initial sync is completed since there is a chance some new messages have been delivered on-premises. Over the next 24 hours, this should get all caught up.


    Beverly Gao

    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact

    Sunday, November 24, 2019 7:34 AM
  • If you follow the Microsoft instructions here, you'll see the problem.

    Step 5 is routing email directly to Office 365, including waiting up to 72 hours for email systems to recognise the MX record change. It's not stated, but this step should also mention that incremental sync will take place every 24 hours so that mailboxes are indeed synced after changing the MX record.

    Step 6 is deleting the cutover migration batch.

    Step 7 is assigning licenses and completing post migration tasks.

    My issue is that if you follow these instructions, between step 5 and completion of post migration tasks, email users cannot access new messages. They will connect to their old stale mailbox, but be unable to connect to the new mailboxes because of a lack of autodiscover records. It's completely unrealistic that users can wait 24 - 72 hours while MX records and mail sync is complete.

    The instructions should be modified to clarify a realistic set of instructions that still actually work in practice. For example:

    Step 5: route email to Office 365, just prior to next expected incremental sync. Sync can't be forced, so best start your initial sync at a time of day when cutover is most appropriate / least disruptive to users.

    Step 6: assign licenses and change autodiscover records. Create O365 autodiscover record so users can access new mailboxes. Modify client access server if appropriate. Connect users to new mailboxes. Keep all other DNS records in place.

    Step 7: ensure final incremental sync has taken place, then delete migration batch. This order actually works - the sync connection will still function even though autodiscover records have been changed. This way, users can access new mailboxes while sync is still taking place. Very minimal disruption in service.

    Step 8: complete remaining post-migration tasks

    Don't you think this is much clearer? Microsoft should publish better instructions and/or fix the "force sync" functionality on migration batches.

    Monday, November 25, 2019 1:53 AM
  • Hi nayl3r,

    Thanks for your sharing. This will help users planning to do a cutover migration a lot.
    You can mark your reply as answer, this will make answer searching in the forum easier and be beneficial to other community members as well.


    Beverly Gao

    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact

    Thursday, November 28, 2019 9:12 AM
  • Whilst I'm stoked I could answer my own question, is there some kind process whereby feedback could filter back to the documentation team to update the cutover migration article with more accurate instructions? 
    Thursday, November 28, 2019 9:40 AM
  • Hi nayl3r,

    You can post your feedbacks according to this link


    Beverly Gao

    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact

    Tuesday, December 3, 2019 10:13 AM