Migrate from BigPicture to Asana

Each Jira project becomes an Asana Project. Jira project key (e.g., ENG, MKT) does not map to an Asana-native identifier; we document the original key as a custom field jira_project_key__c for traceability. Jira project administrators map to Asana project leads. If the BigPicture Box contains multiple Jira projects, each project becomes a separate Asana Project with all issues migrated into it.

Jira issues map directly to Asana Tasks. Summary, description, assignee, due date, priority, status, and created/updated timestamps migrate. Jira issue key is preserved in a custom field jira_issue_key__c for cross-reference. Fix version maps to Asana milestones or a custom field depending on whether the destination Asana plan includes milestone support (Starter and above). Subtasks map to Asana Subtasks.

Jira issue links of type Blocks, Blocked By, and Dependency map to Asana finish-to-start dependency arrows in the Timeline view. Jira issue links that represent parent-child containment (Issue Hierarchy) map to Asana Subtask nesting. We export Jira issue links through the Jira REST API and construct Asana dependencies by posting to the /tasks/{task_gid}/addDependencies endpoint. Jira links that have no Asana equivalent (例如 Relates To, Clone, Issue Split) are documented as a text field note on the destination task.

Gantt chart data — timeline bars, start/finish dates, constraints, and dependencies — is exported from BigPicture as MS Project MPP or XML format (BigPicture's native export path). We then parse the MPP/XML to reconstruct the dependency graph and date logic, and apply it as Asana Timeline dependencies with the correct start and due date values on each migrated task. Critical path tracking in BigPicture has no direct Asana equivalent; we document the critical path tasks as a custom field critical_path__c so the PMO can rebuild it in Asana manually or via Rules.

BigPicture Boxes are programme-level containers that hold multiple Jira projects. Asana has no direct Box equivalent at the lower plans. In Asana Premium and Enterprise, Portfolios provide cross-project views with status and progress; at Starter and Business, Teams provide a shared workspace for multiple projects. We configure Portfolios (or Teams as fallback) to replicate the Box programme view and document the Box-to-Portfolio mapping as a written configuration guide for the customer's PMO admin to apply after migration.

Resource allocation data — capacity hours, utilisation percentage, and assignment loads per team member — lives in BigPicture modules and has no native Asana equivalent on Starter or Business plans. On Asana Premium and Enterprise, Workload view provides a capacity vs. assigned hours visualisation. We map resource allocations to Asana Workload (Premium/Enterprise) where available; on lower tiers, we create custom fields (capacity_hours__c, utilisation_pct__c) as a data-preservation pass and document the Asana Workload rebuild steps.

BigPicture Risk records have fields for risk title, description, probability, impact, status, and owner. Each Risk becomes an Asana Task in a designated Risks project, with probability mapped to a custom picklist field risk_probability__c, impact mapped to risk_impact__c, and status mapped to risk_status__c (open, mitigated, accepted, closed). We split risk responses from the risk record as task subtasks to preserve the mitigation action plan.

BigPicture's Scope module is a hierarchical WBS tree that groups issues under parent scope items. We flatten the WBS into Asana Subtask hierarchies where the scope item parent becomes a parent Asana Task and its child issues become Subtasks. Parent-child relationships are preserved by nesting depth. Scope item attributes (scope name, planned hours, progress) migrate as custom fields on the parent task.

BigPicture Teams group members and assign work. On Asana Starter and Business, Teams are the top-level grouping mechanism; on Asana Premium and Enterprise, Teams also provide cross-project visibility. We map BigPicture team memberships to Asana Team membership, with the team lead mapping to a Team admin role. If the team structure in BigPicture is simpler (one team per project), we use Asana Sections within a Project as a lighter-weight grouping.

Jira labels migrate to Asana tags. Labels are a flat list per issue and map cleanly to Asana's tag model without transformation. We deduplicate labels across all migrated issues and create the tag set in Asana before the task import phase.

Jira attachments on issues migrate as Asana attachments on the corresponding task. We use Jira's attachment download endpoint (GET /rest/api/3/attachment/{id}) and upload to Asana via the POST /attachments endpoint. Attachments larger than 100 MB are flagged for manual re-upload because Asana's attachment API has a 100 MB limit per file.

Jira issue comments migrate to Asana task comments with author and timestamp preserved. Jira comment body (which may include Jira Wiki-style markup) is converted to plain text or Markdown before import to avoid rendering issues in Asana's comment field.

Jira work logged on issues (time spent, author, date) has no native Asana equivalent. We create a custom field time_spent_hours__c (numeric, two decimal places) on the migrated Asana task and populate it with the total logged hours per task. Detailed time entry history (per-session log entries with author and date) is preserved in a JSON sidecar file linked to the task as an attachment for audit purposes. If the customer requires native time tracking in Asana, we document the Asana Time Tracking integration (available on Business and Enterprise) as a post-migration configuration step.

BigPicture creates its own custom fields for resource and timeline data (例如 capacity fields, timeline range fields, percentage fields). We map these to Asana custom fields by type: BigPicture date-range fields become Asana Start Date and Due Date or custom date fields; capacity fields become numeric custom fields; percentage fields become Asana numeric fields with percent display. Field type validation is performed before migration to catch incompatible types (例如 Jira text fields that should be picklists).