Migrate from TeamGantt to Jira

TeamGantt Projects map directly to Jira Projects. The TeamGantt project name becomes the Jira Project name; the TeamGantt project description maps to the Jira Project Description field. Project key prefix (e.g., TG or PROJ) must be defined before migration because Jira requires a 2-10 character uppercase prefix on all issue keys. TeamGantt project start date (derived from the earliest task) is set as the Jira Project lead date or recorded as a custom field for Advanced Roadmaps anchor configuration.

TeamGantt tasks map to Jira Story or Task issue types depending on the parent Group relationship. Tasks with no children map to Jira Story (if representing deliverable work) or Task (if representing action items). Jira's Assignee, Priority, Due Date, and Description fields map directly from TeamGantt task fields. The Jira issue Status (To Do, In Progress, Done) is set based on the TeamGantt task percent_complete value: 0% = To Do, 1-99% = In Progress, 100% = Done. Jira sub-tasks are used for TeamGantt Groups with children, where each sub-group becomes a Jira sub-task issue.

TeamGantt task Groups (nested subtasks) require a two-level mapping. Top-level groups map to Jira Epic issues within the Project, with the Epic's summary set to the group name and the Epic description carrying the group's notes. Nested sub-tasks within a Group map to Jira Story or Task issues linked as children to the parent Epic. The Jira Epic Link custom field (or the parent-link in Advanced Roadmaps) connects each Story to its parent Epic. Teams that do not use Epics configure Stories instead and use Jira's parent-link field for hierarchy.

TeamGantt milestones are zero-duration date markers. In Jira Standard (no Advanced Roadmaps), we map milestones to Jira Task issues with a custom field milestone_date__c set to the original date, and a label milestone applied. In Jira Premium/Enterprise with Advanced Roadmaps enabled, we create Jira Milestone records linked to the relevant Epic or parent Story. The milestone name and target date migrate; no completion percentage is carried since TeamGantt milestones are static markers.

TeamGantt Finish-to-Start dependencies map to Jira Issue Links of type Blocks. If Task B depends on Task A (Finish-to-Start), Jira Issue B gets a link of type Blocks pointing to Jira Issue A. Start-to-Start dependencies map to Jira Issue Links of type 'is dependent on' (a bidirectional relationship). We preserve the dependency type and lag time (if any) in a custom field dependency_type__c on the linked issues. Jira requires the destination project to have Issue Links enabled in Project Settings > Issue Features before migration. Lag time is recorded as days_offset__c on each linked issue.

TeamGantt baselines capture a snapshot of the original planned start and end dates for tasks. Jira Advanced Roadmaps (Premium/Enterprise) supports baseline views. We export all saved TeamGantt baselines as a structured JSON artifact (baseline_name, issue_key, planned_start, planned_end, actual_start, actual_end) and provide post-migration instructions for the admin to configure Advanced Roadmaps baselines from this artifact. Standard-tier Jira migrations store baseline data as a custom field set on each migrated issue so the original planned dates are visible without the Advanced Roadmaps add-on.

TeamGantt user records (name, email, role) map to Jira User accounts. We resolve users by email address against the Jira Cloud destination org. The TeamGantt role (Manager, Collaborator, Guest) maps to a Jira project role (Administrators, Members, Viewers). If the Jira destination has fewer seats than the TeamGantt user count, we flag users not provisioned in Jira and provide a migration-user selection matrix so the admin chooses which users to carry forward.

TeamGantt labels are categorical tags applied to tasks for grouping. These map directly to Jira Labels (available in all Jira tiers). The TeamGantt label name becomes the Jira Label text value. Labels are applied to the migrated Jira issue as a Label field entry. Jira Labels are not hierarchical; if TeamGantt labels use a hierarchical naming convention (e.g., Dept:Subdept:TaskType), we flatten them to Jira Label format and document the original structure in the mapping spec.

TeamGantt checklist items on tasks are migrated as Jira Checklist app items if the destination org has the native Jira Checklist for issue subtasks (Atlassian-owned, available on Premium) or as structured text appended to the Jira issue Description if the destination does not have the Checklist app. We read checklist completion status (checked/unchecked) from TeamGantt and apply the same state in Jira. The mapping choice is made during scoping based on the destination's installed apps.

TeamGantt discussion threads on tasks map to Jira Issue Comments. We preserve full comment text, author attribution (resolved to Jira User by email), and timestamp (ActivityDate set to the original TeamGantt comment date). Comment threading structure is flattened in Jira because Jira Comments are a flat list; parent-child relationships in TeamGantt discussions are documented as a note in the mapping spec. Mentions in TeamGantt comments (@user references) are preserved as plain text and mapped to Jira user mentions where the Jira user account exists.

TeamGantt custom fields at the project level map to Jira Project-level custom fields. We discover field types via the TeamGantt API (text, number, date, dropdown) and create equivalent Jira custom fields before migration. Text fields map to Jira Text Field (free-text). Number fields map to Jira Number Field. Date fields map to Jira Date Picker. Dropdown fields map to Jira Select List (single choice) or Radio Button depending on the TeamGantt field configuration. Custom field values are set on the Jira Project or on each migrated issue as appropriate.

TeamGantt task-level custom fields map to Jira issue-level custom fields. We handle type mismatches by creating the closest Jira equivalent (e.g., multi-select from TeamGantt becomes a Jira Labels field or multi-select custom field if Jira Multi-Select is available). Currency fields from TeamGantt map to Jira Number Field. URL fields map to Jira URL Field. All custom field definitions (name, type, options, applicable issue types) are documented in the mapping spec with Jira configuration steps for the admin to verify before production migration.