Migrate from Project Risk Manager to Jira

Project Risk Manager Risk records map to Jira Issues created under a dedicated risk management project using a custom Risk issue type. The Risk title maps to Jira Summary, description maps to Description, probability maps to a custom Likelihood dropdown field (Rare/Unlikely/Possible/Likely/Almost Certain), impact maps to a custom Impact dropdown field (Insignificant/Minor/Moderate/Significant/Severe), and status maps to the Jira workflow state on the Risk issue type. We compute a Risk Score field (Likelihood x Impact) as a read-only calculated field or formula during import. If the customer installs a third-party risk management app (SoftComply Risk Manager Plus, Risk Management for Jira), we configure the app's specific field schema during the Jira configuration phase.

Project Risk Manager Mitigation Actions linked to a parent Risk map to Jira Tasks or Sub-tasks linked via the is mitigated by or custom link type to the parent Risk issue. The action text becomes the Task summary, assigned owner maps to Jira Assignee (resolved via owner email lookup), due date maps to Due Date, and status maps to the Task workflow state. Sub-tasks are used when the mitigation action itself requires decomposition into steps; parent Task holds the top-level action. If the destination Jira project uses a different link type name, we configure the link type during schema setup and apply it during import.

Project Risk Manager Project records map to Jira Projects. The project name becomes the Jira Project name, and project key is derived from the name's acronym or a customer-specified prefix. If the customer uses Jira's company-managed project template, we configure the project with the Risk issue type as the default; if team-managed, we set the issue type scheme accordingly. Multiple Project Risk Manager Projects map to separate Jira Projects unless the customer consolidates into a single risk project with Components.

Project Risk Manager Risk Categories (e.g., Technical, Financial, Operational, Compliance) are stored as picklist values. We map these to a Jira custom single-select field called Risk Category applied to the Risk issue type. Alternatively, if the customer prefers Jira Components, we create one Component per category and link Risks to their category Component. The customer chooses the strategy during scoping. Category values are created as options in the custom field before record import begins.

Project Risk Manager Risk Owners are extracted by name and email. We match by email against the Jira destination site's User directory. Unmatched owners are flagged in a reconciliation report and held from import until the customer's Jira admin provisions the missing Users. Inactive Users can be imported as Assignee if the customer wants historical owner assignment preserved; active Users are used if the owner will continue managing the risk in Jira.

Project Risk Manager Status values (Open, Mitigated, Closed, Accepted) map to Jira workflow states on the Risk issue type. We configure a custom Risk workflow during schema setup with these states and map the status values during import. If the customer uses a third-party risk management app, we map to the app's workflow states instead. The workflow state transition rules are defined per the customer's risk management process and do not migrate from Project Risk Manager's opinionated workflow.

File attachments linked to Project Risk Manager Risks are extracted and re-uploaded to the corresponding Jira Issue as attachments. We handle common file types (PDF, DOCX, XLSX, PNG, JPG) and preserve the original filename and upload timestamp. Very large files (over 10MB per Jira's limit) are flagged for the customer to host externally and link via URL. Jira attachments require the Jira user performing the import to have the Attach Files global permission.

Project Risk Manager Comments on Risks are imported as Jira Comments on the corresponding Risk issue. Each comment preserves the author name, timestamp, and body text. Jira Comments do not support rich formatting from Project Risk Manager, so plain text is used. If Project Risk Manager stores threaded discussions, we import them as sequential comments ordered by timestamp.

If the customer can generate a bulk CSV export from Project Risk Manager's admin panel, we parse it and import via Jira's CSV import feature (for team-managed projects) or the Jira REST API (for company-managed projects). The import requires a pre-configured schema (custom fields, issue type, project) matching the export columns. We validate field type compatibility (date formats, user email formats, picklist values) before running the import.

Project Risk Manager may have tier-specific custom fields not visible in a standard export. We ask the customer to run a trial export from their account settings and compare it against the in-app view to identify any fields missing from the export. Any discovered custom fields are added to the Jira schema as custom fields on the Risk issue type before record import. If a field cannot be exported from Project Risk Manager, we document it in the scope and the customer decides whether to repopulate manually post-migration or use a different data capture approach in Jira.