Migrate from Flowzone to Jira

Flowzone Jobs are the central record and map 1:1 to Jira Issues. We map Job title to Issue Summary, Job description to Issue Description, and the current workflow step of each Job to a Jira Status value that we configure in the target project's workflow scheme. Priority from Flowzone maps to Jira Priority (Highest, High, Medium, Low, Lowest). Custom column values migrate to Jira custom fields with type-alignment applied during field mapping: text columns become Short Text, numeric columns become Number, date columns become Date Picker.

Flowzone Lists are top-level organizational containers. We map each List to either a Jira Project (if the List represents a standalone work area) or an Epic within an existing Jira Project (if the List represents a feature grouping within a larger initiative). The decision is made during scoping based on the customer's current List count, team structure, and Jira architecture. Lists with fewer than 50 Jobs and no sub-Lists often collapse into Epics within a single Project; Lists with distinct team ownership or reporting requirements become separate Jira Projects.

Flowzone Columns are custom data fields on a Job. We export the column schema (field name, data type, required/optional flag) and map each to a corresponding Jira custom field. Standard column types align directly: text columns become Jira Short Text or Text Field, numeric columns become Number fields, date columns become Jira Date Picker. Select or multi-select columns become Jira Single Select or Multi-Select Picklists. We pre-create all custom fields in the target Jira project before migration begins, ensuring the field context is set to the correct issue types (Story, Task, Bug, Epic).

Flowzone documents attached to Jobs export as binary files with their filename, version, and approval status. We restore each document as a Jira Issue Attachment via the Jira Attachment REST API (multipart upload, max 10 MB per file via API). Documents with approval statuses store their approval state as a Jira custom field (Approved, Pending, Rejected) rather than a native Jira property, since Jira does not have built-in document approval workflows. Annotation threads are UI-stored data that may not export in portable format; we flag annotated documents during the export audit and note that annotation detail requires manual reference post-migration.

Flowzone workflows are step-based with branching, looping, and jumping logic. Jira workflows use status-driven transitions with conditions and post-functions. We do not migrate Flowzone workflows as code because the execution models differ structurally. We export the workflow definition (step names, branching conditions, looping rules, step-jumping logic) and the current step of each Job, then deliver a written workflow inventory document mapping each Flowzone workflow to the nearest Jira workflow equivalent with recommended Jira transition configurations, validators, and post-functions for the customer's admin to rebuild in Jira's workflow designer.

Flowzone Activities (time-planned events on Pro plan) map to Jira Issues or Subtasks depending on whether the Activity is a standalone deliverable or a time-block against an existing Job. We export the activity date, assignee, and description and create corresponding Jira Issues with the Activity description in the Issue Summary and the planned date in the Due Date or Start Date field. If Jira Premium is in use, activities may map to Jira Scheduling features.

Flowzone time records capture hours logged against Jobs. We export the amount, date, and assignee and map to Jira Worklog entries on the corresponding migrated Issue. This requires Jira Software Standard or Premium; Jira Free and Standard do not include worklogging. We flag this during scoping and confirm the customer's Jira tier includes time tracking before mapping time records. Budget-to-actual comparison data from Flowzone Pro (Budget vs Actual) migrates as Jira custom fields on the Issue rather than as native Jira features.

Flowzone user accounts include group-based permissions. We export the user list, their group membership, and permission levels and map to Jira Users matched by email address. Flowzone Groups map to Jira Project Roles (Developers, Viewers, Administrators) or to Jira Groups if the customer uses Jira Software Data Center or Cloud with Atlassian Access. Any Flowzone user without a matching Jira account goes to a reconciliation queue for the customer's admin to provision before record import resumes.

Flowzone Forms capture structured input linked to Jobs. We export the form schema and any submitted responses, noting the field-to-column routing. Jira does not have a native form object; we document the form fields as Jira custom field requirements on the relevant issue types and recommend Jira Service Management request types or Jira automation rules for form-style intake if the customer uses those features.

Flowzone custom dashboard panels (bar charts, pie charts) are UI-level visualizations not portable as data. We do not migrate panel definitions. The underlying Job data migrates through the standard object mapping, so the metrics are available for rebuilding Jira shared dashboards and filter-based gadgets post-migration. We flag which Flowzone panels are in active use during the discovery audit so the customer's admin knows which visualizations require recreation.