Migrate from PlanZone to Jira

PlanZone Projects map directly to Jira Projects. We extract project name, description, start date, target end date, status, and owner assignment from the PlanZone CSV export. The Jira Project is created using the Jira API (POST /rest/api/3/project) before any Issues are imported, so that the project key is available for Issue assignment. Jira project creation requires a Project Key (e.g., PROJ) which we derive from the first three characters of the PlanZone project name in uppercase.

PlanZone Tasks map to Jira Issues. Task name becomes Issue Summary; Task description maps to Jira's Description field (Atlassian Document Format if rich text is present). Task status (To Do, In Progress, Done) maps to Jira Status values, which we configure on the target project's workflow before migration. Priority from PlanZone maps to Jira Priority ( Highest, High, Medium, Low, Lowest). Assignee resolution uses email matching against the Jira user directory. Tasks flagged as Bugs in PlanZone map directly to Jira Bug issue type; unmarked tasks default to Story or Task based on the customer's scoping decision.

PlanZone Milestones are flagged task types marking key delivery points. We export them as Jira Issues with the same summary and due date, apply a milestone label (e.g., milestone:true) for filtering, and attach the milestone flag to the Fix Version field if the customer uses Jira Versions to represent delivery milestones. The milestone name and target date are preserved. We note during scoping whether the customer prefers a dedicated Jira Issue for each milestone or a Fix Version with the milestone date.

PlanZone stores task dependencies as a parent-reference field on the child task pointing to the parent task ID. Jira models dependencies as explicit Issue Link records with link types (Blocks, is blocked by, Relates to, Duplicate, etc.). We walk the PlanZone dependency matrix, translate each flat parent-child reference to a Jira Issue Link using the Jira API (POST /rest/api/3/issuelink), and validate that both the source and target Issues exist before creating the link. Link type defaults to Blocks for finish-to-start dependencies. This step must complete before the cutover validation pass.

PlanZone reusable project templates define a starting structure of tasks and milestones. We export the template as a project skeleton with all tasks, milestones, and dependency references documented in a written template inventory. The template link is not preserved in the CSV export, so we note the template origin as a custom property (template_source: true) on each exported task. Jira project templates are rebuilt manually in Jira using the Create Project from Template action; we provide a step-by-step template reconstruction guide based on the exported template structure. Template rebuild is out of scope for the data migration and falls to the customer's Jira admin.

PlanZone custom fields on Projects and Tasks are discovered during the schema audit step and exported in the CSV. We create equivalent Jira custom fields in the target project using the Jira API (POST /rest/api/3/field) with type mapping applied: text fields map to Text Field, date fields to Date Picker, number fields to Number Field, and single-select fields to Select List. Multi-select PlanZone fields map to Jira Multi-Select. Custom field values are loaded during the Issue import phase and mapped by field name.

File attachments on PlanZone tasks are stored as URL references. We export a file manifest listing each attachment's task ID, filename, URL, and upload date. During the Jira load phase, we download each file and re-upload it to the corresponding Jira Issue using the Jira API (POST /rest/api/3/issue/{issueId}/attachments). Files with null filenames in PlanZone will be flagged in the manifest and excluded from migration per Jira's attachment requirements.

PlanZone task comments are threaded text entries with an author and timestamp. We export them as a flat list per task and recreate them in Jira as Comments on the corresponding Issue using the Jira API (POST /rest/api/3/issue/{issueId}/comment). Comment author is resolved by email against Jira users; if the author has no Jira account, the comment is posted as the migration service account with the original author noted in the comment body. Timestamps are preserved in the comment metadata.

PlanZone assigns tasks to users by email reference. We extract every distinct user email from the Assignments column and match against the Jira destination's user directory using the Jira API (GET /rest/api/3/user/search?query={email}). Users without a matching Jira account are held in a reconciliation queue for the customer's admin to provision before the issue import phase. The migration does not create Jira users directly; it requires the admin to provision accounts for any unmatched assignees.

PlanZone uses status-driven Stages (e.g., To Do, In Progress, Review, Done) at the project level. We map these to Jira Status values on the target project's workflow. The Jira project must have a Workflow assigned (Jira Software Default Workflow or a custom workflow) before issues are imported. We configure the status mapping during the pre-migration schema step and apply it during the issue load phase. Stage-level custom fields (e.g., stage_owner) are translated to Jira labels or custom fields as agreed during scoping.

PlanZone project start date and target end date migrate to Jira Project's startDate and endDate fields if the Jira project is configured with a Project Timeline. Jira Software Premium supports project-level timelines via Advanced Roadmaps. Standard and Free plans do not have native project-level date tracking; in those cases we set the project start and end dates as Jira Labels or as custom date fields on the project.