Editorial review: · Kalenderwoche.info

Switch calendars without losing track of events

A calendar move succeeds when the correct events appear in the right place and everyone knows which calendar is now authoritative. A count of imported entries does not prove that. A backup, separate trial import and explicit cutover let you find problems before changing the system you currently rely on.

Identify sources and ownership before exporting

List calendars containing your own events, calendars shared with you and subscribed calendars. An event you can see is not necessarily yours to transfer. Identify reminders, attachments, invitations and sharing settings that matter in daily use. An exchange format may not transfer every property.

Make an available backup and initially leave the original source unchanged. Record when the export was made and which period it covers. Export files can contain personal appointment details, so keep them out of public directories and share them only with the intended recipients.

Calendar migration starts with a backup, followed by a trial import, verification and a deliberate cutover.
Keep the backup. If checks are incomplete, resolve the cause before switching.

Distinguish importing, sharing and subscribing

Importing a file transfers a snapshot. Google explicitly notes that imported events do not stay synchronised between accounts. Sharing a calendar or using a supported subscription is a different arrangement; check how the destination actually receives later changes.

This website's ICS downloads are calendar files, not a promised live subscription service. Its CSV week table is not a universal calendar-import template either. Choose the transfer method for your task rather than treating a filename extension as evidence of automatic synchronisation.

Start with a separate trial calendar

Where the destination supports it, import into a dedicated trial calendar. This makes the test reversible without immediately mixing old and new entries. Include different cases deliberately: a normal timed appointment, an all-day event, a recurring series with a moved occurrence and an event with a time zone.

Compare dates, times, durations and recurrence with the original. Counting entries alone is insufficient: one product may represent a series as a series while another shows individual occurrences. Matching totals can still conceal shifted or incomplete appointments.

Investigate duplicate sources, not just similar titles

First check whether the same event is being displayed from multiple calendars. Two visible rows do not necessarily mean two stored copies. Before another import, record which file has already been imported into which destination calendar.

iCalendar defines UID as a persistent event identifier. That does not establish how every application will handle your repeated import. Test that behaviour separately rather than retrying blindly in your main calendar. Do not delete similarly named events until you understand their origin.

Agree a cutover and a way back

After the trial, decide when new changes will be made only in the destination. Tell everyone involved which source is authoritative. Reconcile changes made since the export in a controlled way instead of editing two independent calendars indefinitely.

Retain the old state for the agreed checking period. Inspect future recurrences and a year boundary before removing the original source. If important information is missing, pause editing in the destination and return deliberately to the source you have kept available.

  • Are sources, ownership and sharing documented?
  • Is a backup available and access appropriately restricted?
  • Have the trial, recurrence and time zones been checked?
  • Has repeated import and possible duplication been tested?
  • Have changes since the export been reconciled?
  • Are the authoritative calendar, cutover and recovery path agreed?

Sources and further documentation