Migrate from Flow to Jira

Flow Projects map to Jira Projects. Each Flow Project becomes a Jira Project with the same name and description preserved. Jira Projects require a Project Key (prefix for Issues) that we derive from the Flow Project name, truncated to 2-10 uppercase alphanumeric characters. Projects are imported first so that child Tasks can reference the correct ProjectId during insertion.

Flow Tasks map to Jira Issues. The customer selects a default Issue Type during scoping (Story for product work, Task for operational work, or Bug for defect tracking). Jira Issue fields map as follows: Task title to Summary, Task description to Description, Task due date to Due Date, and Task assignee to Assignee. Flow custom fields become Jira custom fields pre-created in the destination project before import.

Flow Lists group Tasks within a Project. Jira has no native List equivalent, so we map Lists to Labels on the migrated Issues. The customer can alternatively choose to create Jira Components per List name and link Issues to Components. We confirm the preferred strategy during scoping and configure Labels or Components before import.

Flow Subtasks nest under parent Tasks. Jira natively supports Sub-Tasks via the Sub-Task Issue Type linked to a parent Issue. We preserve the parent-child hierarchy by creating Jira Sub-Tasks under their parent Issue, with the Sub-Task Issue Type configured in the destination project. If Jira Sub-Tasks are not enabled, we create linked Issue records with a 'is blocked by' or 'is child of' relationship.

Flow Comments attach to Tasks and migrate to Jira Issue Comments. We preserve comment body, author (by email lookup to Jira User), and timestamp. Flow's UI may return timestamps truncated to a date rather than an exact datetime; we document this limitation and preserve whatever precision Flow returns. Jira requires the parent Issue to exist before Comment insert, so we run Comments in a second pass after Issues are loaded.

Flow Members assigned to Tasks map to Jira Users by email address. We extract the assignee email from Flow workspace access and resolve it against the Jira destination User table. Unresolved assignees (no matching Jira User) are placed in a reconciliation queue for the customer's admin to provision before import resumes. Active and inactive Jira users are both supported for historical assignee mapping.

Flow Custom Fields on Tasks (key-value pairs) migrate to Jira Custom Fields. We infer field types from Flow values (text to Text Field, numeric to Number Field, date to Date Picker, true/false to Checkbox). Jira custom fields are pre-created via the Jira API before migration begins. Field names are preserved with Jira's naming conventions (alphanumeric, no special characters). Flow Custom Fields with no direct Jira type equivalent become Text Fields with the raw value stored.

Flow Tags on Tasks map to Jira Labels. Each unique Flow Tag becomes a Jira Label with the same text value. Labels on Jira can be applied across projects and are searchable via JQL. We map all Tags and do not limit label count during migration.

Flow Task due dates map cleanly to Jira Issue Due Date. Time zone context from Flow is preserved. If Flow stores time component on a due date, we map it to Jira's Due Date field (date only) and note any time precision loss in the post-migration report.

If Flow has time entry records associated with Tasks, we map them to Jira Worklog entries. Each Worklog links to the migrated Jira Issue and records the time spent amount, author (resolved by email to Jira User), and timestamp. Jira's Time Tracking must be enabled on the destination project before worklog import begins.

Flow Attachments require manual browser download by the customer before migration because Flow provides no bulk export API. We document the full list of Tasks with attachments and provide a step-by-step checklist for the customer to download files. Once downloaded, we upload attachments to Jira Issues via the Jira API, associating each file with the correct Issue ID. Jira Cloud attachment size limits (10 MB per file on Free, 50 MB on Standard+) apply.

Flow saved Views represent saved filtering and sorting states in the UI. They contain no persistent data that can be extracted via API. We document the View names, filter criteria, and sort order from Flow's active session and deliver them as a reference checklist for the customer's admin to recreate in Jira as Saved Filters or Board configurations post-migration.