Fixing Missing Out-of-Office Replies After Migration

A user emails their team at 7am Monday from a beach in Crete. Two days later their manager calls: "Why has nobody heard from you?" The OOO they set on the source mailbox last week never made it to the destination. This is one of the quieter migration failures — nobody bounces, no error appears in the logs, mail flows normally. It just doesn't reply. If you've just cut over a tenant or finished a Gmail-to-Microsoft 365 move and the support queue is filling with "where's my auto-reply" tickets, here's the fix.

Why OOO never transfers automatically#

Out-of-office replies are server-side rules. Like inbox rules, they're stored in a vendor-specific format outside the IMAP message store, which means no IMAP-based tool can read or write them during a migration:

• Microsoft 365 and Exchange store OOO as MailboxAutoReplyConfiguration accessible through PowerShell, EWS, or Microsoft Graph.
• Gmail and Google Workspace store the vacation responder as users.settings.vacation in the Gmail API, with separate fields for subject, message, schedule, and audience.
• Zoho, Fastmail, iCloud, Yahoo each implement OOO as a per-mailbox setting on their own admin APIs or web UI.
• Custom IMAP / cPanel environments typically run Sieve scripts for vacation replies, which live in ~/.sieve on the server and are invisible to IMAP clients.

When a migration tool authenticates over IMAP, it sees nothing that lets it discover or transfer these settings. This is the same reason inbox rules don't survive — different store, different protocol, completely separate from mail.

The two-clock problem during cutover#

OOO failures cluster around the cutover window because of timing:

1. The user sets OOO on the source mailbox the night before they leave.
2. Cutover happens at midnight. MX records flip to the destination.
3. New mail arrives at the destination, where no OOO exists.
4. The user is on a plane and can't fix it.

If you're running dual-delivery for safety, you can hit the opposite problem: the source mailbox still has OOO enabled and is still receiving copies of mail, so senders get one auto-reply from the source and then nothing from the destination. Or, worse, both eventually reply and the sender gets two messages.

Step-by-step fix#

1. Pull the list of source mailboxes with active OOO

   On Exchange Online: Get-Mailbox -ResultSize Unlimited | Get-MailboxAutoReplyConfiguration | Where-Object AutoReplyState -ne 'Disabled'. On Gmail / Google Workspace, loop through users with the Admin SDK and call users.settings.vacation.get for each. Save the output as CSV — you'll need the message text, schedule, and audience scope.

2. Translate audience scope between providers

   Outlook's "anyone outside my organization" maps to Gmail's "do not respond to people not in my Contacts" — but the negation is reversed, so double-check your translation. Outlook's separate internal and external messages collapse into a single Gmail message; pick the external version if you have to choose, since that's the one strangers will see.

3. Reapply at the destination

   For Exchange Online, loop through your CSV with Set-MailboxAutoReplyConfiguration -Identity user@domain.com -AutoReplyState Scheduled -StartTime ... -EndTime ... -InternalMessage ... -ExternalMessage .... For Gmail destinations, users.settings.vacation.update takes a JSON body with the same fields.

4. Test from outside the org

   Send a message from a personal Gmail or a separate test account to one of the migrated mailboxes. Confirm the auto-reply arrives within a few minutes, contains the expected text, and is sent to the right audience. Repeat for a handful of mailboxes across departments.

5. Disable OOO on the source after the overlap window closes

   Once dual-delivery is off and source mail is fully retired, run Set-MailboxAutoReplyConfiguration -AutoReplyState Disabled (or equivalent) against the source to stop any stragglers from getting duplicate replies if someone re-enables source access for archival.

Common edge cases#

A few patterns where OOO recreation gets tricky:

• Scheduled OOO that's not active yet. A user sets OOO to start next Friday before cutover happens on Monday. The schedule field exists in both Outlook and Gmail, but the timezone semantics differ — Outlook stores UTC times converted from the user's mailbox timezone, Gmail stores epoch milliseconds. Convert carefully.
• OOO with HTML signatures. Outlook accepts HTML in the auto-reply body; Gmail's vacation responder accepts a subset. Test your migrated HTML by sending a test message before declaring the user done.
• Shared mailboxes with OOO. Shared mailboxes can have their own OOO on Exchange Online. Don't skip them in your audit, or the help desk shared mailbox will silently stop responding to support tickets.
• Resource mailboxes. Room and equipment mailboxes use a different auto-reply mechanism (Set-CalendarProcessing). They're not part of the standard mailbox OOO and have to be migrated separately if you customized the decline messages.

For the wider context of what else needs validation after a cutover, see the post-migration validation playbook and the email migration troubleshooting hub. If you're planning your overall migration approach, the complete email migration guide covers cutover sequencing in detail.

Bulk reset for MSPs#

If you run migrations for clients regularly, build a reusable script that pulls source OOO settings into CSV, lets a tech edit them, then applies them to the destination tenant. The translation layer between Exchange Online and Google Workspace is the only part that needs care; the rest is straightforward loops over the API. Once it exists, you can run it as the final step of every cutover and ship users to their new tenant with their OOO intact.