Confluence Content Types

• 1: Team Calendars
• 1.1: Team Calendars: What Is Migrated, What Is Not
• 1.2: Team Calendars: Updates and Manual Changes
• 2: Confluence Databases
• 2.1: Confluence Databases: What Is Migrated, What Is Not
• 2.2: Confluence Databases: Updates and Manual Changes
• 3: Whiteboards
• 3.1: Whiteboards: What Is Migrated, What Is Not
• 3.2: Whiteboards: Configuration

1 - Team Calendars

Note: Team Calendars migration is available as of WikiTraccs v1.37.0

WikiTraccs can migrate Confluence Team Calendars to SharePoint.

What you get

For each calendar owned by a migrated space, WikiTraccs creates one SharePoint list with a calendar view on the target site of that space. Calendar events become list items. The list name ends with (Confluence Calendar).

Permissions are not migrated: the generated lists inherit the permissions of their target site, so configure list access separately.

How to enable

Check Synchronize team calendars to SharePoint lists in WikiTraccs.GUI: dialog Transformation Settings, tab Migration. The feature is off by default.

"Features": {
    "SynchronizeTeamCalendars": true
}

When it runs

Calendar synchronization runs once per space and migration run. It runs only for selectors that select a complete Confluence space by space key. CQL and content ID selectors do not trigger it.

Requirements

• Works with Confluence Cloud and Confluence Data Center (with the Team Calendars app). Confluence Server has not been tested; it is expected to behave like Data Center because Team Calendars is the same app there.
• Interactive Login is not required. Cloud API tokens and Data Center Personal Access Tokens work, subject to the source account’s calendar permissions. Anonymous access does not.
• A calendar must be discoverable and exportable as a complete iCalendar (VCALENDAR) document. An unavailable or malformed export causes that calendar to be skipped.

Calendar failures do not fail or stop page migration. Check the discovered and synchronized calendar counts and the migration log for partial results. The counts are stamped on the space’s row in the Confluence Space Inventory list, in the columns WT_In_CfCalendarCount (discovered) and WT_Out_CfSyncedCalendarCount (synchronized); a synchronized count below the discovered count reveals failing calendars.

Learn more

• What is migrated, what is not
• Updates and manual changes

1.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.

1.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.

2 - Confluence Databases

Note: Confluence Databases migration is available as of WikiTraccs v1.37.0

WikiTraccs can migrate Confluence Cloud databases to SharePoint.

What you get

Each Confluence database becomes its own SharePoint list on the target site. The list columns are generated from the database’s field definitions, so every list matches its database. The migrated database page stays in the page tree and embeds the list via the standard List web part, plus a link to the list.

Permissions are not migrated: the list inherits the permissions of its target site, so configure list access separately. The source page’s view and edit restrictions are only noted in the list description.

How to enable

Check Migrate databases to SharePoint lists in WikiTraccs.GUI: dialog Transformation Settings, tab Migration, group Gray Settings. The feature is off by default.

"Features": {
    "MigrateDatabases": true
}

Requirements

• Confluence Cloud only. Databases are a Confluence Cloud feature.
• Interactive Login is required. Database values are read from internal endpoints that need browser session cookies. API tokens and anonymous access do not work.

Database failures do not fail or stop page migration. A database that cannot be migrated keeps a note on its migrated page, and details are written to the migration log.

Learn more

• What is migrated, what is not
• Updates and manual changes

2.1 - Confluence Databases: What Is Migrated, What Is Not

Database migration is a best effort Gray Feature: database values are read from internal Confluence Cloud endpoints that are not documented as supported by Atlassian. A change on Atlassian’s side can make this feature stop working at any time. See the Confluence Databases overview for how the migration works.

What is migrated

• Fields become list columns. The columns are generated from the database’s field definitions. Every database has its own schema, so every generated list does too.
• All rows of the database, matched by their stable Confluence entry identifier.
• Person fields become two columns. The source data contains only Confluence account IDs, no names. A raw-text companion column always keeps those account IDs. In addition, account IDs that have an entry in the WikiTraccs user mapping list are written to a real SharePoint person column; for account IDs without a mapping the person cell stays empty. There is no name lookup against Confluence.
• Unknown or unsupported field types keep their raw values as text in a fallback column.
• Jira references and links are kept as text.
• A permissions note: the source page’s view and edit restrictions are not applied, but a human-readable note about them is added to the list description.

What is not migrated

• Permissions. The generated list inherits the permissions of its target site. Source restrictions are only noted in the list description; configure list access yourself.
• Database views, filters, and layout settings. The result is a plain SharePoint list. You can build your own SharePoint list views on it.
• Migration is best effort. Databases are read via internal Confluence Cloud endpoints. Content those endpoints do not deliver, or field types WikiTraccs does not know, end up as raw text rather than typed columns.

