Migrate from Cerebro to Jira

Cerebro Projects map directly to Jira Projects. Project name, description, status, start and end dates, and tags migrate as-is. Each Cerebro Project becomes a Jira Project with a corresponding project key (e.g., ANIM, VFX) that prefixes all issues migrated from that project. Jira project creation requires the customer to pre-configure project templates (Scrum or Kanban) in the destination before migration begins.

Cerebro top-level tasks map to Jira Epic issues. The Epic's summary, description, assignee, and due date transfer directly. If the customer prefers a flat Story-based model, top-level Cerebro tasks can map to Stories at the customer's direction during scoping. Epic-Story linking is preserved by mapping the Cerebro task's immediate children as Stories under the Epic.

Cerebro tasks nested at any depth map to Jira Stories or Tasks with parent links reconstructed. Because Jira enforces a maximum of two levels below Epic (Epic > Story > Subtask), Cerebro's unlimited nesting depth requires flattening. We preserve the full Cerebro hierarchy path in the Jira issue description as a breadcrumb trail (e.g., 'Cerebro path: Project / Act 1 / Scene 2 / Shot 10') and link parent-child relationships using Jira issue links or the parent field on Subtask.

Cerebro Subtask records map to Jira Subtask issues linked to their parent Story or Task. Assignee, status, due date, and description transfer directly. Subtasks retain the parent breadcrumb path from the Cerebro hierarchy.

Cerebro tags migrate to Jira Labels. Tag naming conventions vary by team; we extract all unique tag values across all Cerebro objects, normalize them (lowercase, remove spaces, strip special characters per Jira label format), and apply them to the corresponding Jira issues. Labels that exceed Jira's character limit or conflict with existing Jira label names are flagged for manual review.

Cerebro Gantt chart dependencies (Finish-to-Start, Start-to-Start, Finish-to-Finish, Start-to-Finish) are exported as explicit dependency edges. We map them to Jira Issue Links using the 'blocks' and 'is blocked by' link types. Jira does not natively support Finish-to-Start vs Start-to-Start semantic differences, so all dependencies are set as 'blocks' with the original dependency type noted in the link comment for the customer's admin to configure Jira Automation rules post-migration if granular dependency semantics are required.

Cerebro stores media files on its own distributed servers. We extract all attachment URLs from the Cerebro export, download each file individually, and re-upload to Jira as Attachments on the corresponding issue. Re-upload failures (due to file size limits, unsupported file types, or network errors) are logged in a per-file reconciliation report. Audiovisual commentaries are treated as linked media assets with a URL reference retained in the Jira issue description.

Cerebro Comments migrate to Jira Comments on the corresponding issue. Author attribution is preserved by resolving the comment author's Cerebro user ID to a Jira user account by email match. Comment body migrates as plain text; any Cerebro built-in translator UI artifacts are stripped during comment normalization. Inline media references in comments are converted to download links pointing to the re-uploaded attachment in Jira.

Cerebro team and individual calendars aggregate task assignments and deadlines. We extract the scheduled dates from Cerebro calendar entries and apply them to Jira issues as Start Date and Due Date. All-day vs partial-day semantics differ between platforms; Cerebro all-day entries map to Jira issues with no Start Date and only a Due Date set.

Cerebro uses a permission-group access model where users belong to named groups with specific access rights per project. Jira uses role-based access control with project roles (Administrators, Members, Viewers) and global permissions. We extract all Cerebro permission group memberships, map them to the closest matching Jira project role, and flag any Cerebro group with no direct Jira equivalent (e.g., a custom 'Reviewer' role with granular per-object rights) as requiring manual post-migration permission review.

Cerebro user accounts are matched to Jira user accounts by email address. Any Cerebro user without a matching Jira account is held in a reconciliation queue for the customer's Jira admin to provision before record import begins. User display names, avatars, and contact information transfer where available.