Migrate from Fluid to Jira

Fluid Programs map to Jira Projects. We extract the Program name, description, status, owner, and dates and create a corresponding Jira Project with the same key structure. Jira Projects must have a valid project key (alphanumeric, 2-10 characters) that we derive from the Fluid Program name. Programs containing multiple Fluid Projects each create separate Jira Projects under the same Jira project key prefix if the customer opts for a consolidated structure.

Fluid Projects map to Jira Projects or Jira Project categories depending on the target structure. If the customer has multiple Fluid Projects that should share a Jira project key prefix and configuration, we consolidate them under a Jira Project category. Each Jira Project requires an issue type scheme (Standard, Bug Tracking, or Task Tracking) that we configure before migration.

Fluid Tasks map to Jira Issues. The Fluid Task name becomes the Jira Summary field (required). Fluid task status (Not Started, In Progress, Complete) maps to Jira Status using a configured mapping table. Priority maps from Fluid Priority to Jira Priority. Assignee resolves by email match against the Jira User table. Description, start date, due date, and custom fields transfer as-is. Jira issue type (Story vs Task) is configurable during scoping based on whether the customer treats the work as deliverable (Story) or action item (Task).

Fluid Subtasks map to Jira Issues with issue type Subtask. Jira Subtask has a dedicated Parent link field that we populate by resolving the Jira Issue ID created from the parent Fluid Task. We flatten nested subtask chains into a single-level Jira Subtask hierarchy by preserving the top-level parent relationship and documenting any deeper nesting in a custom field subtask_path__c. If the Subtask issue type is not enabled in the target Jira project, we fall back to a linked Issue approach with a 'Subtask of' link type.

Fluid assigns named users to Tasks and Subtasks. We extract the assignee identity (name and email) and resolve against the Jira User table by email match. Any Fluid assignee without a matching Jira User is held in a reconciliation queue for the customer's Jira admin to provision before record import proceeds. Jira's native user provisioning or Atlassian Admin API handles new user creation.

Fluid Custom Fields (text, number, date, picklist, boolean, multi-select) require a pre-migration schema review. We read each Fluid custom field type and create the corresponding Jira custom field (text field, number field, date picker, select, multi-select, checkbox) in the target Jira project before any record import. Jira custom field IDs (customfield_XXXXX) are assigned at creation and must be mapped in the transform layer before data insertion.

Fluid stores task start and end dates that drive the Gantt visualisation. We extract these as Jira Start date (Custom field: customfield_earlystart__c if the Jira project uses Jira Software with the date fields enabled) and Due date (native Due Date field). The Gantt layout itself is a UI construct and does not migrate; the underlying schedule data is preserved as date fields. Jira does not have a native Gantt chart in Jira Software base; we document this gap explicitly so the customer can evaluate Jira Advanced Roadmaps ($10.50/user/month on Premium) if Gantt visualisation is required.

Fluid effort metrics (estimated hours, actual hours consumed) map to Jira Worklog entries. We create Worklog records with the original author (resolved via user email match), the date the work was logged, and the duration in seconds calculated from the Fluid hours-consumed field. Jira time tracking must be enabled on the target project before migration; if it is not, we create a custom field effort_hours__c to hold the numeric value and flag the configuration gap during scoping.

Flex Statistics mode stores scenario-modelling and what-if planning data in a proprietary analytical format not exposed via any documented export endpoint. Jira has no native scenario-modelling equivalent. We document this gap explicitly in the migration scope before work begins and do not attempt to migrate Flex Statistics data. If scenario planning data is critical, the customer should retain their Fluid access or export the data manually before the migration cutover date.

Fluid computes workload distribution charts at runtime by aggregating task assignments and effort metrics per team member. These visualisations are not stored as discrete exportable records. We do not migrate workload distribution data. The underlying task assignments (Assignee fields) are preserved in Jira, allowing the customer's team to recreate workload views using Jira's native reporting or a third-party plugin.

Fluid Task descriptions (rich text) migrate to Jira Issue Description fields. Jira uses Atlassian Document Format (ADF) for rich text; plain text descriptions transfer directly. Formatted descriptions may require ADF conversion depending on the source format. We preserve inline images as attachments and update description references accordingly. Links within descriptions to other Fluid records are documented as a post-migration cleanup task.

Fluid task attachments (files attached directly to tasks) migrate to Jira Issue attachments via the Jira REST API attachments endpoint. Jira's CSV import does not support attachments, so we handle them separately through API-based insertion after the primary record migration is complete. Attachment metadata (filename, size, uploader, upload date) is preserved. Jira enforces file size limits per attachment (typically 10 MB on Cloud; configurable up to 256 MB on Data Center).