SharePoint field limits

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

• Short values use single-line text or choice fields, which can store at most 255 characters.
• Longer content, including database text, raw user values, Jira references, and fallback data for unknown field types, 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.2 - Confluence Databases: 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 database lists by a marker in the list description (wt-database-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.
• The list is reconciled with the source database: rows are matched by their Confluence entry identifier. Changed rows are updated, new rows are added.
• Rows that were deleted in Confluence are deleted from the list. Only WikiTraccs-managed items are deleted; see below. As a safety measure, deletions are skipped when the source data could not be read completely.
• New database fields add new list columns.
• Changes to the user mapping list are not picked up on their own. The person columns are written only when the database itself is migrated again. An update run skips a database that is unchanged in Confluence, so changing the WikiTraccs user mapping list alone does not refresh the person columns. The next migration that includes the database applies the then-current mapping to all rows.

Manual changes in SharePoint

• Do not edit WikiTraccs-managed rows while further migration runs are planned. A managed row (it carries a source entry identifier) is overwritten with the source values on the next migration of that database. While migration runs are still happening, treat the generated list as a read-only mirror. 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 entry identifier are never modified or deleted by WikiTraccs.
• Safety guard: WikiTraccs only writes to lists that carry both its description marker and at least one WikiTraccs column (internal name starting with WT_). Copying the marker into an unrelated list does not make WikiTraccs write to it.

3 - Whiteboards

WikiTraccs can migrate Confluence Cloud whiteboards to SharePoint. There are two independent modes that can be combined:

• Whiteboard as image: the whiteboard becomes a static image on the migrated SharePoint page.
• Whiteboard as draw.io file: the whiteboard content is converted to a draw.io diagram file and added as a page attachment. This conversion is experimental and best effort: expect converted diagrams to need manual rework, and expect the conversion to fail entirely for some whiteboards.

What you get

The whiteboard keeps its position in the page tree: it becomes a SharePoint page that shows the exported image. With the draw.io mode enabled, the page additionally gets a .drawio file attachment.

Requirements

• Confluence Cloud only. Whiteboards are a Confluence Cloud feature.
• Interactive Login is required for both modes. API tokens and anonymous access do not work.
• A locally installed Chrome or Edge browser. WikiTraccs drives it to open and export the whiteboard (see Adding Edge Browser Support).

Whiteboard export failures do not fail or stop page migration; check the migration log.

Learn more

• What is migrated, what is not
• Configuration

Blog posts with examples and background: Migrating Confluence Cloud Whiteboards, Migrating Whiteboards as draw.io, and Inside Confluence Whiteboards (technical deep dive).

3.1 - Whiteboards: What Is Migrated, What Is Not

The target of the whiteboard migration is a static image on a SharePoint page. There is no interactive whiteboard in SharePoint. See the Whiteboards overview for how the migration works.

What is migrated

• The current visual state of the whiteboard, exported as an image and placed on the migrated SharePoint page.
• The position in the page tree: the whiteboard becomes a SharePoint page like any other content.
• When the experimental draw.io mode is enabled, additionally a .drawio file as page attachment, converted from the whiteboard content on a best effort basis.

What is not migrated

• Interactivity. The image is static. There is no editing, no collaboration, no whiteboard experience in SharePoint.
• The optional draw.io attachment is an experimental, best effort conversion, not a copy: it is not editable inside SharePoint, elements without a draw.io equivalent are lost or wrong, and reworking it requires an external draw.io editor. Treat the image as the faithful representation.

For examples of what the results look like, see the blog posts Migrating Confluence Cloud Whiteboards and Migrating Whiteboards as draw.io.

3.2 - Whiteboards: Configuration

Both whiteboard modes are toggled in WikiTraccs.GUI: dialog Transformation Settings, tab Migration, group Gray Settings. Both are off by default and can be combined:

• Migrate whiteboards as image [Cloud]
• Migrate whiteboards to draw.io file [Cloud, best effort]

The Gray Settings page describes both settings and why they are gray.

Prerequisites

• Use Interactive Login for Confluence. Both modes need a signed-in browser session; API tokens and anonymous access do not work.
• Have Chrome or Edge installed on the migration machine. WikiTraccs uses Chrome by default (if available); the setting Use Edge instead of Chrome as remote controlled browser switches to Edge (see Adding Edge Browser Support).

Verifying results

Whiteboard export failures do not fail or stop page migration. To find affected whiteboards after a run, use the Site Pages library of the target site; migrated pages carry WikiTraccs metadata columns there (see Monitoring per page progress):

1. Filter the column WT_In_CfContentType by the value Whiteboard to list all migrated whiteboard pages.
2. Among those, look at the column WT_Out_CfFailedTransformationsCount: a value greater than zero means the image export failed for that whiteboard. Such a page shows no image.

The migration log contains the details for each failure.