Migrate from Project.co to Jira

Project.co projects map to Jira Projects. We extract project name, description, status, created date, and custom field values via CSV export, then create the Jira Project with an auto-generated project key during scoping. Jira project keys must be uppercase alphanumeric (3-10 characters) and are unique per Jira instance; we resolve any naming conflicts by appending a numeric suffix. Project.co's client-visible flag maps to Jira project's Public/Private visibility setting.

Project.co tasks map to Jira Issues. We map task title to Issue Summary, task description to Issue Description, task status to Jira Issue status (To Do/In Progress/Done or custom workflow statuses), task assignee to Jira Assignee (resolved by email), due date to Due Date, and priority to Jira Priority. Project.co does not have issue types; we configure a default issue type (Story) during Jira project setup, or create separate issue type schemes for Story/Task/Bug if the customer specifies a multi-type configuration.

Project.co subtasks are not a distinct object type; they are tasks with a parent task association. We detect parent-child task relationships from Project.co's task list, then create Jira Subtasks linked to their parent Story or Task via the Parent Link field. If Jira's Subtasks feature is not enabled on the destination project, we create flat tasks with a parent reference in a custom field.

Project.co discussions are per-project threaded message feeds. We flatten each thread as a chronological list of comments with author, timestamp, and body text, then attach each comment to the corresponding Jira Issue as an Issue Comment in thread order. File attachments referenced in discussions migrate as Jira attachments to the parent issue. Mentions and @-references in discussion text are preserved as plain text because Jira mentions require user context at render time.

Project.co files are stored in project-level folders. We download file binary content and re-upload to Jira as Issue Attachments on the corresponding issue using Jira's REST API. File metadata (uploader name, upload date) is preserved in a custom field if the customer requests an audit trail beyond Jira's native attachment history. We flag the total attachment volume during scoping because individual file downloads extend the export timeline significantly.

Project.co Notes are standalone rich-text documents attached to projects. We map each note's title and content to a Jira Issue's Description field if the note is short and issue-specific. For project-level documentation that does not attach to a single issue, we create Jira Document records (if Jira's native document feature is enabled) or flag the note for manual Confluence page creation post-migration. Formatting is simplified to Jira's Atlassian Document Format (ADF) because Project.co's rich-text schema may not map 1:1.

Project.co time entries (task-level with duration, date, and billable flag) map to Jira Issue Worklogs. We preserve duration and date on every worklog entry. Project.co does not store hourly rates, so Jira worklogs inherit no billing rate; we flag this in the scoping report and advise the customer to configure billing rates in Jira if billable time tracking is required. The billable/non-billable flag from Project.co maps to a custom worklog field (billable__c) rather than a native Jira field because Jira does not have a built-in billable flag.

Project.co custom fields on projects map to Jira Project Properties (for project-level metadata) or Jira custom fields on the issue schema (for per-issue metadata). We extract custom field definitions (name, type, options) and their values per record. Custom field types including text, number, date, dropdown, and checkbox are mapped to equivalent Jira custom field types. Jira's custom field context (which project or issue type the field applies to) is configured during Jira project setup.

Project.co custom fields on tasks map to Jira custom fields on Issues. We extract task-level custom field values per task and import them as Jira custom field values on the corresponding issue. If a Project.co custom field uses a picklist with options, we create a Jira custom field of type Single Select or Multi Select and populate the options. Jira requires custom fields to be created and configured (with field context) before data import; we deploy field configuration via Jira REST API or CSV import configuration file.

Project.co clients access projects via a client portal link without consuming a paid seat. We extract client email addresses and names and map them to Jira user accounts. Jira's permission model uses project roles (Viewers, Users, Administrators) rather than Project.co's per-project role assignments. We create Jira user accounts for clients and add them to the appropriate project role, but Jira guest access (external users without a full license) requires Jira Cloud with at least a Standard plan. We flag this during scoping because Enterprise-tier Jira Data Center may require different user provisioning.