Migrate from Goplan to Jira

Goplan project workspaces with descriptions, member access controls, and dates map to Jira Projects. Project metadata (name, description, created date, archived status) migrates directly. Jira project settings (issue types, default workflow, notification scheme, permission scheme) require reconfiguration because Jira's permission model uses project roles and groups rather than Goplan's member-access model. We preserve the member list as a Jira permission export for the admin to reassign post-migration.

Goplan tasks with title, description, assignee, due date, status, and custom field values map to Jira Issues (Story, Task, or Bug depending on the Goplan task type inferred during discovery). The Goplan status taxonomy (for example: Open, In Progress, Done) does not map automatically to Jira workflow statuses; we design the Jira workflow schema during scoping, map each Goplan status to a corresponding Jira status, and configure the workflow transitions before issue import begins.

Goplan's flat status list requires mapping to Jira's workflow-driven status model. Each Goplan status value becomes a Jira Status (for example: Open to To Do, In Progress to In Review, Done to Done) and we configure the valid transitions between statuses as Jira Workflow transitions. If Goplan had informal status categories not modeled in the system, we infer them from task data during discovery and document them for the admin's workflow design review.

Goplan timesheet entries logged per user against specific tasks and date ranges present a mapping challenge because Jira Software does not include a native timesheet module. If Jira Tempo is present or planned in the destination Jira environment, we migrate timesheet data as Jira Issue worklog records linked to the corresponding Issue. If Jira Tempo is not in scope, we map hours to a custom field (for example: goplan_hours__c) on the Issue record and document the timesheet report reconstruction plan using Jira's native reporting or a reporting plugin.

Goplan user accounts with roles and project memberships map to Jira Users by email address match. Jira's free plan supports up to 10 users; if the Goplan workspace exceeds this, we flag the overage during scoping and the customer decides whether to provision paid Jira seats before migration or archive inactive Goplan users. Goplan collaborator roles (admin, member) are preserved as Jira project role assignments or as a custom field for post-migration reconciliation.

Goplan custom fields on tasks and projects map to Jira Custom Fields of the corresponding type (text, number, date, select, multi-select). Jira's custom field system requires field context configuration (which issue types and projects the field applies to) and screen configuration (which Create and Edit screens display the field). We pre-create the Jira custom field schema, configure the field context, and attach it to the relevant screens before any data migrates.

Goplan custom field values on individual tasks migrate to the corresponding Jira Custom Field. Text, numeric, and date values migrate directly. Select and multi-select values from Goplan require a value mapping table because Jira picklist options must exist in the destination before the record can be saved; we create the picklist options in Jira during the schema phase before migrating the values.

Goplan report definitions and historical output export as data but do not have a direct Jira equivalent because Jira separates reporting into native Jira Software reports and configurable Dashboard gadgets. We export Goplan report data as CSV, document each report's metrics and underlying data sources, and deliver a written plan for reconstructing the key reports as Jira Dashboards and Saved Filters. Goplan report configurations (schedules, distribution settings, formulas) are not migratable and require manual rebuild in Jira.

Goplan task-level comments have not been confirmed as a separately exportable object in the available Goplan documentation. During scoping we verify whether comments are embedded in task records or stored as a separate entity. If they are embedded, we extract them alongside task data and insert them as Jira Issue Comments linked to the corresponding Issue using the Jira REST API. If they are not exportable, we flag this as a data gap and document the limitation for the customer.

Goplan file attachments on tasks or projects have not been confirmed as exportable in the available documentation. During scoping we verify whether attachments are accessible via Goplan's UI export or stored outside the primary data store. If exportable, we download files and attach them to the corresponding Jira Issues via the Jira REST API. Files over 10 MB require chunked upload handling; we flag this during scoping. If attachments are not exportable, we document the limitation and recommend a parallel file migration process.