Fixing Calendar Sync Issues Post-Migration

You finished the email migration cleanly, the user logged into the new mailbox, and the calendar is empty. Or it shows last year's events but nothing scheduled for next week. Or events are there but every meeting still lists the old domain as the organiser, so reply-tos bounce. None of this is unusual after an IMAP migration, because IMAP does not carry calendar data at all. The calendar needs its own migration path, and the most common problems are protocol mismatches and stale organiser fields. This post walks through diagnosing and fixing each case.

Calendar is empty on the new account
Meeting responses bouncing: <oldname@olddomain.com>: user unknown
CalDAV: 401 Unauthorized when adding account on iPhone
Exchange ActiveSync: account configured but no events syncing

Why this happens#

Three root causes explain almost every post-migration calendar problem.

IMAP does not move calendar data. IMAP is a mail-only protocol. Calendars live in CalDAV (Google, iCloud, Fastmail, most open-source providers), Exchange ActiveSync, or EWS / Microsoft Graph (Microsoft 365 and Exchange). An IMAP migration tool that promises "mailbox migration" usually means just the mail. If your migration plan did not include a CalDAV or Graph step, the calendar simply was not copied.

Calendar requires a separate authentication path. Even when the same provider hosts both mail and calendar, the calendar usually needs its own credentials and its own URL. Office 365 uses Microsoft Graph or EWS with OAuth2, Google uses CalDAV with OAuth2 scoped to calendar, iCloud uses CalDAV with an app-specific password. A migration that authenticated for IMAP does not automatically have permission to read the calendar, and a tool that does not request the calendar scope will not have a token for it.

Meeting organiser still points at the old domain. Each meeting carries an ORGANIZER field with the address that created it. When you export a calendar and re-import it on the new mailbox, the organiser remains the old address. The user is now sitting in the destination mailbox owning a calendar whose meetings claim to be organised by their old self. Updates and cancellations from the new mailbox are seen by attendees as coming from "someone else", which their clients flag as suspicious or refuse to apply.

Fix it now#

1. Confirm the calendar protocol on each side

   Identify the calendar protocol used by both source and destination. For Google Workspace and personal Gmail, calendar is CalDAV at https://apidata.googleusercontent.com/caldav/v2/. For Office 365, calendar is Microsoft Graph (/me/calendars) or EWS. For iCloud, CalDAV at https://caldav.icloud.com. For Fastmail, CalDAV at https://caldav.fastmail.com. Knowing which protocol applies on each side determines which export and import path to use.

2. Export the source calendar as ICS

   Most providers offer a "download calendar as ICS" option in the web settings. In Google Calendar it is Settings, Import and export, Export. In Office 365 it is Outlook Web, Calendar, Settings, Save calendar. In iCloud you right-click the calendar in the sidebar and choose Export. Save the ICS file locally. If the user has multiple calendars (Personal, Work, Holidays), export each one separately to make import cleaner.

3. Import the ICS into the destination

   Use the destination provider's Import Calendar option. Google Calendar and Office 365 both accept ICS files directly. For larger ICS files (more than a few MB), split by year if the import times out. Imports are idempotent on Message-ID-equivalent event UIDs, so re-running a partial import does not duplicate events.

4. Re-invite attendees for future meetings

   For every recurring meeting with occurrences after the cutover date, send a fresh invitation from the new organiser address. Cancel the imported copy and create a new one with the same date, time, attendees, and body. This is the only reliable way to make sure responses and updates flow to the new mailbox. The Office 365 migration guide covers the same step for tenant-to-tenant migrations where many users move at once.

5. Reconnect mobile calendar clients

   On every device, remove the old calendar account and add the new one. iOS in particular caches the CalDAV configuration aggressively, so the events will keep syncing from the old account until the account is fully removed. After re-adding, the destination calendar populates within a few minutes if the import already completed.

6. Validate shared calendars and delegations

   Shared calendars and delegate access do not survive a calendar export. On the destination, re-share each calendar with the same colleagues and reapply any delegate or full-access permissions. Office 365 delegations specifically need to be set in Outlook (not Outlook Web) for full functionality. The contacts missing fix covers the parallel problem for the address book.

How to prevent it next time#

Plan calendar migration as a separate workstream from email migration. Even if you use the same tool, treat them as two distinct jobs with their own scopes, their own credentials, and their own validation. The complete email migration guide includes a checklist that splits mail, calendar, and contacts into separate runs.

Set the cutover date in the calendar export tool's settings to match the email cutover. If mail moves on Friday but the calendar export was taken on Wednesday, two days of meetings booked on the old system will not exist on the new one.

For tenant-to-tenant Office 365 migrations, use the Microsoft Graph or EWS-based calendar migration path rather than ICS export. Graph preserves the organiser by rewriting it to the new tenant address, which is the single biggest cause of organiser-mismatch problems.

Keep the old mailbox in forward-only mode for at least 30 days after the calendar migration. Meeting responses from attendees who have not yet updated their copy will still arrive at the old address; forwarding ensures the new organiser sees them. The IMAP protocol glossary explains why this transitional period matters for mail too.