Migrate from Shotgun to Asana

Shotgun Projects map to Asana Projects as the primary container. For studios with multiple distinct production groups, we map each Shotgun Project to an Asana Project within a Team. Project-level metadata including status, description, and start and due dates migrate as Project fields. The Asana Team structure is established first as the parent container so that Projects are created inside the correct Team scope.

Shotgun Sequences group Shots into editorial acts or sequences and carry sequence-level metadata. We map Sequences to Asana Project Sections within the same Project, preserving the sequence-to-shot relationship as Section membership. If the studio uses Sequences as independent planning units, we map them to Sub-Projects within the parent Project to maintain editorial hierarchy.

Shotgun Shots are the core production entity containing cut order, status, and assigned Tasks. We map Shots to Asana Tasks within the relevant Project or Section, preserving shot code as the Task name prefix (e.g., SEQ001_010) and shot description as the Task description field. Shot status maps to a custom single-select field sg_shot_status__c with values derived from the source pipeline stage list. Cut order is preserved as a custom number field sg_cut_order__c used for sorting.

Shotgun Assets (characters, props, environments, and other reusable production elements) map to Asana Tasks with a custom field sg_asset_type__c indicating the asset kind (character, prop, environment, vehicle, etc.). Asset status migrates to a custom single-select field sg_asset_status__c. The Asset-to-Shot link (which Shots reference which Assets) is preserved as a custom multi-select field sg_linked_shots__c or as a Tag on the Asset Task.

Shotgun Tasks are assigned to Shots or Assets and contain pipeline stage, status, assignee, and due date. We map these to Asana Subtasks nested under the parent Shot or Asset Task, preserving Task status in a custom field sg_task_status__c, assignee as the subtask owner, and the pipeline stage as a custom field sg_pipeline_stage__c. Task priority from Shotgun maps to Asana Task Priority.

Shotgun Versions are linked to Shots or Assets and represent review iterations. Asana has no native version-control equivalent, so we reconstruct the version chain as an ordered set of Task Attachments, with the version number and iteration notes preserved as a Comment on each version attachment. The most current Version is flagged with a custom field sg_current_version__c. Studios using Frame.io or Review 365 for review workflows may prefer to migrate Version metadata as task notes pointing to the external review platform.

Shotgun Notes attach to any entity and support threaded Replies. We map Notes to Asana Comments on the corresponding Task. Reply depth is preserved as a comment threading indicator. Shot or Asset linkage is preserved via the parent Task reference. Note author from Shotgun maps to the Comment author field; note creation timestamp migrates as the Comment timestamp.

Shotgun Attachments include uploaded files, render outputs, and published media linked to Shots, Assets, or Versions. We use Shotgun's download_attachment and get_attachment_download_url endpoints to extract files, then upload to Asana via the attachments endpoint. We flag any file exceeding 100 MB for manual handling because Asana's API and UI both reject attachments above that size. Files are staged in batches with download pacing to stay within Shotgun's undocumented rate limits. Attachment metadata (filename, upload date, linked entity) is preserved in a FlitStack AI manifest for reconciliation.

Thumbnails are entity-level images for Shots, Assets, Versions, and Tasks. We extract them via upload_humbnail or download_attachment and re-associate them as Task Attachments in Asana, noting that Asana does not display thumbnails in list or board views the way Shotgun does. Studios using Asana primarily as a coordination layer rather than a review platform typically accept this trade-off. If visual reference is critical, we can attach the thumbnail as a pinned image to the Task description.

Shotgun custom fields vary widely between sites in type, display name, and list values. We perform field-level mapping during scoping, matching each Shotgun custom field type to the closest Asana custom field type (enum for list values, text for freeform, number for numeric, date for date fields). Custom field schemas are created in the destination Asana Project before data import, and field values migrate as typed values against the destination field GID. Custom fields that have no Asana equivalent (e.g., Shotgun entity reference fields pointing to other Shots) are flagged for review.

Shotgun pipeline statuses are customizable per entity type and vary widely between studios. We map the source site's pipeline stage workflow to either Asana Project Sections (for sequential editorial stages like Assembly, VFX, Composite) or a custom single-select field sg_pipeline_stage__c on Tasks (for parallel workflow stages). We flag any statuses that reference pipeline logic beyond simple ordering, such as automated approval gates, and document them in the automation inventory for rebuild in Asana Rules.

Shotgun Tags are freeform labels applied to any entity. We preserve tag assignments as Asana Tags, mapping the Shotgun tag name directly to the Asana Tag name. Tag color is not carried over from Shotgun because Asana manages tag color internally. If tags represent classification categories (e.g., render priority, review status), we document the tag taxonomy for potential migration to custom single-select fields for stronger filtering in Asana.

Shotgun Users are persons with roles and permissions. We migrate the user record including name and contact email, but role and permission sets are destination-specific. User-to-Task assignment migrates by resolving the Shotgun user to an Asana User by email match. Any Shotgun user without a matching Asana User is placed in a reconciliation queue for the customer's admin to provision before Task import resumes. Admin and supervisor roles require manual reassignment in Asana after migration.

Shotgun maintains work day rules via work_schedule_read and work_schedule_update. We extract the schedule configuration and attempt to apply it to the Asana Workspace's calendar working days settings, noting that Shotgun work schedules often encode studio-specific holidays and production blackouts that must be manually re-entered in Asana.