Introduction

A mail migration can move mailboxes successfully while a CalDAV client still points to the old server for calendar sync. Users may assume the whole migration failed because calendar updates stop syncing, even though email already works on the new system and the remaining problem is a stale calendar endpoint inside the client profile.

Treat this as a saved calendar-endpoint problem instead of a full mail-platform outage. Start by checking the exact CalDAV server URL the client is using, because reused Apple Calendar, Thunderbird, or mobile DAV profiles often keep the previous hostname after the rest of the mailbox migration is complete.

Symptoms

  • A CalDAV client still points to the old server after mail migration
  • Email works on the new platform, but calendar sync still fails or uses the previous hostname
  • One newly added device syncs correctly while older devices still show stale calendar behavior
  • Certificate warnings, login prompts, or sync errors reference the old calendar server
  • Events added on one device do not appear in the migrated environment
  • The issue started after mailbox migration, domain change, or calendar service replacement

Common Causes

  • The CalDAV client still stores the old hostname or full calendar URL
  • The destination platform uses a different DAV discovery path than the previous provider
  • An imported or reused client profile preserved the old calendar endpoint
  • DNS for the previous CalDAV hostname still resolves to legacy infrastructure
  • Cached trust or login state is tied to the old calendar server identity
  • Migration validation focused on mail access while calendar sync settings were skipped

Step-by-Step Fix

  1. Open the failing calendar account and record the exact CalDAV server URL, hostname, and path it uses, because you need the live client target before changing server-side settings.
  2. Compare the saved CalDAV endpoint with the intended post-migration calendar URL, because many calendar clients keep the full previous DAV path even after the mailbox move is complete.
  3. Check whether the destination platform expects a different discovery path or account type, because the new service may not use the same DAV structure as the old provider.
  4. Verify DNS and certificate identity for the hostname the client is still using, because stale calendar hostnames often reveal themselves through old certificates or legacy server responses.
  5. Test a brand-new calendar profile against the intended destination endpoint, because that separates a stale client configuration from a wider server-side calendar problem.
  6. Recreate or fully update the saved CalDAV profile only after confirming the correct new URL, because partial edits can leave the old path or authentication state behind.
  7. Compare one fixed client with one older reused client if behavior differs, because migration leftovers often survive inside imported calendar profiles rather than in the server itself.
  8. Confirm new calendar events sync to the correct destination and no longer reference the old hostname, because the real fix is reliable bidirectional calendar sync on the migrated platform.
  9. Document the final CalDAV URL and any client setup instructions used after recovery, because calendar endpoints are easy to miss during future mail migrations.