Migrate from Trigger to Jira

Trigger Clients map to Jira Projects (the client workspace) plus a nominated Project Contact person stored as a Jira user or as a Contact in Jira's native contact model if the Jira Service Management integration is active. We export client name, email, billing address, and currency setting and map currency to the Jira Project's default billing currency field. Clients without a billing address are flagged before import since Jira Projects have no optional-address equivalent — these land as incomplete and require manual completion post-migration.

Trigger Projects map directly to Jira Projects. The Trigger project manager assignment maps to the Jira Project Lead field. Start date and due date become the Jira Project's start and end dates. The hourly budget cap from Trigger becomes a custom field trigger_project_budget_hours__c on the Jira Project since Jira does not have a native budget field. The client association resolves to the Jira Project key as the shared reference field.

Trigger Tasks map to Jira Issues with Issuetype set to Task. The Trigger assignee maps to Jira's Assignee field resolved by email against the Jira User directory. Priority maps from Trigger's priority values (Low, Medium, High, Urgent) to Jira Priority field values. Due date maps directly. Estimated hours map to the Jira Original Estimate field. The task description from Trigger migrates to the Jira Description field, preserving line breaks and basic formatting.

Trigger Subtasks nested under parent Tasks require flattening during export. We identify subtasks by their parent-task reference, export the full hierarchy, then set Jira Issuetype to Sub-task on the child records and link them to the parent Jira Issue via the Parent Link field. This requires Jira's Sub-tasks feature to be enabled per project before import. Subtask-specific fields (if any exist beyond the inherited parent fields) map to Jira custom fields created before ingestion.

Trigger Time Entries linked to tasks map to Jira Worklog records on the corresponding Jira Issue. The time spENt field maps from Trigger's duration value. The date of the time entry maps to the Worklog's started date. The billable flag maps to a custom field trigger_billable__c on the Worklog. The user who logged time is resolved by email match against Jira Users. Jira's Bulk API 2.0 is used for large worklog imports (over 5,000 records) with chunking at 1,000 records per batch. Non-billable time entries also migrate as Worklogs with the billable flag cleared.

Trigger Invoices do not have discrete line items — invoice totals are computed from billable time entries. We reconstruct invoice records by first importing all billable time entries as Jira Worklogs (mapping_type row above), then creating Jira Issues with Issuetype = Task and a custom field trigger_invoice_id__c referencing the original Trigger Invoice ID. The invoice total and status (draft, sent, paid, overdue) are stored as custom fields on this Jira Issue, and the worklog-linked time entries carry the invoice context in their trigger_invoice_id__c field. Customers should confirm whether Jira's ecosystem of invoice apps (Invoice Ninja, Zoho Invoice) is in scope as a parallel migration step.

Trigger User records map to Jira User accounts by email address as the dedupe key. Trigger's admin or member role maps to Jira's Global Permissions (Admin or User) set manually post-provisioning since Jira permissions are permission scheme-based rather than simple role flags. The hourly rate from Trigger maps to a custom field trigger_hourly_rate__c on the Jira User record. Jira Users without a matching Trigger User are not created automatically — the customer's Jira admin provisions any new team members post-migration.

Trigger project-level custom fields require Jira custom fields to be pre-created before record import. Jira field types must match Trigger field types: text fields map to Jira Text Field (single-line), long-text fields map to Jira Text Field (multi-line), number fields map to Jira Number Field, and date fields map to Jira Date Picker. We export the Trigger custom field definition alongside values and create equivalent Jira custom fields via the Jira REST API before data ingestion. Trigger custom fields without a direct Jira type equivalent are mapped to Jira Text Field (single-line) as the closest fallback.

Trigger task-level custom fields (for example, a custom Priority Override or Client PO Number) map to Jira Issue-level custom fields. Jira's custom field context must be scoped to the relevant project or issue type before import. If a Trigger custom field uses a multi-select or checkbox pattern, we map to Jira's Labels or Multi-select custom field depending on the value count. Validation rules on Jira custom fields must be relaxed or removed during import to prevent null-value rejections.

Trigger locked or archived projects require explicit flagging during export. Jira has no direct equivalent to a locked project state — archived Jira projects are hidden but not locked. We export locked Trigger projects as standard Jira Projects with a custom field trigger_record_status__c set to Archived or Locked, and we configure Jira's project sharing settings to restrict access to these records. Customers should confirm whether archived projects need to be migrated at all or whether they can remain in Trigger as a read-only archive.

Trigger project templates define a reusable project structure with pre-populated task lists and default values. Jira's project templates work differently — Jira uses project types and blueprints rather than saved template projects. We do not migrate project templates as code. We deliver a written inventory of every Trigger project template listing its tasks, default assignees, estimated hours, and recurring structure so that the customer's Jira admin can recreate equivalent Jira project templates using Jira's built-in template system or the Structure for Jira app for more complex template requirements.

Trigger task attachments are included in the CSV export as file path references. Jira supports file attachments up to 256MB per file via the REST API. We attempt to re-upload attachments to the corresponding Jira Issue after the issue record is created, using the Jira Attachment API. Attachments exceeding Jira's size limit are flagged for manual re-upload. If Trigger attachments are stored outside the platform (for example, in a linked Google Drive or Dropbox folder), we note the external URL in a Jira comment on the issue rather than attempting an internal upload.