Migrate from ProWorkflow to Jira

ProWorkflow Projects map 1:1 to Jira Projects. We extract Project name, description, status, start date, due date, and custom fields. Jira Project key (e.g., PROJ) must be reserved before migration. If the customer is migrating into an existing Jira org with pre-existing projects, we namespace the imported Projects with a prefix. Project template configuration in Jira does not carry ProWorkflow's milestone/task pre-fill; we deliver a written inventory of each Project's task hierarchy for manual template creation.

ProWorkflow Tasks map to Jira Issues. Task name becomes Issue Summary, Task description becomes Issue Description, due date becomes Due Date, assignee resolves via email to Jira User. Task hierarchy (subtasks) maps to Jira sub-tasks with the parent Issue linked. Task status in ProWorkflow (Not Started, In Progress, Completed) maps to Jira status categories (To Do, In Progress, Done) but requires a valid Jira Status to be present in the target project's workflow before import — we validate this before migration to avoid JCMA error 149.

ProWorkflow Milestones carry a name and target date. We map milestones with a Sprint structure if the destination Jira Project uses a Scrum board. The milestone date becomes the Sprint end date or a due date on a linked issue. Milestones that have an associated invoice flag in ProWorkflow (milestone converted to invoice in the financial suite) carry a custom field pw_milestone_invoiced__c to alert the customer that the invoice record does not migrate to Jira and must be recreated or archived separately.

ProWorkflow Items carry Time Allocated, Time Spent, Manual Completion %, and Margin % fields. Jira has no native financial Item concept. We carry these values as Jira custom number and percentage fields on the mapped Issue: pw_time_allocated__c, pw_time_spent__c, pw_manual_completion_pct__c, pw_margin_pct__c. Note that Nexus introduced changes to how these fields calculate — we flag any Item with non-default financial values and surface the discrepancy before migration so the customer can decide whether to accept the Nexus-calculated values. Financial reporting on these fields must be built in Jira's reporting module or a third-party add-on like Tempo Timesheets.

ProWorkflow Clients map to Jira Organizations (available from Jira Premium and Enterprise; not available on Free or Standard). We extract Client name, primary contact, phone, and email. If the destination Jira is on Free or Standard tier where Organizations are not available, Clients map to Project-level Description text or a custom text field. We flag this limitation during scoping so the customer can upgrade Jira if client-level organization tracking is required.

ProWorkflow Contractors are free and unlimited in ProWorkflow but consume Jira seats on Cloud. We extract all Contractor user records, separate them from Staff Users, and flag which records will incur billing in Jira. The customer's Jira admin provisions contractor accounts before migration, or contractors are migrated as inactive Jira users and activated as needed. We flag this as a cost-impact item in the scoping document.

ProWorkflow Staff Users map 1:1 to Jira Users by email address. User name, email, and role migrate. Jira group membership is configured post-migration based on the customer's desired permission model. Any ProWorkflow user without a matching Jira account goes to a reconciliation queue for admin provisioning before record migration resumes.

ProWorkflow Time Entries (tied to Tasks or Items) map to Jira Issue Worklogs. We extract Hours, Description, Date, and Billable flag. The Billable flag maps to a custom Jira field pw_billable__c because Jira's native worklog has no billable indicator. Worklog author resolves by email to Jira User. Jira's worklog history is preserved on the Issue timeline. If the destination uses Tempo Timesheets, we coordinate the worklog import format with the Tempo API.

ProWorkflow Invoices are generated from Items and Milestones via the financial suite. Jira has no native invoicing or billing feature. We do not migrate Invoices as Jira records. We deliver a written inventory of every Invoice with client name, amount, date, status, and line items, mapped from ProWorkflow's export. The customer's admin rebuilds invoicing in a dedicated tool (QuickBooks, FreshBooks, or a Jira-compatible billing add-on) post-migration.

ProWorkflow Custom Fields (dropdown-based, Advanced plan only) map to Jira Custom Fields of equivalent type. Dropdown options migrate as Jira custom drop-down options. Multi-select or checkbox-style ProWorkflow custom fields map to Jira multi-select or checkbox fields. Custom fields are created in the destination Jira project before data migration begins. ProWorkflow custom field definitions and selected values carry over as structured key-value pairs.

ProWorkflow Custom Forms are raw HTML injected into a Project page and are available only on Advanced plan. We extract the HTML as a plain-text blob and place it in the Jira Issue Description field. The form structure and any conditional rendering cannot be preserved. We flag all Projects with Custom Form content before migration and alert the customer that form functionality will not carry over to Jira. No form builder equivalent exists in Jira or Jira Software — the customer rebuilds form logic in Jira Service Management if needed.

ProWorkflow Project Templates define repeatable structures including tasks, milestones, and pre-filled financial fields for recurring client work. Jira has its own project template system, but the structures are incompatible — a ProWorkflow template's milestone-and-item hierarchy does not map automatically to a Jira project template. We deliver a written template inventory listing every template's task hierarchy, milestone sequence, and pre-set financial fields. The customer's Jira admin creates matching Jira project templates manually post-migration.