Migrate from ProjectFlow to Jira

ProjectFlow Projects map directly to Jira Projects. Each ProjectFlow project becomes a Jira project with its name, key (auto-generated from the first letters of the project name or customer-specified), description, lead (mapped via email to Jira User), and start/end dates preserved as project dates. Jira project type (Team-managed or Company-managed) is selected during scoping; Team-managed is the default for smaller migrations.

ProjectFlow Tasks map to Jira Issues (Story, Task, or Bug issue type selected during scoping based on the task's nature in ProjectFlow). The Jira issue is created with summary, description (rich text preserved), assignee (resolved by email match to Jira User), reporter, priority, status, due date, and original estimate fields mapped from the corresponding ProjectFlow task. Custom task fields from ProjectFlow are enumerated during discovery and recreated as Jira custom fields before migration.

ProjectFlow subtasks map to Jira subtasks under the parent Issue. Jira enforces a three-level hierarchy (Epic > Story/Task > Subtask). We validate subtask nesting depth during discovery and flatten any subtasks that exceed Jira's maximum depth by re-parenting them to the nearest supported ancestor. The re-parenting decision is documented and approved by the customer before migration begins.

ProjectFlow Milestones map to Jira Fix Versions with the milestone name, target release date, and description preserved. Fix Versions appear in the Versions panel of the Jira project and are used to filter and group issues by release. If a ProjectFlow milestone has no date, we create an Unreleased version in Jira and flag it for the admin to populate.

ProjectFlow documents linked to tasks migrate as Jira file attachments on the corresponding Issue. We extract the document metadata (filename, file type, size, upload date) from the CSV export and request that the customer provides the actual file references or storage paths so that FlitStack AI can upload them to Jira. DocumentFolders are preserved as a flat parent-child reference table and optionally mapped to a Confluence space if the customer has a Confluence instance.

ProjectFlow DocumentFolders establish a hierarchical structure for documents within a project. Jira does not have a native folder concept for issue attachments. We map the folder hierarchy to a documented folder path reference table and optionally recreate the structure in a Confluence space if the customer's scope includes Confluence migration. The mapping document notes which documents belong to which folder so the admin can organize them in Jira or Confluence post-migration.

ProjectFlow DailyReports (construction-industry-specific with author, date, and narrative) have no direct Jira equivalent. We map each DailyReport to a Jira Issue Comment on the relevant project task, with the comment body preserving the daily narrative. We create custom fields daily_report_author__c and daily_report_date__c on the Issue to carry the structured DailyReport metadata. Any construction-specific fields (weather conditions, labour counts, site notes) are flagged as unmapped and listed in the migration inventory for the admin to recreate as custom fields in Jira if needed.

ProjectFlow GanttChart data — task bars, start/end dates, and dependencies — is extracted from the CSV export and reconstructed in Jira as Issue start and due dates. Dependencies that do not have a Jira-native equivalent are stored in a custom field jira_dependencies__c as a text reference to the dependent issue key. Jira's Board and Timeline views then render the dependency chain visually without requiring a third-party Gantt app.

ProjectFlow Alerts and notification thresholds are platform-specific and do not have a direct Jira equivalent. We extract the alert configurations during discovery and map them to Jira Notification Schemes (for project-level notifications) and Jira Automation Rules (for conditional alert triggers). The alert inventory is delivered as a written document with each ProjectFlow alert described and its recommended Jira equivalent noted.

ProjectFlow ProjectShares control access for users and external parties at the project level. We map these to Jira Permission Schemes by extracting the list of ProjectFlow users with project-level access and recreating equivalent Jira project role memberships. Multicompany Enterprise structures require deduplication of the same person appearing under multiple company contexts before mapping to Jira's single-company permission model.

ProjectFlow Assignees are resolved by email match against Jira User accounts. In Enterprise-tier multicompany structures, the same person may appear under multiple company contexts, creating duplicate user records in ProjectFlow. We deduplicate these cross-company records during assignee mapping, preserving task history attribution to a single Jira User record per person. Any ProjectFlow assignee without a matching Jira User is held in a reconciliation queue for the customer's admin to provision before record import resumes.

ProjectFlow custom fields on Projects vary by tier and configuration. We enumerate all custom fields during discovery, classify them by data type (text, number, date, picklist, user reference), and pre-create matching Jira custom fields in the destination project before data migration begins. Jira's custom field type must match the source data type; fields that cannot be matched (such as ProjectFlow fields with complex nested structures) are flagged in the migration inventory.