Team Calendars

• 1: Team Calendars: What Is Migrated, What Is Not
• 2: Team Calendars: Updates and Manual Changes

"Features": {
    "SynchronizeTeamCalendars": true
}

1 - Team Calendars: What Is Migrated, What Is Not

The target of the calendar migration is a SharePoint list with a calendar view, one list per Confluence calendar. WikiTraccs does not create an Outlook calendar, a Microsoft 365 group calendar, or any other Exchange-based calendar. See the Team Calendars overview for how the migration works.

What is migrated

• Events with title, start and end time, location, description (as plain text), the first category, and a clickable link to the source event.
• Recurring events are expanded into separate list items, because SharePoint list items have no native recurrence. The expansion covers the range from the beginning of the current UTC month minus one year through the beginning of that month plus two years, with a maximum of 2,000 items per series. The original recurrence rule is kept as reference text.
• Cancelled events become list items with status CANCELLED.
• Organizer and attendee information, kept as text. On Confluence Data Center the calendar export provides names and Confluence identifiers. On Confluence Cloud the export typically contains only identifiers and no names; WikiTraccs does not look up the missing names, so expect organizer and attendee names to be missing there.
• Source information: calendar name, calendar and event identifiers.

What is not migrated

• No Outlook or Microsoft 365 group calendar is created, and there is no Outlook synchronization. The result is a SharePoint list with a calendar view.
• SharePoint’s Events web part cannot use these lists. A Team Calendar macro on a migrated page remains a non-functional placeholder; it is not automatically connected to the generated list.
• A multi-calendar overlay (several calendars shown in one view, like in Confluence) is not recreated.
• My Calendars, external or internal subscription calendars, and Jira-derived calendar events are not migrated. Only parent calendars owned by a selected Confluence space are migrated.
• Person fields: the SharePoint organizer and attendee person fields are not populated. Whatever the source provides is kept as text only.
• Calendar colors, custom event-type icons, reminders, and watcher or subscription settings are not migrated.
• Occurrences outside the recurrence window or beyond the 2,000 item cap are not migrated. A RANGE=THISANDFUTURE change is applied only to the explicitly changed occurrence; later occurrences continue to use the original series data.
• Permissions: the generated lists inherit the permissions of their target site.
• Events without a start date or UID are skipped.

Time zones

Event dates are stored and displayed using the time zone of the target SharePoint site (the site’s regional settings). The source calendar’s time zone is not preserved as separate metadata.

• Timed events are stored as UTC moments. SharePoint displays them converted to the site’s time zone.
• All-day events have no time, only a calendar day. WikiTraccs anchors that day to midnight in the site’s time zone at migration time. Without this anchoring, an all-day event could shift to the previous or next day, depending on where the migration runs.

Set the target site’s regional time zone before migrating calendars. Changing the site’s time zone after the migration can make already migrated all-day events appear on a neighboring day.

SharePoint field limits

Calendar values are stored in SharePoint list columns and are subject to SharePoint field length limits:

• Event titles, locations, categories, organizer metadata, source names and identifiers, and clickable event URLs use single-line text, choice, or URL fields. Those fields can store at most 255 characters.
• Longer content, including event descriptions, recurrence rules, attendee lists, raw event URLs, and calendar source links, is stored in multi-line text fields. SharePoint limits those to 63,999 characters.

Content beyond these limits cannot be stored completely in a list field.

2 - Team Calendars: Updates and Manual Changes

Synchronization is one-way

Changes flow from Confluence to SharePoint only. Nothing is written back to Confluence.

What happens on a repeated migration run

• WikiTraccs recognizes its calendar lists by a marker in the list description (wt-calendar-id:...). Renaming the list is safe; WikiTraccs finds it again. Do not remove the marker from the list description, otherwise WikiTraccs creates a new list on the next run.
• Events are matched by their source identifier. Changed source events update their list items, new source events are added.
• Events that were deleted in Confluence are removed from the list. Only WikiTraccs-managed items are removed; see below.
• When the source calendar has not changed since the last synchronization, WikiTraccs skips the list writes for that calendar.

Manual changes in SharePoint

• Do not edit WikiTraccs-managed rows while further migration runs are planned. A managed row (it carries a source UID value) is overwritten with the source values on the next synchronization of a changed calendar. When the source calendar is unchanged, the synchronization skips writes, so manual edits are not repaired either. While migration runs are still happening, treat the generated lists as read-only mirrors. Once the migration is finished, the list is a normal SharePoint list and all rows can be edited freely.
• Rows you add yourself are safe. Items without a source UID are never modified or deleted by WikiTraccs.

Deletions in Confluence

• Cancelled events remain in the list as rows with status CANCELLED.
• A calendar removed from Confluence is retained in SharePoint by default, including all its migrated events and its list. Removal of such lists can be enabled with the RemoveDeletedTeamCalendars feature flag in the configuration file.