Migrate from Blueprint to Jira

Blueprint Projects map directly to Jira Projects as the primary container. The Blueprint project name becomes the Jira project name; the project key (Jira's 2-10 character uppercase identifier) is derived from the Blueprint project name or assigned by the customer's Jira admin during scoping. Project metadata (description, creation date, status) migrates as standard Jira project fields. Jira project category and lead are configured at migration time based on the customer's org structure.

Blueprint Scopes represent AI-generated work breakdowns within a Project and map to either Jira Versions (if used for release or milestone planning with dates) or Jira Components (if used for logical grouping without dates). We assess during discovery whether the customer uses Scopes with start/end dates and release notes (Version) or as static groupings (Component). If the customer uses both patterns, we document the split and apply it consistently during import.

Blueprint Tasks map to Jira Issues with the issue type determined by a scoping decision: Tasks with no sub-work become Jira Task; Tasks with sub-tasks or deliverable acceptance criteria become Jira Story with sub-tasks. Task status from Blueprint maps to Jira status (To Do, In Progress, Done); Task timestamps (created, updated, completed) preserve as Jira created, updated, and custom resolved-date fields.

If Blueprint Tasks contain sub-tasks, we split these into a parent Jira Issue with the parent's fields and child Jira Sub-tasks linked via the Parent Link field. The hierarchy depth from Blueprint is preserved as a flat parent-child Jira structure; Jira does not natively support three-level nesting without third-party apps.

Blueprint user-to-Task assignments store a user ID linked to each Task record. We resolve assignments by matching the Blueprint user email to a Jira User account in the destination instance. Any Blueprint user without a matching Jira account is placed in a reconciliation queue for the customer's Jira admin to provision before record import resumes. We preserve the original Blueprint assignee as a custom field for audit.

Blueprint's role-based access control maps to Jira's project-level permission schemes and project roles (Developers, Administrators, Users). During discovery we document every Blueprint role and its associated user set, then map each to the nearest Jira project role or permission group. Role semantics differ between platforms; we flag any Blueprint role with no direct Jira equivalent for the customer's admin to decide on access policy.

Blueprint stores attachments as URL references or stored object IDs linked to Project or Task records. We preserve attachment links as Jira Issue attachments by re-fetching the file content and uploading via the Jira REST API during the issue import phase. If the attachment storage is unreachable (self-hosted Blueprint instance with restricted access), we flag each unresolvable attachment in the migration report.

Blueprint supports custom fields at the Project level. These require schema discovery per customer configuration because field names and data types vary by account. We create matching Jira custom fields (with appropriate Jira field types: text, date, picker, checkbox, number) before migration, then map source values during import. Custom field context is set to the applicable Jira projects during schema setup.

Blueprint Task-level custom fields map to Jira Issue-level custom fields following the same discovery and type-mapping approach as project-level custom fields. Jira enforces required-field constraints at import time, so any Blueprint custom field that maps to a required Jira field without a source value must either have a default value configured or be flagged as a manual post-migration action.

Blueprint automation rules are stored as structured configuration with trigger conditions and actions. We do not migrate them as code. We document every active Blueprint automation rule during discovery (trigger type, conditions, actions, target scope) and deliver a written specification that the customer's Jira admin uses to rebuild equivalent rules in Jira Automation (cloud) or as Jira Workflow XML (Data Center or Server). The rebuild is outside standard migration scope.

Task-level comments from Blueprint migrate to Jira Issue comments with author, timestamp, and body preserved. Jira stores comments as a separate resource linked to Issue, so we import comments after the parent Issues are created to satisfy the issue key reference. Comment body content migrates as plain text; any rich-text formatting from Blueprint is preserved where Jira supports it.