Migrate from Fruux to Jira

Fruux tasks stored as CalDAV VTODO components map to Jira Issues. We extract UID, SUMMARY (maps to Summary), DUE (maps to Due Date), COMPLETED (maps to Status — completed VTODO becomes Done in Jira), DESCRIPTION (maps to Description), PRIORITY (maps to Priority), CATEGORIES (maps to Labels), and X-FRUXX-* extended properties. Each VTODO maps to a Jira Issue type chosen during scoping: Epic, Story, Task, or Bug. The parent VTODO UID becomes the Jira parent Issue link if the Fruux task had sub-tasks.

Fruux task lists are CalDAV collections containing VTODO components. Each distinct task list maps to a Jira Project with a dedicated Issue type scheme. We pre-create the Jira Project via the Jira API before importing Issues, set the default Issue type (Task, Story, or Bug per the customer's preference), and configure the initial workflow. If Fruux has multiple task lists, each becomes a separate Jira Project with its own default assignee pool.

Fruux calendar events stored as iCalendar VEVENT components do not have a direct Jira equivalent because Jira has no native calendar object. We decompose each VEVENT into a Jira Issue: SUMMARY maps to Issue Summary, DTSTART/DTEND map to Due Date and a custom time-range field, DESCRIPTION maps to Issue Description, LOCATION maps to a custom Location field, and ATTENDEE emails become Issue watchers. Recurring VEVENT RRULE values are decomposed into a Jira Issue per occurrence, with a Recurrence ID custom field to preserve the original rule reference.

Fruux iCalendar subscriptions (webcal/ICS URLs) have no direct Jira equivalent. We export the subscription URL and, if the customer requests, create a Jira Filter using a JQL query that matches the imported VEVENT-derived Issues by labels (e.g., label = 'calendar-import'). A Scrum or Kanban Board can be configured to display that Filter as its default query, giving the customer a calendar-view-equivalent board in Jira.

Fruux contacts stored as vCard (RFC 6350) records do not map directly to Jira native objects because Jira does not have a Contact object. We extract the FN, EMAIL, and TEL properties and match them against Jira User accounts by email during migration. Any Fruux contact without a matching Jira User is flagged in the reconciliation report for the customer's admin to provision manually. Fruux contacts are not migrated as Jira Accounts (which are CRM-style company records) unless the customer specifically requests Account creation from contact data.

Fruux supports multiple CardDAV address books per user. Each addressbook-home-set maps to a Jira Group that we pre-create via the Jira API. vCard FN and EMAIL properties from that address book are matched to Jira Users in the corresponding group. This preserves Fruux group semantics as Jira group memberships, enabling the customer to configure project-level permissions by group after migration.

Fruux supports hierarchical VTODO components where a parent VTODO has child VTODO entries. We map these to Jira Sub-Task Issues (Issue type = Sub-Task) with a Parent link to the Jira parent Issue. The Jira Sub-Task feature must be enabled in the target Project's Issue type scheme before migration; we handle this as a pre-migration configuration step.

Fruux Notes are proprietary objects with no CardDAV binding. We export accessible notes via web API scraping where technically feasible, but cannot guarantee full content or formatting fidelity. Long notes (exceeding Jira Description character limits) are split across multiple Jira Comments. Short notes become Issue Descriptions. Customers with heavy Notes usage should plan for manual recreation or a Confluence page as a Notes replacement.

Fruux task tags stored in VTODO CATEGORIES or X-FRUXX-tag properties migrate to Jira Labels as a flat list. Labels are created at migration time if they do not already exist in the destination Jira project. Jira Labels are project-scoped by default, so tags from multiple Fruux task lists may share label names across projects — we do not deduplicate cross-project label namespaces.

Fruux creates server-side copies when the same record is edited on multiple devices simultaneously. These appear as duplicate VTODO entries with identical UIDs but different content. We detect duplicates by comparing UID + SUMMARY + DUE fields, flag suspected duplicates in a reconciliation report before import, and suppress duplicates from the Jira import unless the customer explicitly chooses to import all copies. This prevents duplicate Jira Issues from Fruux sync artifacts.

Fruux Bookmarks are stored in a proprietary internal format with no CardDAV or CalDAV export path. We do not migrate Bookmarks as structured records because there is no interoperable protocol and no Jira equivalent native object. We deliver a plain-text list of extracted bookmark URLs with titles for the customer to recreate manually or import into Confluence as a links page.

Fruux does not expose an automation engine — sync rules are client-side configuration (sharing permissions, push settings) rather than server-side triggers. We do not migrate Fruux sync rules because they have no Jira equivalent. We deliver a written inventory of Fruux sharing configurations (task lists shared with which users, calendar access permissions) as a reference for the customer to recreate in Jira as project role memberships and Automation for Jira rules post-migration.