Migrate from Project Insight to Jira

Project Insight Projects map directly to Jira Projects. We pull project name, description, status, start date, target end date, and manager from the project-level report. Jira Projects require a Project Key (usually a 2-10 character abbreviation) which we derive from the project name or customer-provided abbreviation. If the customer uses Project Insight's Program or Portfolio grouping, we map those to separate Jira Projects and create a project hierarchy or use Labels to group them.

Project Insight Tasks map to Jira Issues with type decisions made at migration time based on task attributes. Standard tasks become Jira Tasks. Tasks marked with a bug or defect indicator become Jira Bugs. Parent-child hierarchy from Project Insight's WBS exports as a flattened path; we reconstruct it in Jira using Jira Subtasks (where the parent Issue is created first and subtasks are linked under it) or by preserving the parent task ID as a custom field for manual reorganization. We carry the original task ID as a custom field (pi_task_id__c) for cross-reference.

High-level Tasks flagged as project milestones or summary items in Project Insight map to Jira Epics. We identify these by task level (top-level tasks in the WBS), by a custom field flag if present, or by the customer's guidance during scoping. Epics get a Jira Epic Name custom field populated for roadmap grouping. Child Tasks link to Epics via the Epic Link custom field (customfield_10006 by default) using the migrated Epic's issue key.

Project Insight Resources (people with name, role, and availability) map to Jira Users. We match by email address where available; if Project Insight Resources lack email, we match by name. Jira User provisioning is a prerequisite — we extract the resource list and hand it to the customer's Jira admin to provision accounts before migration. Availability and allocation percentage from Project Insight become Jira Project Role memberships and Capacity Planning data if the destination is Jira Premium with Portfolio.

Project Insight custom fields (Pro plan only) export within the same row as their parent Project or Task. We map each named custom field to a Jira custom field of the matching type: text fields to Text Field, numeric fields to Number Field, date fields to Date Picker, dropdown values to Select List. Jira generates customfield_ IDs on field creation, which differ between the source scoping environment and production — we update these IDs before the production import run. Custom field values are carried in the CSV row alongside the parent record data.

Project Insight time entries (hours, date, resource attribution, and task link) map to Jira Worklog records. We extract the time entry report, resolve the author to the Jira User, resolve the task to the Jira Issue key, and insert the worklog with the original date and duration. Jira requires the Worklog author to have the Log Work permission on the project. If Project Insight tracks billable vs non-billable time, we carry that distinction in a custom field or Jira label on the worklog.

Project Insight constraint types (ASAP, Finish No Earlier Than, Finish No Later Than, Start No Earlier Than, Start No Later Than) export as text fields. Jira does not have a native constraint type object. We carry the constraint value as a Jira Label (pi_constraint_type__c) or as a Select List custom field on the Issue. We flag which issues have non-default constraints in a pre-migration report so the customer's project scheduler can review and reapply them in Jira's date and dependency model.

Project Insight Portfolios and Programs group multiple Projects. Jira does not have a native Portfolio object above Projects, but Jira Premium's Portfolio for Jira (formerly Advanced Roadmaps) supports Initiative and Epic hierarchies. We map Portfolio groupings to Jira Labels for filtering, or we provision a separate Jira Project per Program if the customer needs clean project separation. The approach is chosen during scoping based on reporting needs.

Project Insight predecessor relationships (task-to-task dependencies with type: Finish-to-Start, Start-to-Start, etc.) export via the dependency report. We translate these into Jira Issue Links: Finish-to-Start maps to Blocks; Start-to-Start and Finish-to-Finish map to custom link types that the customer's Jira admin configures before migration. Jira does not natively support Start-to-Start or Finish-to-Finish constraint types, so these are noted and the admin either accepts a simplified model or uses a third-party app like Structure for Jira to preserve the full dependency logic.

Project Insight file attachments are stored within the application but are not included in the report export. We do not migrate binary attachments directly. We recommend a parallel document migration workflow: a direct download from Project Insight's file storage (handled by the customer or a file migration tool) followed by upload to Jira as issue attachments. We provide a mapping table of issue keys to their associated attachment filenames so that file relinking happens alongside the record migration.