Forum Discussion

tccables01's avatar
tccables01
Copper Contributor
May 01, 2026

Gmail to Microsoft 365 Migration Issue Open for 7+ Days – Seeking Guidance or Escalation Path

I’m facing an issue with a Gmail to Microsoft 365 migration that has been open for more than 7 days, and I’m looking for guidance or an escalation path from the community.

 

Scenario:

  • Migration type: Gmail to Microsoft 365
  • Issue started: April 22
  • Current status: Stuck with no clear resolution

 

What’s happening:

The support ticket has been active since April 22. However, the updates I’ve been receiving are generic responses such as “we are working on it” and “this has been prioritized.”

 

Despite multiple follow-ups, there has been:

 

  • No clear root cause identified
  • No ETA provided
  • No technical breakdown of the issue

 

I also requested a callback from the assigned manager and technical lead to better understand the situation, but the communication has remained email-only with repeated status updates.

 

What I’m looking for:

 

  • Has anyone faced similar issues during Gmail → Microsoft 365 migrations?
  • Are there known blockers or common causes that could lead to this kind of delay?
  • What is the recommended escalation path when support is unable to provide technical clarity or ETA?

 

Any insights, workarounds, or guidance would be highly appreciated.

 

Thank you in advance.

 

 

admin
exchange online
Exchange Server
office 365
outlook

1 Reply

  • radwanalmsora's avatar
    radwanalmsora
    Occasional Reader
    May 02, 2026

    Gmail Migration Endpoint – Time-Sync Deadlock / Stale Endpoint (SR# if available)

     

    Thanks for sharing the details and the screenshot. The error you're seeing is a well-known, classic MRS Proxy deadlock scenario with Gmail migrations. The future timestamp (4/23/2026 8:27:09 PM) is the giveaway. This is not a genuine "too many recent attempts" throttle — it's a symptom of one of two root causes:

     

    1. A corrupt migration endpoint object on the tenant side, where a failed Test-MigrationServerAvailability attempt has left a stale time-stamp that the UI cannot clear.

    2. A time-skew / clock-drift issue on the backend MRS instance handling the OAuth handshake with Google's IMAP/EWS endpoint, causing Google to reject the token as not-yet-valid.

     

    The support ticket being open for 7+ days with generic responses means it hasn't reached the right engineer yet.

     

    Here's exactly what you need to tell support to execute immediately (Exchange Online PowerShell, backend level):

     

     

    Step 1 – Force-Remove the Stale Endpoint

    The GUI/Admin Center can't touch this. They must run:

    Get-MigrationEndpoint | Where-Object {$_.EndpointType -eq 'Gmail'} | Remove-MigrationEndpoint -Force -Confirm:$false

    Step 2 – Verify Clean Removal

    Get-MigrationEndpoint | fl Identity, EndpointType, Status

    Make absolutely sure nothing with type Gmail remains before proceeding.

    Step 3 – Manually Create a Fresh Endpoint (Bypass the Wizard)

    New-MigrationEndpoint -Gmail -Name "GmailEP_Fresh" -EmailAddress "email address removed for privacy reasons" -NoBinding

    Step 4 – If It Still Fails

    Ask them to escalate immediately to the MRS (Mailbox Replication Service) Product Group, specifically to check for backend time-skew on the MRS instance handling your tenant, and to review the failed OAuth token request. They have internal tools to force a re-sync of the MRS proxy clock. This is not something you can fix from the client side.

     

    Escalation Path (If They Push Back)

    · Reference your SR number and state: "This is a proven MRS deadlock. I'm requesting immediate escalation to the MRS PG or FastTrack Escalation engineering team. The standard UI troubleshooting path will not resolve this."

     

    · If callback continues to be denied, open a new ticket directly via the Service Health Dashboard → Report an Issue, quote the original SR, and flag it as a service-impacting bug, not a user error.

     

    Hope this helps cut through the queue. I've seen this exact scenario with IMAP/Gmail endpoints more times than I can count – the forced endpoint removal and fresh creation via PowerShell solves it 90% of the time, and the remaining 10% is always backend clock drift. Let me know how it goes.