Migrate from workspace.pm to Jira

workspace.pm Projects map directly to Jira Projects. We extract project name, status (active/archived), start and target dates, owner, and any project-level custom fields. Jira project creation uses the Jira Cloud REST API POST /rest/api/3/project. For Jira company-managed projects we set the project type key (software), template (Scrum or Bug Tracking), and issue security scheme. For team-managed projects the schema is lighter but fewer Jira automation options are available post-migration. Archived projects migrate as closed Jira projects with the original closure date preserved.

workspace.pm Tasks map to Jira Issues. The Issue Type (Epic, Story, Task, Bug) is assigned based on a customer-defined mapping rule established during scoping — by default workspace.pm Task maps to Jira Story, and workspace.pm Bug maps to Jira Bug. Standard field mapping: title -> Summary, description -> Description (stored as Jira rich text), status -> Status (via status category mapping: To Do, In Progress, Done), assignee -> Assignee (resolved by email against Jira User), due date -> Due Date, priority -> Priority (mapped by label). We set the parent Project reference at insert time.

workspace.pm Subtasks nested under Tasks map to Jira Sub-Task Issue Type. Jira requires that Sub-Task be enabled in the project's Issue Type Scheme. We preserve the parent-child relationship by setting the Parent Issue ID during insert. The Sub-Task inherits the parent's Project, Assignee, and Sprint if assigned. Jira's Sub-Task display in the parent Issue's detail view matches the workspace.pm task-subtask nesting that teams rely on for work breakdown.

workspace.pm Milestones have no direct Jira equivalent. Jira Software does not ship a native Milestone object. We transform Milestones into Jira Fix Versions (releases) with the following mapping: Milestone name -> Fix Version name, Milestone target date -> Fix Version release date, Milestone description -> Fix Version description. Each Issue in Jira that was assigned to a workspace.pm Milestone receives the corresponding Fix Version in its Fix Version / Affects Version field. Version-level reporting in Jira (burndown by version, release report) reconstructs the milestone tracking view. Jira administrators who prefer a dedicated Milestone label rather than Fix Version can alternatively use a Label with the milestone name; the choice is confirmed during scoping.

workspace.pm predecessor-successor task dependencies map to Jira Issue Links. We extract the dependency pair (predecessor task ID, successor task ID, dependency type if available) and create Jira Issue Link records with type Blocks on the successor issue pointing to the predecessor issue. Jira's default link types include Blocks, Is blocked by, Clone of, Relates, and Duplicates; we use Blocks for workspace.pm finish-to-start dependencies. The Jira Global Issue Linking setting must be enabled for the destination instance. Orphaned dependencies (where the predecessor or successor task was not migrated) are flagged in the reconciliation report and resolved manually.

workspace.pm custom fields at project and task level map to Jira custom fields. We extract the full custom field schema (field name, data type, picklist options, and current values) during the pre-migration data audit. Jira Cloud supports the following custom field types relevant to this migration: Date picker, Date time picker, Number field, Select field (single select), Multi-select, Text field (single line and multi-line), URL, Labels, Checkbox, User picker (single and multi-user). workspace.pm picklist options map to Jira Select field options; multi-checkbox fields map to Jira Multi-select. Jira custom fields require context configuration (association to Issue Type and Project) before they accept data during import.

workspace.pm Resource management records assign team members to projects and tasks with a role and an allocation percentage. In Jira, the Assignee field holds the primary assigned user. workspace.pm allocation percentage migrates as a Jira Number custom field allocation_pct__c scoped to the task-level Issue Type. Role information from workspace.pm (e.g., Developer, QA, Designer) migrates as a Labels custom field on the Issue if Jira Roles are not in use, or as a Jira Project Role membership where the destination team uses Jira's native role model. We resolve assignees by email match against the Jira User directory.

workspace.pm time entries (user, date, hours, description) map to Jira Worklog records. Jira's native time-tracking feature must be enabled in the destination project before worklogs can be inserted. We insert worklogs via the Jira REST API POST /rest/api/3/issue/{issueIdOrKey}/worklog with fields started (ISO 8601 with timezone), timeSpent (Jira duration format, e.g., 3h 30m), and comment. If Jira time-tracking is not enabled, time entries migrate as a Text field on the Issue. We validate that the Jira user performing the migration has the Worklog On Issues permission in the destination project.

workspace.pm discussion threads on tasks and projects map directly to Jira Comments. We extract comment text, author (resolved by email to Jira User), and timestamp. Comments insert via the Jira REST API POST /rest/api/3/issue/{issueIdOrKey}/comment. Jira's add comment permission is validated per project before migration. Rich text formatting from workspace.pm comment bodies is preserved as Jira ADF (Atlassian Document Format) to the extent that the source export exposes structured formatting; plain text comments migrate as plain text Jira comments.

File attachments linked to tasks or projects are exported as file references from workspace.pm and uploaded to Jira via the Jira REST API POST /rest/api/3/issue/{issueIdOrKey}/attachments. We transfer filename, uploader, upload date, and file URL. Jira's attachment size limit is 64 MB per file on most plans. Files exceeding this limit are flagged in the pre-migration audit and discussed with the customer — options include uploading to a shared storage location and linking via URL, or uploading the file to Jira's connected Google Drive or OneDrive integration.

workspace.pm Portfolio-to-project associations do not have a direct Jira equivalent. Jira Product (Jira Software Premium) provides portfolio-level project grouping but requires an additional license. For standard Jira Software Cloud, we reconstruct portfolio membership as Jira Labels applied to each Project record: the label format is portfolio-{portfolio-name} allowing teams to filter across projects by label. Alternatively, Jira Components within a project provide a closer grouping construct if the portfolio structure maps to sub-project components rather than cross-project groupings. The customer confirms the preferred reconstruction strategy during scoping based on how they use portfolio views in workspace.pm.