Migrate from OmniPlan to Jira

Each OmniPlan .omniplan file maps to one Jira Project. Project-level metadata (name, start date, description) migrate as the Jira Project name and description. Jira Project key (e.g., PROJ) is auto-generated or assigned during scoping. If the customer has multiple OmniPlan files, each becomes a separate Jira Project. We validate project key availability in Jira before migration begins.

OmniPlan tasks map to Jira Issues. Task Name becomes Issue Summary. Start date and Finish date migrate to Jira's custom date fields or to the Description field if Jira Advanced Roadmaps is not in scope. Duration (work-time) migrates as a custom field (Original Estimate in hours or days). Work-time vs elapsed-time flags are preserved in a custom picklist field duration_type__c so Jira admins can filter elapsed-time tasks post-migration. Elapsed-time tasks will not auto-recalculate in Jira; they serve as fixed-date records.

OmniPlan subtasks (outline level > 1) map to Jira Sub-Task issues linked to their parent Story or Task via the Jira Sub-Task Issue Link type. The Jira Sub-Task field enables Parent Link to create the hierarchy. Outline level is preserved in a custom field outline_level__c for reporting. Jira's 3-level hierarchy cap (Epic > Story > Sub-task) is enforced; any OmniPlan tasks deeper than Sub-task (level 4+) are promoted to Sub-task with a lineage note in the Description.

OmniPlan milestones (zero-duration tasks with a finish date) map to Jira Fix Versions. The milestone name becomes the Fix Version name; the milestone finish date becomes the Fix Version Release Date. We create Fix Versions during Jira project configuration before any issue migration begins, so that issues can be linked at import time. If the customer used multiple milestone types (phase, deliverable, external), we create multiple Fix Version categories (Released, Unreleased) and document the categorization in the handoff report.

OmniPlan named resources (people, equipment, materials) map to Jira User accounts via email address lookup. Resource Max Units become a custom field max_units__c on the Jira User record. Resource Hourly Cost becomes a custom field hourly_cost__c for budget reconstruction in Jira if the customer uses a cost-tracking plugin. Equipment and material resources that have no Jira User equivalent are flagged in the handoff report as needing a Jira User account (or a dedicated project role) to represent the resource in the system.

OmniPlan resource-to-task assignments map to Jira Assignee on the Issue. Assignment percentage from OmniPlan is written to a custom field assignment_percent__c on the Jira Issue. Jira's Assignee field accepts only one User per issue, so tasks with multiple resource assignments in OmniPlan are handled as follows: the primary resource (highest allocation %) becomes Jira Assignee; secondary assignments are written to custom fields secondary_assignee__c and tertiary_assignee__c. A Jira admin review of multi-resource tasks post-migration is recommended to validate allocations.

OmniPlan Finish-to-Start dependencies map to Jira 'is blocked by' links (predecessor blocks successor). Start-to-Start maps to a custom Jira issue link type 'start together' that we configure in the target project. Finish-to-Finish maps to 'finish together'. Start-to-Finish maps to 'start after'. Lag time is preserved as a custom field lag_days__c on the successor issue. Jira does not support lead time natively; lead time is converted to negative lag and documented in the mapping notes. Dependency direction and type are validated after migration by running a test that opens each linked issue pair and confirms the correct blocker relationship.

OmniPlan hammock tasks derive duration from the span of their child tasks. Jira has no hammock concept. We calculate the hammock's effective start date (earliest child start) and finish date (latest child finish) at migration time and write a fixed-duration task with those dates. The original hammock calculation intent is preserved in the Description field as a note: 'Original hammock: duration derived from children [child1] through [childN].' The customer can use Jira Advanced Roadmaps to re-implement this as a rolled-up view if the roadmap add-on is licensed.

OmniPlan Pro custom data fields per task or resource map to Jira custom fields. We extract the field name, data type (text, number, date, picklist, checkbox), and all values, then pre-create the equivalent Jira custom field with the same name (sanitized for Jira API compatibility). Value-type mapping: OmniPlan text → Jira Text Field (single line); OmniPlan number → Jira Number; OmniPlan date → Jira Date; OmniPlan picklist → Jira Select (single choice); OmniPlan multi-select → Jira Labels or Multi-select. Custom fields are scoped to the target Jira project before migration begins.

OmniPlan recurrence rules (daily, weekly, monthly, annual) are expanded into individual Jira Issue instances at migration time. The recurrence rule itself does not transfer because Jira has no native recurrence rule object. Each generated issue carries a custom field recurrence_pattern__c (e.g., 'Monthly on the 1st') and recurrence_group__c (a shared UUID linking the series) so that Jira admins can identify the series post-migration and configure Jira Automation rules to manage future instances.

OmniPlan baseline snapshots (multiple baselines with dated task start/finish/duration) are written as custom fields on each migrated Jira Issue: baseline_1_start__c, baseline_1_finish__c, baseline_2_start__c, etc. The baseline name and capture date are stored in a project-level custom field baselines__c as a JSON block. Jira does not have a native baseline comparison view; the customer uses Jira Advanced Roadmaps (Premium) or a third-party Gantt app for baseline-vs-actual visualization.