Migrate from SMART Project Control to Jira

SMART Project Control Programs act as top-level grouping containers for related Projects. We map each Program to a single Jira Project, and nest the source Projects as Jira Epics or as separate Jira Projects within the same project key family depending on the customer's visibility requirements. Programs with rollup reporting needs are re-parented to Jira project folders or to a Confluence page hierarchy for documentation linkage since Jira has no native Program object.

Projects migrate 1:1 to Jira Projects with core attributes preserved: Project Name, Project Key (we generate a key from the source name, validated for uniqueness), start date mapped to the Jira Project creation date, and status (Active, On Hold, Completed) mapped to Jira Project archived state. Project-level custom fields migrate to Jira Project properties or to a custom Jira Project configuration page.

Activities are the core scheduling unit and map across Jira issue types based on WBS level and hierarchy depth. Top-tier WBS activities map to Jira Epics; mid-tier activities map to Stories; lower-tier activities map to Tasks; and leaf-node activities map to Subtasks. Activity fields including Name, Start Date, Finish Date, Duration, and Calendar migrate to Jira fields (Summary, Due Date, Assignee, Labels). Predecessor and successor relationships migrate as Jira Issue Links (Blocks / Is blocked by / Depends on).

SMART Project Control Baselines store the approved schedule snapshot and are referenced by EV calculations. Jira has no native baseline object. We migrate the latest approved baseline as a Jira Fix Version named with the baseline date, and apply it to all issues that existed at baseline time. The source baseline schedule data is preserved in a custom field baseline_snapshot__c as a JSON reference for audit. We flag EV metrics (PV, EV, SV) as requiring manual recalculation in Jira's reporting layer.

Work Breakdown Structure elements define hierarchical accountability and cost coding accountability in SMART Project Control. We flatten multi-level WBS into Jira's three-tier Epic > Story > Task structure and tag each migrated issue with WBS path labels (e.g., WBS-1.2.3) in a custom Label field for traceability. Cost account assignments on WBS elements migrate to Jira custom fields linked to the Cost Breakdown Structure mapping.

Labor, material, and equipment Resources — including roles, rates, and unit-of-measure — migrate as named Jira Users and Project Role assignments. We resolve each SMART Resource to a Jira user by email match; any resource without a Jira user is held in a reconciliation queue. Resource rates and capacity data migrate to a custom Resource__c object or to Jira Assets object types if the destination is Jira Service Management-linked.

Resource-to-Activity assignments in SMART Project Control map to Jira Issue Assignee. Planned hours from the assignment migrate to the Jira issue's Original Estimate (or Story Points if the customer prefers an estimation-based model). Actual work logged against activities migrates to Jira Worklog entries with the SMART-recorded hours and date.

Cost CBS levels and cost accounts map to Jira custom fields on the migrated issues. We create custom fields cbs_level_1__c through cbs_level_3__c as text or picklist fields, and cost amounts migrate to a custom field cost_amount__c. Time-phased cost distributions (weekly or monthly budget buckets) migrate as Jira project-level custom records or as rows in a linked Jira Assets Object Schema if the customer licenses Assets. Jira does not natively calculate earned value from cost data.

Cumulative S-curves and progress curves are time-phased data rows per project. We convert them to Jira Dashboard gadgets (Burndown or Cumulative Flow diagram using the source curve as a reference data table) and tag the corresponding issues with the percentage-complete value in a custom field pct_complete__c. The raw time-phased data is delivered as a CSV attached to the Jira Project for manual chart rebuilding in Confluence if needed.

Custom activity, project, and resource fields are exported with their current values and field types. We create equivalent Jira custom fields with matching types (text, date, number, picklist) and apply them to the relevant issue types' screens before migration. Picklist values require explicit mapping instructions from the customer to ensure option sets match between Oracle Cloud and Jira. Jira's field context model means custom fields are scoped per project by default; we configure project-level contexts during migration.

Critical path activities and float values are preserved as Jira Labels (Critical_Path label applied to critical path issues) and as custom number fields float_days__c and critical_path_flag__c. Jira does not calculate critical path natively post-import. We document the exported critical path chain so the customer's project controls team can re-verify the path after any Jira issue date changes. This is a manual post-migration validation step, not an automated calculation.

SMART Project Control bottleneck alerting rules generate notifications when activities approach or exceed schedule thresholds. Jira Automation for Cloud (or Data Center Automation) provides an equivalent trigger-and-action model. We deliver a written inventory of each source alerting rule with its trigger condition, threshold, and notification action, mapped to the equivalent Jira Automation rule for the customer's admin to rebuild post-migration. We do not rebuild Jira Automations as part of standard migration scope.