Migrate your ftrack data

Projects are the top-level container in ftrack's hierarchy. They hold Sequences, Shots, and Tasks and carry custom attributes and project-level settings. We export and import them as a full subtree, preserving the full hierarchical structure down to Tasks.

Sequences sit between Projects and Shots in the hierarchy. Each Sequence contains Shots. When migrating into ftrack, we create Sequences and link them to the parent Project; when migrating out, we preserve the Sequence-to-Project relationship and all child Shots.

Shots are children of Sequences and parents of Tasks in ftrack's data model. They carry status, thumbnail, and custom attributes. We map Shot IDs and names bidirectionally and preserve the Sequence parent linkage during import.

Tasks are the core work unit in ftrack, with a parent link to Shots or Sequences. Tasks carry status, assignees, due dates, notes, and custom attributes. We migrate Tasks including their parent reference so they land in the correct location in the destination.

Assets represent published files or asset builds linked to a Shot or Sequence context. Each Asset has one or more Asset Versions. We migrate Assets with their version history and the context_id linkage preserved.

Asset Versions represent sequential publishes of an Asset. They carry file paths, components, and metadata. We preserve version numbers and component references when migrating in or out.

Notes can be attached to any object in ftrack (Project, Shot, Task). A known ftrack behavior is that notes posted via the webplayer sometimes land at the wrong task level, attaching to the topmost parent instead. We detect this during migration and re-associate notes with their intended parent object based on context metadata.

Custom attributes are configurable fields on any entity type, stored as key-value pairs in a custom_attributes dictionary. The ftrack API has limitations: hierarchical attributes return raw values rather than evaluated ones, and expression attributes return non-evaluated values. We read the raw values and document these limitations in the pre-migration report.

Users are assigned to Tasks as assignees. User records include name, email, and role. We map assignee references and can create placeholder users in the destination if the target system does not yet have matching accounts.

Locations define storage configuration for assets and files, including cloud and on-premises paths. They are studio-specific and carry Python plugin logic. We export the Location configuration as metadata but do not migrate the underlying file storage—we flag this for the customer's infrastructure team to reconfigure post-migration.

Review sessions and frame annotations are stored with a link to the Asset Version. We migrate review session metadata and annotation data. Media files themselves are not moved; we flag their expected storage path in the destination system.

Task Statuses are configurable per project and include name, color, and order. The status schema varies between ftrack workspaces. We map status values by name and flag any that have no exact match in the destination system.

ftrack Spreadsheets are a view configuration (column layout, sorting, filters) rather than a data object. They cannot be exported as standalone records. We do not migrate spreadsheet views; we rebuild the Task list view in the destination using the underlying Task data.