Migrate from GanttPRO to Jira

GanttPRO projects map directly to Jira Software projects. We preserve the project key, name, description, and project-level settings including the auto-scheduling toggle state and duration step (hours, days, weeks, or months). Jira projects require a key prefix (such as PROJ) which we generate from the GanttPRO project name or preserve if the customer has an existing Jira project key convention. Project-level permissions and notification schemes migrate as part of the project configuration export.

GanttPRO summary tasks (parent rows that group related subtasks and display rollup progress on the Gantt chart) map to Jira Epic issues within the destination project. The summary task name becomes the Epic summary; the estimated duration and rollup progress map to the Epic's custom fields. Subtask rollup percentage is preserved in a custom field ganttpro_rollup_progress__c on the Epic for audit and reporting. If the customer prefers a flat issue hierarchy, summary tasks map to parent Story issues with linked Sub-tasks instead.

Standard GanttPRO tasks map to Jira Story or Bug issues depending on the task type field in GanttPRO. Task name becomes Issue Summary; start date and end date map to the Jira custom fields ganttpro_start_date__c and ganttpro_due_date__c or to the GanttPRO for Jira add-on fields if that app is installed. Assignee, priority, status, and description migrate directly. Progress percentage from GanttPRO maps to a custom field ganttpro_progress__c.

GanttPRO subtasks (nested under summary tasks with their own dates and assignments) map to Jira Sub-task issues linked to their parent Story or Epic. Subtask dates, assignees, and status preserve. Jira's native Sub-task issue type must be enabled in the destination project settings before migration; if not enabled, subtasks are created as standard linked issues instead.

GanttPRO supports four dependency types: Finish-to-Start (FS), Finish-to-Finish (FF), Start-to-Start (SS), and Start-to-Finish (SF). Jira's default issue link types include Blocks and Relates To but do not natively distinguish between dependency directions. We create four custom Jira link types (ganttpro_blocks_fs, ganttpro_blocks_ff, ganttpro_blocks_ss, ganttpro_blocks_sf) during schema setup, map each GanttPRO dependency to the corresponding link type, and validate link counts post-migration against the source. Circular dependency detection from GanttPRO is preserved as Jira comments on the offending issues.

GanttPRO project members (human users with project-level access) map to Jira User accounts by email address. We resolve each project member's email against the Jira instance user directory and set the Jira issue Assignee field. Any project member without a matching Jira user is flagged in the reconciliation report for the customer's admin to provision before the production migration phase.

GanttPRO virtual resources are role-based placeholders (such as Senior Developer or QA Engineer) with assigned cost rates per hour or per day. Jira has no native virtual resource or cost-rate concept on the standard issue schema. We extract virtual resource assignments as task-level notes in a custom field ganttpro_virtual_resource__c, preserving the resource name, role, and cost rate for manual assignee mapping in Jira. Customers who need cost tracking configure Jira custom fields for billable hours or integrate with an Atlassian marketplace app for resource management.

GanttPRO custom fields (Advanced and Business tiers) support text, number, date, dropdown, and checkbox types. We map these to Jira custom fields of the equivalent type: GanttPRO text to Jira Text Field, GanttPRO number to Jira Number Field, GanttPRO date to Jira Date Picker, GanttPRO dropdown to Jira Select List, and GanttPRO checkbox to Jira Checkbox. Field values migrate per issue. Custom field context (project-specific versus global) maps to Jira's field configuration scheme.

GanttPRO time entries (date, user, duration in hours, and optional comment) map to Jira Worklog records on the corresponding issue. The time tracking must be enabled in the Jira project settings before migration. GanttPRO exports time logs as XLSX only; we parse the XLSX during scoping, convert to structured records, and map the duration to Jira's time tracking format (such as 3h 30m). Worklog author is resolved by email match against Jira users. Note that GanttPRO time logs do not include a billing rate field by default; if the customer uses resource cost rates for billing, those rates are preserved in a custom worklog field.

GanttPRO portfolios group multiple projects for high-level strategic monitoring across an organization. Jira does not have a native portfolio object without Jira Align or Structure add-ons. We migrate portfolio membership as a custom field portfolio_name__c on each Jira project or as a Jira label for grouping. If the customer licenses Jira Align post-migration, the portfolio hierarchy is rebuilt within that platform.

GanttPRO Budget Tracking (Business tier) stores automatic calculation mode (resource rates multiplied by estimated hours) or manual budget values per project. Jira has no native budget module. We extract the calculated budget value and the resource-rate derivation and map them to Jira custom number fields: ganttpro_budget_total__c and ganttpro_budget_mode__c. If the customer requires active budget tracking, we recommend a Jira-compatible financial app from the Atlassian Marketplace.

GanttPRO project calendars define working days, holidays, and calendar exceptions per project. Jira has project-level working day configurations in project settings. We export GanttPRO calendar exceptions and map them to Jira's working days configuration. Jira does not support per-project holiday sets natively; holidays are set at the Jira instance level and apply globally.