Migrate from Workfront to Jira

Workfront Portfolios have no direct Jira equivalent. We map each Portfolio to a Jira company-managed Project, using the Portfolio name as the Jira Project name and the Portfolio description as the Project description. If multiple Portfolios exist, they become multiple Jira Projects. Financial summary fields from the Workfront Portfolio (budget vs actual) migrate to a Jira custom field on the Project-level because Jira does not have a native financial summary object.

Workfront Programs sit between Portfolios and Projects. We map Programs to Jira company-managed Projects if the customer's Jira environment uses a multi-project structure per department, or to Epics if Programs contain a single thematic workstream and the customer prefers Epic-level grouping inside a department-level Jira Project. The customer's project governance model determines this choice during scoping.

Workfront Projects map 1:1 to Jira Projects. We use the Workfront project name as the Jira Project name, the project status maps to the Jira Project status, start and completion dates map to Jira Project lead time fields, and the assigned Workfront project owner maps to the Jira Project Lead. We preserve the Workfront project URL in a custom field for audit trail purposes.

Workfront Tasks map to Jira Stories (user-facing work items), Tasks (operational work items), or Bugs (defect tracking). We use the Workfront task name as Jira Summary and the Workfront task description as Jira Description (migrated as Jira's rich text format). Task status from Workfront (NEW, INP, ONHD, CPLD, DED) maps to Jira status categories (To Do, In Progress, Done) via a status mapping table defined during scoping. We preserve the Workfront task priority as a Jira custom field if the customer's workflow requires it.

Workfront Subtasks are child tasks with the same field schema as Tasks. They map 1:1 to Jira Subtasks. We resolve the Jira parent Issue reference at migration time by matching the Workfront parentTaskID to the Jira issue key generated from the parent Task. Jira Subtasks inherit the parent Project context automatically. Jira Subtasks do not have their own Status Category mapping; they inherit transitions from the parent Issue type's workflow.

Workfront Issues (trackers of blockers or change requests against Projects or Tasks) map to Jira Task or Bug depending on whether the Workfront Issue type is 'Issue' or 'Bug'. We preserve the Workfront issue priority, the assigned user, and the issue status. Request Queue intake forms have no direct Jira equivalent; we document the queue structure as a written reference for the customer's Jira admin to recreate using Jira Service Management forms or project-level components if needed.

Workfront custom field names, data types, and picklist values vary by customer instance. We discover the full custom field schema via the Workfront API before migration, then pre-provision matching Jira custom fields with correct data types in the target Jira project. Picklist values migrate as Jira custom field options. Multi-select picklists map to Jira multi-select. Date fields map to Jira Date or DateTime fields. We flag any Workfront custom field with no Jira equivalent (e.g., Adobe-specific metadata) for customer review during scoping.

Workfront Approvals are attached to Tasks, Projects, Documents, or Timesheets and define a workflow of stages and approvers. Jira has no native approval workflow as a separate object. We extract the approval status (Approved, Rejected, Pending) and the approver name and timestamp, then write this as a Jira Comment on the mapped Issue with the format 'Approval status: [status] by [approver] on [date]'. This preserves the audit trail without requiring a marketplace approval add-on.

Workfront Documents attach to Projects, Tasks, or Issues and support versioning and proofing. We extract document content via the Workfront API and attach the file to the corresponding Jira Issue using Jira's Attachment API. Proof approval status migrates as a comment (see Approval mapping). Automated Workflow proofing templates have no Jira native equivalent; we provide a proofing replacement guide recommending a Jira-compatible marketplace add-on (e.g., Comala, EasyVista) or Confluence-based review.

Workfront Users are mapped to Jira Users by email address match. Job Roles (which carry billing rates in Workfront) have no Jira equivalent; we preserve the Job Role name and billing rate as custom fields on the Jira User record if the customer's finance team requires revenue attribution. Inactive Workfront users who still own records are mapped to inactive Jira users to prevent assignee orphans.

Workfront Notes are the conversation thread on Projects, Tasks, or Issues where team members leave updates. We extract the full note history including author, timestamp, and rich text content, then create Jira Comments on the mapped Issue. We preserve the original Workfront author name in the Jira Comment attribution. Notes created by system (rather than users) migrate as Jira Comments flagged with [System Note] to distinguish them from manual updates.

Workfront Billing Records capture billable revenue against a Project and lock permanently once marked as Billed. Jira has no native financial object. We export all Billing Records (including Billed ones, which cannot be edited) as a separate financial extract delivered as a structured CSV alongside the Jira migration. The extract includes project name, billing record ID, amount, status, and date. Jira project financial tracking is handled by the customer's finance team post-migration using Jira custom fields or a third-party finance add-on.