Migrate from Workamajig to Jira

Workamajig Campaigns aggregate multiple Projects under a single budget and P&L reporting boundary. Jira has no native Campaign object. We map Campaigns to Jira Projects (if each Campaign corresponds to a distinct client or engagement) or to Epics within a single Jira Project (if the customer wants all work under one project and uses Epics to segment by client or initiative). The mapping choice is confirmed during scoping based on the customer's Jira project strategy. Campaign-level budget and estimate fields migrate to Jira custom fields on the Epic or Project.

Workamajig Projects map directly to Jira Projects. We export via the projects module respecting the 20 req/min rate limit by chunking into staggered batches of 20 records with backoff delays. Project-level custom fields map to Jira Project properties or to custom fields on a representative Issue Type. The project's status, start date, end date, and budget fields migrate to custom fields on the Jira Project.

Workamajig Tasks nested under Projects map to Jira Issues (Story, Task, or Bug) within the corresponding Jira Project. Task hierarchy (parent task, subtasks) migrates as Jira subtask links or as hierarchical Story-Subtask relationships. Predecessors, date ranges, hourly allocations, and completion statuses map to Jira fields or custom fields. We flag cross-project dependencies at migration time so the customer can re-establish links in Jira after rebuild.

Workamajig Deliverables represent reviewable outputs tied to approval workflows with stakeholder reviewer assignments and approval statuses. Jira has no native approval workflow or deliverable object. We export Deliverable records with their approval statuses and reviewer assignments into a Jira custom field set. The customer chooses whether Deliverables become Jira Issues (for tracked outputs) or Label-tagged Issues (for lighter-weight reference). Approval chain logic requires manual rebuild in Jira as a separate workflow or Jira Automation rule.

Workamajig Time Entries (linked to Projects, Tasks, and Employees with billable/non-billable flags and hourly rates) map to Jira Issue Worklogs with the time spent, start date, and author preserved. Billable/non-billable flags and hourly rates migrate to Jira custom fields on the Worklog since Jira's native worklog does not expose a billable flag. Time-entry dates become the Jira worklog start date for timeline ordering.

Workamajig supports custom fields on Projects, Campaigns, Companies, Contacts, Employees, and Order lines. We extract the full custom field schema (field types, required flags, choice options) and map each to an equivalent Jira custom field. Radio button and dropdown choices in Workamajig map to Jira select or radio button fields; checkbox groups map to Jira multi-select. We pre-create the Jira custom field schema in a Sandbox before production migration.

Workamajig Companies (with contact roles, relationship links, and custom property values) map to Jira Organizations if the customer enables Jira Service Management, or to a Project-level Company custom field if Jira Software is the destination. We export all Company records with their associated contact roles and custom field values. The mapping is confirmed during scoping based on the Jira edition and the customer's intent for client-facing versus internal project tracking.

Workamajig Contacts are stored in the CRM module with Companies, roles, and custom fields. Jira Software does not have a native Contact object; contacts can only exist as Jira Users or as Issue Assignee/Reporter fields. We map active Workamajig Contacts to Jira Users where the contact has a Jira license, and hold the remaining contacts for admin decision on whether to provision Jira accounts or store in a separate CRM. Contact-level custom fields require Jira user property configuration or external storage.

Workamajig Invoices and billing worksheets (line items, payment status, linked transaction records) have no direct Jira equivalent. Jira Software has no invoice, AR, or billing module. We export invoice metadata as JSON for reference and advise the customer to manage billing in a dedicated ERP (QuickBooks, NetSuite, Harvest) post-migration. Invoice total and outstanding balance can be stored as read-only custom fields on the Jira Project if the customer requests it.

Workamajig Purchase Orders track vendor expenses against Projects with PO headers, line items, and vendor associations. Fiscal and expense-account mappings have no Jira equivalent. We export PO data as JSON reference and note that Jira is not a procurement or accounts payable tool. Vendor names can be stored as a custom field on Jira Issues if expense tracking is needed in Jira.

Workamajig Activities capture engagement history on Companies and Contacts (GET-only via API at 50 req/min). Jira Issues have a native Comment model and an Issue History view. We export available activity records as Jira Comments on the linked Issue, preserving the original timestamp, author, and activity type. Automation rules or activity-triggered workflows in Workamajig do not migrate and are documented separately.