Migrate from CAMMS to Jira

CAMMS Projects (including sub-projects and work packages) map to Jira Projects. We extract full project hierarchies and map the top-level CAMMS Project to one Jira Project per portfolio or programme. Sub-projects become Jira Projects within the same Jira organisation or, where the destination org uses a single large project, become Jira Epics or Folders depending on the team's hierarchy convention agreed during scoping.

CAMMS Tasks map to Jira Issues (Story or Task issue type). Parent-child task relationships in CAMMS map to Epic-Story-Subtask or Story-Subtask nesting in Jira depending on the depth of the original hierarchy. Task status, assignees, start/end dates, and effort estimates migrate to Jira Issue fields. Task-level attachments require the parallel file export pipeline.

CAMMS Risks map to Jira Issues using a Risk-dedicated Issue Type (we recommend a custom Issue Type called Risk created in the destination Jira Project). Risk likelihood and impact scores migrate to custom Number fields; risk owner migrates to the Jira Assignee field; mitigation plan migrates to the Issue Description or a linked child Issue. CAMMS risk-to-issue associations require explicit cross-object mapping during the transform phase.

CAMMS Issues (distinct from Risks in CAMMS) map to Jira Issues using the standard Issue issue type. Issue status workflow, priority, and linked project context migrate directly. Issue-to-risk associations in CAMMS do not have a direct Jira equivalent; we create these as Jira linked issues (Blocks/Is blocked by relationship) or as labels during migration.

CAMMS Budget entries have no native Jira equivalent. We map budget lines to Jira Issue custom fields: Planned Cost becomes a Number field, Actual Cost becomes a Number field, and Variance is computed or stored as a read-only Formula field if Jira Premium is used. Cost code schemas and period structures are mapped to custom Select or Text fields. Budget roll-up to portfolio level requires Jira Portfolio or third-party apps post-migration.

CAMMS Meeting records (agenda, attendees, minutes) are decomposed in Jira. The meeting title and key decisions become a Jira Issue; the full agenda and minutes become Issue Description; attendees are mentioned in a first Comment or linked via Labels. Meeting attachments (documents, PDFs) are extracted via the file export pipeline and re-attached to the corresponding Jira Issue.

Documents attached to CAMMS Projects, Tasks, Risks, or Meetings are exported as files in their original format via the parallel attachment pipeline. We recreate the original folder hierarchy in a staging directory and re-link each file to its parent Jira Issue during import using the Jira REST API attachment endpoint. File size limits (75MB per attachment for Jira Cloud, 10MB for Jira Data Center) apply and are communicated during scoping.

CAMMS user accounts and resource allocations are extracted and matched to Jira Users by email address. We resolve role-based access assignments (CAMMS project roles, approval authorities) to Jira Project Roles (Administrators, Developers, Users) or Group memberships depending on the destination permission model. Inactive CAMMS users map to Inactive Jira users if historical attribution is required.

CAMMS custom fields are not governed by a stable export schema and have no documented API. We request a written inventory of all active CAMMS custom fields (name, data type, current values) from the customer before scoping. We then configure equivalent Jira custom fields (Text, Number, Select, Multi-Select, Date, User Picker) during Jira schema design. Fields with no Jira equivalent are flagged as manual carry-over items in the handoff documentation.

CAMMS custom approval chains and stage-gate workflows do not migrate to Jira as code. Jira does not have a native approval workflow in Jira Software; approvals typically require Jira Automation for DevOps-style chains or a third-party app like Tempo Timesheets for time-based approvals. We deliver a written inventory of every active CAMMS approval workflow (trigger, approver role, conditions, escalation path) for the customer's Jira admin to rebuild post-migration.