Migrate from OnePlan to Jira

OnePlan Plans map to Jira Projects for top-level organizational units. Plans with hierarchical Program or Project plan types that contain child Work Plans can alternatively map to Jira Epics at the Epic level with child Work Plans as Issues within the Epic's scope. The customer chooses during scoping whether the destination uses a flat Project-per-Plan model or an Epic-within-Project model. We create Jira Projects via the REST API, setting the default project template (Scrum, Kanban, or Bug Tracking) based on the source Plan's work methodology metadata if present.

OnePlan Work Plans are child containers under Plans containing Tasks, Risks, Issues, and Notes. If the Plan maps to a Jira Project, the Work Plan maps to a Jira Epic within that Project. If the Plan maps directly to an Epic, Work Plans map to Stories or Tasks at the top level of the Epic's child hierarchy. We preserve Work Plan name as the Epic summary or Story summary and use OnePlan's Plan Type field to set the Jira Issue Type for the container.

OnePlan Tasks map to Jira Issues of the type matching the source Item Type field (Task, Story, Bug, or Sub-task). We preserve Summary, Description (migrated as Jira Comment or Description rich text), Estimated Start and Estimated End dates (mapped to Due Date or custom date fields), Status, Priority, and Assignee (resolved via User lookup by email). Task dependencies migrate as Jira Issue Links (Blocks / Blocked by / Depends on) where the dependency type is preserved.

OnePlan Risks under Work Plans migrate as Jira Issues using a custom Issue Type named Risk that we create in the destination Project during schema setup. We map Risk Probability and Risk Impact as custom number or select fields, Risk Owner as Jira Assignee, and Risk Status (Open, Mitigated, Closed) as the Jira Status field with a dedicated workflow path.

OnePlan's Issue entity under Work Plans (distinct from the OnePlan Work Plan itself) maps to Jira Issue with type determined by the source item's category. We preserve the original OnePlan Issue ID as a custom field source_id__c for traceability and map description, owner, status, and priority directly to Jira fields.

OnePlan Resources map to Jira Users by email address match. We extract all Resources from OnePlan including their role, department, and custom attribute fields, then resolve each Resource to the corresponding Jira user account. Resources without a Jira account are flagged in a reconciliation report for the customer admin to provision before assignee population begins. OnePlan's time-phased resource allocation percentages are preserved as custom number fields on the mapped Issues.

OnePlan's seven custom field types map to equivalent Jira field types: Text to Jira Text Field or Short Text; Date to Jira Date Picker; Number to Jira Number Field; Currency to Jira Number Field with a currency formatting note; Yes/No to Jira Checkbox; Choice to Jira Select List (single) or Radio Buttons; User to Jira User Picker. We pre-create Jira custom fields during schema setup before any data import begins, preserving the source field name as the Jira field name with __c suffix.

OnePlan's time-phased financial plan data (budget, actuals, forecast by period) has no direct Jira equivalent. We migrate financial plan headers as custom number fields on the Jira Project (Budget, Actuals, Forecast) and the detailed time-phased rows as a CSV export delivered alongside the migration. The customer rebuilds period-level financial tracking as a Jira dashboard or links the CSV to an external financial reporting tool. We document the full field mapping in the migration handoff so the financial data is not lost.

OnePlan's time-phased resource allocation data (allocation percentage by resource by period) has no native Jira equivalent. We migrate resource allocation summaries as custom number fields on Jira Issues or as Project-level custom fields, and deliver detailed time-phased allocation rows as a CSV export. Jira's native workload view handles current allocation but not historical allocation curves, so we document the gap and recommend a separate capacity planning rebuild in Jira's Power Scripts or a third-party app if period-by-period historical data must remain accessible.

OnePlan Plan Details form data associated with Plans migrates to Jira Project description fields or as custom fields on the Project. Custom form layouts in OnePlan do not migrate as form layouts; we document the form schema and field list for the customer's admin to rebuild in Jira as Project properties or as a Jira Service Management request form if the use case is intake-driven.

OnePlan Areas are top-level organizational containers that can hold multiple Plans. We map Areas to Jira Projects or to Jira Components within a Project depending on the customer's chosen structure. If the destination has multiple Jira sites or organizations, Areas may map to separate Jira organizations or site-level project groups.

OnePlan attachments do not migrate via the CSV Migration Tool and have no structured export path. We flag this gap and recommend a separate document migration using OnePlan's native download capability or SharePoint export, followed by Jira's file upload API to re-attach to the corresponding Issues post-migration. We provide a file-to-issue mapping spreadsheet as part of the handoff.