Migrate from ftrack to Jira

ftrack Projects map directly to Jira Projects. Each Project in ftrack contains the full hierarchy (Sequences, Shots, Tasks) that we decompose and redistribute into Jira Epics and Stories. Project-level custom attributes migrate as Jira Project properties or custom fields scoped to the Project. We create Jira Projects via the Jira REST API before any child issue migration begins, using the Project key from the ftrack Project name as the Jira Project key.

ftrack Sequences map to Jira Epics. Each Sequence contains one or more Shots that become Jira Stories linked to the Epic via the Epic Link field. We preserve the Sequence name as the Epic summary and Sequence-level custom attributes as Epic-level custom fields. The Sequence > Shot parent-child relationship becomes Epic > Story in Jira's issue hierarchy.

ftrack Shots map to Jira Stories. The Shot's parent Sequence becomes the Story's Epic Link. Shot status, thumbnail reference (as a URL in a custom field), and Shot-level custom attributes migrate as typed Jira custom fields. We flag Shot records that contain no child Tasks as they represent terminal deliverables with no Jira Subtask equivalent.

ftrack Tasks map to Jira Subtasks linked to the parent Story (derived from the Shot). Task assignees map to Jira Subtask Assignee; Task status maps to Subtask Status with name-matching against the Jira Status scheme. Task due dates migrate as Due Dates; Task notes migrate as Jira Comments with the original author preserved as the Comment author if a matching Jira User exists.

ftrack Assets represent published files or builds linked to a Shot context. Jira has no native Asset object. We map Asset publish records as Jira Issue Links of type 'Relates' attached to the parent Story, with the Asset name and version stored in a custom field on the linked issue. For Asset metadata that functions as structured data (render farm output specs, resolution, codec), we create Jira custom fields typed to match the data format.

Multiple ftrack Asset Versions for a single Asset (sequential publishes) map to multiple Jira Issue Link records, each attached to the same parent Story. Version number, publish date, and publishing user migrate as link metadata fields. Jira does not have a version-on-version history object; this flattened representation preserves the publish sequence for audit without native version tracking.

ftrack Notes attached to any entity (Project, Shot, Task) migrate to Jira Comments. We resolve the target object by traversing the ftrack note's context_id against the hierarchy and linking to the corresponding Jira Issue. A known ftrack behavior is that notes posted via the webplayer sometimes attach to the wrong parent object; we detect mismatched notes by comparing context_id against the resolved task hierarchy and re-associate them with the correct parent before writing to Jira.

ftrack Locations define studio-specific file storage paths including cloud and on-premises configurations. Jira has no storage-location concept. We export Location configuration as a JSON metadata document delivered alongside the migration, listing each Location name, path pattern, and associated Assets. The migration team and studio infrastructure admin review this document post-migration; file path references do not transfer into Jira's data model.

ftrack Review Sessions with frame annotations link to an Asset Version. Jira has no native interactive media review capability. We migrate review session metadata (session name, participant list, date range) as a Jira Comment on the related Story, storing annotation count and version reference as structured text. Actual annotation overlays cannot transfer because Jira does not support frame-level drawing tools on media attachments.

ftrack custom attributes on any entity type (Project, Shot, Task, Asset) map to Jira custom fields scoped to the appropriate issue type context. We handle the type mapping: text attributes to Jira Text Field, date attributes to Jira Date Field, number attributes to Jira Number Field, and dropdown-style attributes to Jira Single Select. Hierarchical custom attributes (inherited from parent) return raw null values in the ftrack API; we query the parent entity for the effective value and write the resolved value to Jira.

Expression custom attributes in ftrack are UI-evaluated formulas (e.g., calculated due dates, derived status). The ftrack API returns the non-evaluated expression string, not the computed value. We flag all expression attribute fields during pre-migration scope and document them in the handoff deliverable. These values must be recalculated or replaced with Jira calculated fields (if supported) or manual entries post-migration.

ftrack Users assigned to Tasks map to Jira User records resolved by email address. We pre-provision Jira Users before record migration begins. Assignees without a Jira User account are placed in a reconciliation queue; the customer's admin provisions accounts before migration resumes. Active and inactive status is preserved where Jira supports inactive-user records.