Migrate from ftrack to Asana

ftrack Projects are the top-level container holding Sequences, Shots, Tasks, and custom attributes. We map each ftrack Project to either an Asana Team (for organization-level grouping) or an Asana Project (for work-level grouping), depending on how many ftrack Projects exist and whether the customer uses Asana Teams for department-level separation. The ftrack Project name, status, and custom attributes migrate to the Asana Team description or Project custom fields. Schema dependency: Projects must be created before Sequences and Shots because those entities hold parent references.

ftrack Sequences sit between Project and Shot in the hierarchy. We map each Sequence to an Asana Project (if the customer wants per-sequence work plans) or an Asana Section within the parent Project (if sequences are treated as task groupings rather than standalone work plans). The mapping choice is made during scoping based on the customer's workflow. Sequence status, name, and custom attributes transfer to the Asana equivalent. Parent Project reference resolves to the Asana Team or Project GID created in the Project phase.

ftrack Shots are children of Sequences and parents of Tasks. We map Shots to Asana Sections within the parent Project (the standard mapping for mid-volume shot lists) or to standalone Asana Projects (for large productions where each Shot requires its own task plan and timeline view). Shot status, thumbnail URL (stored as a text custom field reference), and custom attributes migrate. Parent Sequence reference resolves to the Asana Project or Section GID from the Sequence mapping phase.

ftrack Tasks are the core work unit with a parent link to Shot or Sequence, assignees, due dates, status, notes, and custom attributes. Tasks map 1:1 to Asana Tasks. Assignee email addresses resolve to Asana User GIDs via the User mapping. Due dates migrate directly. ftrack Task status values map to Asana Sections or to a custom status field depending on whether the customer uses Timeline view, which requires named Sections for stage tracking. Notes attached to the Task migrate as Asana Task Comments.

ftrack Assets represent published files or asset builds linked to a Shot or Sequence context. Asana has no native asset library or version control. We handle Assets in one of two ways depending on the customer's choice during scoping: (a) create a custom Asana Text field asset_reference__c on Tasks, storing the original ftrack Asset name, version count, and a link to the expected file path; or (b) attach the most recent Asset Version as a file attachment to the Task. Media files themselves are not transferred; we document the expected file location and let the customer's infrastructure team manage the actual asset transfer.

ftrack Asset Versions represent sequential publishes of an Asset, each with a version number, file path, components, and metadata. Asana has no native version history. We store the version chain as a newline-separated list in a custom Text field asset_versions__c on the linked Task (format: v1: /path/to/v1 | v2: /path/to/v2). For productions where version history is critical, we recommend using Asana's Proof attachments or a third-party DAM integration post-migration rather than storing full version chains inside task fields.

ftrack Notes attach to any entity (Project, Shot, Task) and include author, timestamp, and body text. We migrate Notes as Asana Task Comments linked to the resolved Task. A known ftrack behavior (documented in ftrack gotchas) is that Notes posted via the webplayer sometimes attach to the wrong hierarchical level, landing at the topmost parent object instead of the intended child Task. We detect these mismatched notes during pre-migration validation by comparing each note's context_id against the task hierarchy and re-associate them with the correct parent Task before writing to Asana.

ftrack custom attributes are key-value pairs stored in a custom_attributes dictionary on any entity type. We map each ftrack custom attribute to an Asana Custom Field of the closest matching type: Text, Number, Enum (single-select), or Date. Hierarchical custom attributes (set on a parent Shot and inherited by child Tasks) require special handling because ftrack's API returns the raw value rather than the evaluated inherited value; we query the parent entity for the effective value during migration and store that. Expression attributes (calculated formulas) return the non-evaluated expression string from ftrack's API; we flag these fields in the migration inventory and advise the customer to recalculate values in Asana manually or via a post-migration script.

ftrack Users are assigned to Tasks as assignees and carry name, email, and role. We extract every distinct ftrack user referenced on Task records and match by email against the destination Asana workspace's User table. Users without a matching Asana account go into a reconciliation queue for the customer's admin to provision before Task migration begins. Inactive ftrack users are mapped to inactive Asana Members with a custom field original_ftrack_role__c storing the ftrack role designation.

ftrack Review Sessions store frame annotations, reviewer comments, and approval status linked to an Asset Version. Asana has no native review or annotation module. We extract review session metadata (session date, reviewer name, frame number, annotation text, approval status) and store it as a formatted Asana Task Comment on the Task linked to the reviewed Asset. The original review media (annotated frames, video markup) is not transferred; we flag the expected storage location for the customer's team to manage separately.

ftrack Task Statuses are configurable per project with name, color, and sort order. Asana does not have a global status object—Statuses are represented by Section names (for List and Board views) or by a custom Enum field. We map ftrack Status values to either Asana Sections within each Project or to a custom single-select field task_status__c, depending on whether the customer uses Timeline view (which requires Sections for stage gates). Any ftrack status with no exact Asana equivalent is flagged in the scope document for the customer to map manually.

ftrack Locations define storage configuration for assets and files, including cloud and on-premises paths with optional Python plugin logic. These are studio-specific and carry infrastructure-specific path logic. We do not migrate Location records as functional storage configuration because Asana has no storage configuration layer. Instead, we export Location names and path templates as a metadata document and store a reference in a custom Text field asset_location__c on Tasks where the original ftrack Location is relevant. The customer's infrastructure team uses the metadata document to configure their file management system post-migration.

ftrack Spreadsheets are a view configuration (column layout, sorting, filters) rather than a data object and cannot be exported as records. We do not migrate spreadsheet views. We document the column configurations and filter settings from each ftrack Spreadsheet as a written reference so the customer's Asana admin can rebuild equivalent List or Board views in Asana. This is listed in the handoff inventory.