Migrate from Projectworks to Jira

Projectworks Projects map to Jira Projects as the top-level container. Each Jira Project gets a Project Key (up to 10 uppercase characters) derived from the Projectworks project name or code. Project status (Active, On Hold, Completed) maps to Jira Project status. Project budget and planned revenue do not migrate because Jira has no financial fields; these are exported to a Budgets CSV alongside invoice data for accounting re-entry.

Projectworks Tasks nested under Projects map to Jira Issues (Story, Task, or Bug) within the corresponding Jira Project. Task status, priority, description, assignee, and due date migrate directly. Jira Issue Types (Story, Task, Bug, Sub-task) are selected during scoping based on the customer's existing Jira project type scheme. Task custom fields map to Jira custom fields of equivalent type (text, date, select, multi-select).

Projectworks Milestones (named delivery checkpoints with due dates and completion status) map to Jira Versions. Milestone name becomes Version name, due date becomes Release Date, and completed status maps to Jira Version status (Released or Unreleased). Jira Versions support release notes and can be linked to Issues via Fix Version, making them the closest structural equivalent to Projectworks Milestones.

Projectworks Time Entries (duration only, no start/end clock times) map to Jira Work Logs with hours transferred directly. The Jira WorklogRecorded event captures the duration but loses any implied start/end timestamp. If consultants used Memtime or a separate clock-time tool alongside Projectworks, those records are outside the scope. Jira's Bulk API handles high-volume work log imports in batches of 1,000 records per request with rate-limit backoff. High-volume exports (over 200,000 time entries) require date-range chunking by month or quarter.

Projectworks People records (with capacity, hourly rates, and utilization settings) map to Jira User accounts by email address. Jira User records do not natively store billing rates or capacity percentages; these are exported as a CSV alongside the People export for re-entry in the customer's billing tool. Jira groups are created to represent Projectworks resource pools, and users are added to relevant groups during provisioning. Owner and Project Manager roles map to Jira Project Lead and Component Lead fields.

Projectworks Company records have no native Jira equivalent. Jira does not include an Accounts or Companies object. We export Company records as a CSV keyed by Company ID, then configure a Jira custom field (Single Select User Picker or Text field depending on Jira plan) on the relevant Issue screens to store the client name. The customer chooses whether to store the Company as a custom field or as Labels during scoping. This is a configuration-level mapping, not a direct object migration.

Projectworks Contact records (separate from Company) similarly have no Jira native equivalent. We export Contacts as a CSV with Company linkage preserved. In Jira, contacts are either stored as a custom text field on the Issue, linked via Labels, or managed through a third-party app (Jira Service Management, Atlassian Intelligence for cross-referencing). We document the chosen strategy during scoping and implement it as a custom field configuration.

Projectworks Invoices (with fixed-fee and hourly line items, status, and client linkage) have no Jira equivalent. Jira has no billing or invoicing module. We export all Invoice records as a structured CSV with invoice number, client, date, line items, amounts, and status. The customer re-enters invoices in their accounting tool (Xero, QuickBooks, or another platform) post-migration. We flag the Xero sync settings during discovery to prevent duplicate invoice pushes if the customer continues using Xero for accounting.

Projectworks Expenses (reimbursable and non-reimbursable, linked to Projects and People) have no Jira equivalent. Jira work logs track time, not costs. We export all Expense records as a CSV with project linkage, expense category, amount, reimbursement status, and approval status. Reimbursable expenses that were pushed to Xero as bills are flagged during discovery; the Xero export settings do not transfer and must be reconfigured in the destination accounting tool. Financial exports require the customer's admin to confirm the target accounting system before extraction.

Projectworks Budgets (planned vs. actual revenue and costs at the Project level) have no Jira equivalent. Jira's data model does not include financial budget fields. We export budget line items as a CSV with planned amounts, actual amounts, variance, and project linkage. This export supports the customer's financial re-entry in their accounting system. Jira's native reporting shows planned vs. logged hours, not planned vs. actual revenue, so budget variance analysis must remain in the accounting layer.

Projectworks custom fields on Projects, Tasks, People, Companies, Contacts, Time Entries, Expenses, and Invoices are enumerated during discovery. We map each to a Jira custom field of matching type (text, number, date, single select, multi-select, user picker). Jira Cloud Standard plan limits custom fields to 30 per issue; Premium allows up to 100. Fields that exceed the Jira plan limit or cannot be typed equivalently are flagged and documented for the customer's admin to resolve in Jira project settings.

Projectworks custom Reporting Views are defined in a proprietary undocumented schema and cannot be migrated. We extract the underlying data so customers can rebuild reports in Jira (native dashboards, Jira Issues views, or Atlassian Analytics). We document which reporting views were configured in Projectworks, the data sources they referenced, and the recommended Jira equivalents (Jira Dashboard Gadgets, eazyBI, or Atlassian Analytics). Custom report configurations do not transfer automatically.