Migrate from ActionPlanner to Jira

Each ActionPlanner Roadmap maps to a Jira Project. We confirm the target Jira plan (Free supports 1 project, Standard and Premium support unlimited projects) and configure project settings (key prefix, default issue type scheme, default permission scheme) before data import. If the source account has multiple Roadmaps, each becomes a separate Jira project with its own issue type scheme and workflow.

ActionPlanner Objectives (top-level strategic containers with title, description, owner, and date range) map to Jira Epic issues. The Epic's Summary field carries the Objective title, Description carries the objective text, and the Assignee carries the owner. Start Date and Due Date from the Objective migrate to Epic's custom fields (customfield_10020 and customfield_10021 on Jira Cloud default schemas, confirmed during scoping). Parent-child linkage from Initiative to Objective is preserved via the Epic Link field on the Jira Story.

ActionPlanner Initiatives (mid-level work breakdown with purpose, deadline, owner, and child milestones) map to Jira Story issues. The Initiative title becomes Story Summary; Initiative purpose and description map to Story Description; deadline maps to Due Date. Parent Objective linkage is preserved by setting the Epic Link custom field on each Story to the migrated Epic key. If Jira's Epic Link field is not available in the target configuration, we use a custom field parent_objective__c to carry the reference.

ActionPlanner Milestones (time-bound checkpoints with title, due date, status, and owner) map to Jira Stories when they represent deliverable work items, or to Subtasks when they are checkpoint completions under a parent Story. The mapping decision is made during scoping based on whether the milestone has independent assignees and due dates or is purely a status marker. Milestone status (active, completed, at-risk) maps to Jira status category (In Progress, Done, or a custom status with at-risk label) using a status mapping table built during scoping.

ActionPlanner Actions (atomic to-dos with title, description, assignee, due date, and status) map to Jira Task issues or Subtasks depending on whether the Action has child actions in the source data. Tasks inherit the Summary, Description, Assignee, Due Date, and Priority fields directly. Parent milestone linkage is preserved via the parent key or a custom parent_milestone__c field when the Jira schema does not support native subtasking for the target issue type.

ActionPlanner KPIs are numeric or percentage-based performance indicators attached to Objectives. They do not have a direct Jira standard field equivalent. We create Jira custom number fields (cf_type = number, decimal) per KPI definition during Jira schema setup, attach them to the Epic issue type via the associated screen, and populate them from the source KPI current and target values. KPI name becomes the custom field label; current and target values are stored as separate custom fields or as structured text in a JSON-formatted custom field depending on the customer's reporting preference.

ActionPlanner user names and email addresses are extracted from owner fields across all object types. We match by email against the destination Jira site's user directory. Any ActionPlanner owner without a matching Jira user is placed in a reconciliation queue for the customer's Jira admin to provision before the record migration phase. Role and permission hierarchy from ActionPlanner does not export and cannot be migrated.

ActionPlanner Roadmap metadata (name, description, created date, owner) migrates to Jira Project settings (Project Name, Project Description, Project Lead). The Roadmap creation timestamp becomes the Jira Project creation date if the Jira API supports project creation date setting, otherwise it is recorded in a custom project metadata field.

ActionPlanner decision logs and discussion threads attached to plans and actions do not expose a documented export in the platform's admin interface. We flag this as a gap during scoping and note it in the migration handoff document. The customer's admin may request vendor assistance to export conversation history separately, but this is outside the standard migration scope. Jira comments on migrated issues must be rebuilt manually or through a separate comments-import script if a comment export is obtained from ActionPlanner.

If the source ActionPlanner account uses custom fields at the CORPORATE tier, we extract the field name, data type, and instance values during the export phase. Custom field types (text, number, date, select, multi-select) are mapped to the nearest Jira custom field type available in the target Jira plan. Free plan Jira has custom field support; Premium unlocks additional field types including script fields and aggregation fields. Custom field configuration (screen association, required flag, default value) is documented and applied in the Jira project settings before record migration.