Migrate from WeTrack to Jira

WeTrack Projects map directly to Jira Projects. We preserve the project name, description, start and end dates, and status. WeTrack's RAG-overall indicator maps to a Jira custom priority field or is noted in the project description field. Project key prefixes are assigned during Jira project creation based on the customer's naming convention. Projects are created before any child Issues to satisfy Jira's parent-project dependency.

WeTrack Tasks map to Jira Issues with an Issue Type of Story or Task. The mapping decision is made during scoping based on whether the task represents deliverable work (Story) or a discrete action item (Task). WeTrack's due date, start date, and estimated duration map to Jira's Due Date, Start Date, and Original Estimate fields. Assignee maps by email match to Jira User.

WeTrack Subtasks map to Jira Sub-task Issues linked to their parent Task or Story via the Jira Parent Link field. WeTrack's auto-sync date behavior is noted as a manual post-migration configuration in Jira: the customer's admin sets Due Date on the parent issue and updates subtask dates in a follow-up reconciliation pass. Subtask order is preserved through the Jira reordering API after migration.

WeTrack Risk Registers with Inherent Likelihood and Impact values map to Jira Issues using a custom Risk Issue Type. If the customer does not have a Risk issue type configured, we map RAG status, likelihood value, impact value, and risk owner to custom fields on the standard Issue object: wt_likelihood__c (number), wt_impact__c (number), wt_risk_owner__c (user), and wt_risk_status__c (picklist with RAG values). WeTrack's inherent risk score calculation is preserved as a custom formula field or computed post-migration.

WeTrack RAG status values (Red, Amber, Green, Grey) have no native Jira equivalent. We create a custom picklist field wt_rag_status__c on the Issue object with the four WeTrack values preserved. For customers who prefer to use Jira's native Priority field, we create a mapping table (Red > Highest, Amber > High, Green > Medium, Grey > Low) and document it in the migration handoff. The cascade behavior from parent to subtask in WeTrack is not automated in Jira and requires a post-migration workflow rule or manual process update.

WeTrack Job Categories restrict valid assignment options to prevent data entry errors. We map active Job Category values to Jira Labels on Issues, allowing filtering by category in JQL (labels in ('Event Operations', 'Venue Management')). If the customer prefers a more structured approach, we map Job Categories to Jira Components with the relevant project. Inactive or orphaned categories are flagged in the migration report for manual reassignment.

WeTrack's Sustainability module tracks ESG indicators per project (carbon metrics, waste reduction, accessibility compliance). Jira has no native ESG object. We create a Jira custom object ESG_Metric__c with fields for metric_name__c, metric_value__c, unit__c, reporting_period__c, and a lookup to the Jira Project. If the customer has fewer than 10 ESG metric types, we alternatively use custom fields on the Jira Project object to avoid schema complexity.

WeTrack Incident Reports map to Jira Issues. The mapping uses Task type for operational incidents (venue safety, scheduling conflicts) and Bug type for technical incidents (system failures, data integrity issues). Incident severity, reported-by user, and resolution notes migrate to custom fields: wt_incident_severity__c, wt_incident_reporter__c, and wt_incident_resolution__c. Incident date is preserved in the Issue Created Date or a custom wt_incident_date__c field.

WeTrack file attachments (event schedules, risk documents, sustainability reports) migrate to Jira Issue Attachments. File metadata (name, type, size, upload date) is preserved. Actual file content migrates directly if the Jira instance has attachment storage enabled; Jira Cloud has a 10MB per-file limit and 1GB storage at the free tier, which may require the customer to upgrade for large attachment volumes.

WeTrack Users and Task Owners map to Jira Users by email address. We extract all distinct user references from WeTrack data and match them against the Jira destination instance. Users without an existing Jira account go into a reconciliation queue for the customer's admin to provision before record import resumes. WeTrack inactive or deactivated users are flagged and can be set as Jira inactive users with the historical assignments preserved.

WeTrack custom fields on Projects and Tasks map to Jira custom fields of equivalent type (text, number, date, picklist). WeTrack multi-select values map to Jira label-style custom fields. Custom field schema is pre-deployed into the Jira destination before data migration begins, using Jira's Bulk Custom Field Creation API. Fields that cannot be mapped (due to type incompatibility or Jira field limits) are flagged in the handoff report for manual re-entry.

WeTrack Event and Venue records represent specific events (Wimbledon, Expo 2020) and their physical locations. These map to Jira Project Description fields supplemented with custom fields: wt_event_type__c, wt_venue_name__c, wt_venue_location__c, and wt_event_date__c. If the customer manages recurring events, each event becomes a Jira Project linked to a parent Venue Project via Jira's Project Links feature.