Migrate from Exepron to Jira

Exepron Projects map directly to Jira Projects. We export project metadata (name, status, start/finish dates, priority) via GET /projects and create corresponding Jira Projects during migration. If the source Exepron account uses multiple concurrent project portfolios, we recommend one Jira Project per Exepron project or one Jira Project per portfolio, depending on the customer's reporting structure. Jira Project keys (e.g., ENG, MKT) are derived from the project name during scoping.

Exepron Activities map to Jira Issues. Task Name becomes Summary, Duration and Start/Finish dates map to Due Date and a custom duration field. Activity Kanban statuses and Custom Activity Statuses are mapped to Jira Status values in the destination workflow scheme. For Activities with parent Work Packages, we set the Jira Epic Link custom field or nest as Stories under the parent Epic. Fixed-duration flags migrate as a custom field; Jira treats all issues as variable duration by default.

Exepron predecessor chains (Finish-to-Start by default) migrate to Jira Issue Links. We use the Jira issue-links REST API to create dependency records after both the source and destination issues exist. The predecessor sequence in Exepron is preserved as the link type and order. Jira does not support buffer insertion between linked issues; we capture buffer duration as a custom field (ccpm_buffer_duration__c) and document the original buffer position in the migration notes for the customer's admin to address in project planning.

Exepron Resources (people, equipment, facilities) map to Jira Users by resolving the resource name or email against the Jira instance user directory. If a Resource has no corresponding Jira User, we hold it in a reconciliation queue for the customer's Jira admin to provision. Resource Capacity and Consumption units are stored as custom fields on the mapped Issue because Jira does not have a native resource capacity model.

Exepron Resource Types (grouping Resources for drum scheduling) map to Jira Project Roles. We export the type hierarchy from Exepron and create corresponding Project Roles in Jira (e.g., Developer, Designer, QA Lead). Resource assignments in Exepron become Jira Issue Assignees scoped to the appropriate Project Role. The Dynamic Drum recommendation is not migratable as an artefact; we preserve the drum recommendation timestamp and constraint window in a custom field for manual re-entry in Jira.

Exepron Activity Bundles (grouping related Activities under a Work Package) map to Jira Epics. We export the bundle hierarchy and create Jira Epics in the destination project. Child Activities become Stories linked to the Epic via the Epic Link custom field. If Activities span multiple Exepron Projects, we use Jira's Cross-Project Epic Links or restructure into a single parent Epic with Stories distributed across the relevant Jira Projects during scoping.

Exepron Custom Fields map to Jira Custom Fields of the closest matching type (text, number, date, select). We export field definitions and values from Exepron and pre-create the corresponding Jira custom fields in the destination project before import. Multi-select custom fields in Exepron map to Jira multi-select or checkboxes. Custom field contexts (project-level vs. global) are preserved. Jira's custom field scoping model differs from Exepron's per-account model; we configure contexts during schema design.

Exepron Project Templates (reusable task networks with resource assignments) map to Jira Project Templates. We export the template block structure and task sequence from Exepron and use Jira's Project Template feature to pre-populate new projects. Template Blocks are supported but require manual reconstruction in Jira because Jira Project Templates do not preserve a full Activity hierarchy; we document the block structure as a handoff artifact for the customer's admin to use when creating new projects from template.

Exepron Custom Roles (permission scoping within Exepron) map to Jira Project Roles and Permission Schemes. We export the role definition and permission set from Exepron and map to the nearest Jira permission category (Browse Projects, Create Issues, Assign Issues, etc.). Exepron-specific permission concepts (e.g., portfolio-level access, BIDSS access) have no direct Jira equivalent; we flag these in the permission mapping document and recommend Jira administrators use Jira administrators, project administrators, and site-wide access levels to approximate.

Exepron Earned Value Module (Planned Value, Earned Value, Actual Cost per task) migrates as point-in-time custom fields on the mapped Jira Issues. We export the EV snapshot values at migration time and create numeric custom fields (exepron_ev__c, exepron_pv__c, exepron_ac__c) in Jira. Because EV is calculated at migration time and Jira does not natively update EV after cutover, we flag this as a historical snapshot rather than a live metric. The customer's admin rebuilds EV tracking using a Jira marketplace app or external BI tool if ongoing EV reporting is required.

Exepron What-If scenarios (cloned projects with modified constraints, durations, or resource loads) are exported as separate Jira Projects with a naming convention that flags them as scenario variants (e.g., PROJ-WhatIf-A, PROJ-WhatIf-B). The delta changes (modified durations, resource loads, start date shifts) are captured in a custom field (exepron_scenario_delta__c) as JSON. Jira does not natively support What-If scenario modeling; the customer's admin rebuilds this using Jira Automation, Structure ( marketplace app), or a third-party scheduling tool.

Exepron Alerts (threshold-based notifications for task slippage and resource overload) and Reason Codes (annotations for why slips occurred) migrate as Jira Labels or custom select fields. We export the alert definitions and reason code values and map them to Jira Labels (preferred for cross-issue reporting) or to a custom Status Category + custom field if the customer requires structured reason-code tracking. Alert trigger thresholds are not migratable as live rules; we document them for the customer's admin to reconstruct as Jira Automation rules.