Migrate from BigPicture to Jira

Jira Projects migrate directly as Jira project structures. BigPicture uses Jira projects as containers for Boxes and Gantt modules; after migration the project configuration, issue types, and custom field associations carry through the standard Jira export path. Issue-linkage between projects remains intact during migration.

Issues are the atomic work units in Jira and carry all BigPicture task data as custom fields. We migrate issues with full field fidelity including assignee, reporter, status, fix version, sprint assignment, and any BigPicture-specific custom fields that have a Jira-native or plugin-equivalent target.

BigPicture creates its own custom fields for resource allocation, timeline data, and percentage fields. We map these to Jira custom fields of equivalent type, validating field type compatibility especially for date-range, percentage, and user-picker fields. Fields that reference BigPicture module IDs are flagged for the customer to map to Jira equivalents (Epic Link, Sprint, Fix Version) before migration.

Boxes are BigPicture's primary portfolio-level containers grouping Jira projects or selected issues. Jira has no direct Box equivalent. We map Box structure to a hierarchy of Jira Projects (for programme-level grouping) or Epic-to-Feature-to-Story nesting (for work-level grouping). The customer chooses the target representation during scoping, and we document the Box-to-hierarchy mapping for manual reconstruction in Jira Plans or Advanced Roadmaps.

Gantt configurations including timeline bars, dependencies, constraints, and critical path data are stored as BigPicture module data on top of Jira issues. We export to MS Project MPP/XML format for maximum fidelity preservation, preserving dependency types (Finish-to-Start, Start-to-Start, Finish-to-Finish), lead/lag, and constraints. In Jira, these dependencies map to Jira issue links (Blocks, Is Blocked By, Depends On) and the Jira Plans timeline view.

Roadmap views are constructed from Box and project timeline data in BigPicture. We preserve the view structure (which projects and epics appear, date ranges, and progress indicators) as a written specification for Advanced Roadmaps configuration. Jira Plans (available from Jira Software Premium and Enterprise) provides multi-project roadmap views that replace BigPicture roadmaps for most use cases.

Resource allocation data including capacity, utilisation, and assignment loads lives in BigPicture modules. We map these to Jira custom fields (for simple capacity values) or flag them for Tempo Timesheet and Planner if the customer continues using a resource management plugin in Jira. Jira and Jira Software Standard have no native resource management.

Risks are tracked in a dedicated BigPicture module with custom fields for probability, impact, status, and mitigation plan. We extract them as structured records and map to a Jira Risk issue type (if configured in the destination project) or to existing issue types with custom risk fields. The BigPicture risk status (Open, Mitigating, Closed) maps to Jira resolution values.

Scope trees are BigPicture-specific hierarchical structures representing the work breakdown. We flatten them into Jira Epic-Feature-Story-Subtask hierarchies or the equivalent configured hierarchy in the destination Jira project. Parent-child relationships are preserved as Jira issue links or as standard Jira sub-task relationships.

BigPicture teams group members and assign them to work packages. We map team memberships and assignments to Jira project roles (Developers, Testers, Project Administrators) or Jira user groups. Team capacity data maps to the same Jira custom fields used for resource allocation.

Attachments on Jira issues are standard Jira attachments stored in the Jira database or Atlassian-optimised cloud storage. We migrate them through the standard Jira file export path with file name, content type, author, and creation timestamp preserved.

Logged work on Jira issues carries through standard Jira export. BigPicture does not store its own time data; all time entries are Jira-native. We migrate worklog records with author, duration, start date, and comment intact.