Migrate from Shotgun to Jira

Shotgun Projects map directly to Jira Projects. Project-level metadata including name, description, status, and pipeline configuration migrate as Project fields. We create Jira Projects via the Project resource endpoint before any entity migration begins so that Project keys are available for downstream issue creation. Studio-specific pipeline schema configurations that cannot be expressed as Jira Project settings are preserved as a written configuration inventory for the customer's admin.

Shotgun Sequences (editorial groupings of Shots) map to Jira Epic issues. The Epic's summary and description carry the Sequence name and notes. Epic issues are created before Shot-level migration so that the Epic key is available as a parent reference when Stories are created. Studios that do not use the Sequence entity may map Sequences to Jira Labels or custom field groupings instead; we confirm during scoping.

Shotgun Shots map to Jira Stories linked to the parent Epic derived from the Shot's Sequence. Each Shot's cut_order, status, and assigned Tasks migrate as Story fields. Shot-level custom fields (cut_in, cut_out, head_duration, tail_duration) map to Jira custom fields of equivalent type. Shots without a Sequence parent map to Stories in a backlog Epic or a designated catch-all project. The Shot's Version chain is reconstructed as an ordered chain of comments on the Story, with version number, artist, and notes preserved.

Shotgun Assets (characters, props, environments) map to Jira Stories or Tasks depending on the studio's asset tracking model. Asset type (Character, Prop, Environment, Vehicle) migrates as a Jira label or custom field. Asset thumbnails migrate as Jira issue attachments with a naming convention identifying them as the primary asset image. Assets without assigned Tasks are imported as Stories; Assets with Task assignments are imported as parent Stories containing Subtasks that correspond to the Asset Tasks.

Shotgun Tasks assigned to Shots or Assets map to Jira Subtasks linked to the parent Story. Task pipeline_stage, task_assignees, and task_status migrate as Subtask fields. Unassigned Tasks or Tasks that do not belong to a Shot or Asset parent map to Jira Tasks in the project backlog. Task dependencies (prev_task_entity, next_task_entity) map to Jira issue links (Blocks, Blocked by) if the destination Jira instance has the appropriate link type configured.

Shotgun Versions (iterations in the review pipeline) do not have a native Jira equivalent. We reconstruct the version chain as an ordered chain of Comments on the parent Story, each Comment containing the version number, version artist, version date, status, and review URL from Shotgun. Version approval status migrates as a Jira label or custom field on the Story. Studios with dedicated review workflows may choose to represent versions as Jira Labels for filtering rather than comments.

Shotgun Notes attached to Shots, Assets, or Tasks map to Jira Comments on the corresponding Story or Subtask. Shotgun's threaded Reply structure (where a Reply has a parent Note) is flattened in Jira: top-level Notes become Comments, and Replies become child Comments or replies via Jira's comment threading. Note author and timestamp migrate with each Comment. Shotgun's @mention syntax in Notes maps to Jira @mention in Comments if the mentioned user has a Jira account.

Shotgun Attachments (uploaded files, render outputs, published media linked to Shots, Assets, or Versions) migrate as Jira issue attachments. We use Shotgun's get_attachment_download_url endpoint to retrieve attachment blobs and re-upload to Jira via the attachment endpoint. Attachment file size is constrained by Jira's attachment limits (the maximum file size varies by tier: 10 MB for Free, 250 MB for Standard and Premium Cloud). Large render outputs and video files that exceed Jira limits are flagged during scoping and linked as external URLs if the studio uses a DAM or storage system, or uploaded to Jira if within limits.

Shotgun entity thumbnails (for Shots, Assets, Versions, and Tasks) migrate as Jira issue attachments with a thumbnail_ prefix in the filename. Jira does not have a native thumbnail display for issue avatars outside of the attachment list, so we attach thumbnails to the relevant Story with a note identifying them as the primary thumbnail for display purposes. Jira Premium offers issue property macros that can surface thumbnail attachments in issue detail views.

Shotgun pipeline statuses are studio-specific and vary widely between Shotgun sites. We extract the source site's pipeline workflow for each entity type (Shot, Asset, Task) and map each status value to a Jira Status within a Status Category (To Do, In Progress, Done). Any status with no Jira equivalent is flagged and escalated during scoping. Studios with multi-stage approval pipelines (e.g., wip, review, approved, omit) map to Jira status values plus Jira workflow transitions; we provide the status mapping matrix as a written deliverable.

Shotgun per-entity custom fields migrate to Jira custom fields of matching type (text, number, date, list, entity reference). Shotgun list fields (status picklists, type picklists) map to Jira select (single-choice) or multi-select fields. Entity reference fields (e.g., a custom field pointing to a Shot or Asset) map to Jira custom issue property or a Jira label. Custom field schemas vary between Shotgun sites, so we perform field-level mapping during the discovery phase before any data moves.

Shotgun freeform Tags applied to any entity migrate to Jira Labels on the corresponding issue. Tags are stored as a flat list in Shotgun and Jira labels are a comma-separated field, so the migration is direct. Studios that use Tags for content classification (e.g., asset type, shot type, sequence category) should verify during scoping that Jira Labels provide sufficient filtering granularity for their post-migration workflow.