Migrate from Demand Metric to Jira

Demand Metric Projects map to Jira Projects. We preserve the project name, description, start/due dates, and status. Jira requires a Project Key (e.g., MKT, ENG) that we derive from the first 2-3 characters of the project name; if the key is already in use in the destination Jira site, we append a numeric suffix and flag for the customer's admin to confirm the final key before import begins.

Demand Metric Tasks map to Jira Story or Task based on their position in the hierarchy. Tasks with child subtasks in Demand Metric map to Jira Story (which natively supports Subtask children). Standalone tasks map to Jira Task. We apply this distinction during the CSV transform step before Jira API insertion, using the presence of a parent_task_id field in the exported data as the determinant.

Demand Metric subtasks (child tasks within a parent task) map directly to Jira Subtask issue type with the Jira Parent Issue field set to the migrated parent task's Jira issue key. Jira requires Subtasks to be enabled per project — we confirm Subtask issue type is active in the destination project before this phase. We preserve the subtask title, description, assignee, due date, and priority.

Demand Metric tags are flat string labels applied to tasks across projects. We map them to Jira Labels scoped per project. Jira Labels do not inherit cross-project behavior — the same tag label exists independently in each project. During discovery we extract the complete tag vocabulary, and the customer's Jira admin decides whether to apply labels selectively per project or to the entire workspace. Tag-based filter logic in Demand Metric does not transfer.

Demand Metric assignees are extracted by email from the task export. We resolve against the destination Jira site's User table by email match. Any Demand Metric assignee without a matching Jira user is held in a reconciliation queue for the customer's Jira admin to provision before record import resumes. Inactive Jira users can receive imported issues if the admin explicitly sets Allow inactive users to be assignees in Jira settings.

Demand Metric custom fields on tasks require pre-creation as Jira Custom Fields before any data can migrate. We identify all custom field names and data types during discovery (text, number, date, select, multi-select) and configure the Jira schema in a Sandbox pass first. Jira Custom Fields require explicit issue-type context — we assign each custom field to the relevant issue types (Story, Task, Subtask) in the destination project. A missing field context causes the known Jira import error JRASERVER-28006.

Demand Metric's marketing calendar milestones (date-bound events used to anchor project timelines) map to Jira Fix Version with Type set to Milestone. We extract milestone name, description, and target date from the Demand Metric marketing calendar export and create Jira Fix Versions before issue migration begins, then link each relevant issue to the corresponding Fix Version via the Jira Fix Versions field during import.

Demand Metric task comments migrate as Jira Comments on the corresponding Jira issue. Comment body, author (resolved via email match to Jira User), and timestamp are preserved. Jira's comment visibility settings (project role, group) default to the Jira admin's project-level comment permissions; we document the default and recommend post-migration review of any restricted comments.

Demand Metric task attachments migrate as Jira Attachments on the corresponding issue. We extract files from the Demand Metric CSV export rows that reference attachment URLs, download each file, and upload to Jira via the Jira REST API attachment endpoint. Jira's attachment size limit (10 MB per file on Standard, 50 MB on Premium) is enforced; any file exceeding the limit is flagged in the reconciliation report for manual re-upload.

Demand Metric priority levels (Critical, High, Medium, Low, None) map to Jira Priority values (Highest, High, Medium, Low, Lowest). We apply this mapping as a configuration step in the transform script before Jira insertion. Any Demand Metric task with no priority set defaults to Jira Medium priority. The Jira Priority field must be available on the relevant issue types in the destination project's field configuration.

Demand Metric task statuses (To Do, In Progress, Done, On Hold) map to the corresponding statuses in the destination Jira project's workflow. We extract the status column from the Demand Metric CSV export and apply the Jira Status ID during the issue transform step. Jira workflows may use different status names or include additional transition states not present in Demand Metric — we flag these discrepancies in the scoping document and the customer's Jira admin selects the appropriate target status during configuration review.