Migrate from Output Time to Jira

Output Time Projects map directly to Jira Projects. We extract project name, description, status (active/archived), start date, and end date. The Jira Project key is derived from the Output Time project name (first letters or acronym if available). Project-level custom fields migrate as Jira Project Properties (key-value) or as custom fields on a configured Issue Type if the project has a shared custom field schema.

Output Time Tasks map to Jira Issues. The task name becomes Issue Summary, description maps to Issue Description (with HTML preserved), due date maps to Due Date, priority maps to Priority (Critical/High/Medium/Low), and status maps to Status with a pre-migration status mapping document. Assignee resolves by email match against Jira User records. Parent project link is preserved via the Jira Project field.

Output Time Subtasks map to Jira Sub-task Issues within the same Project. The Sub-task issue type must be enabled in the Jira Project before migration. Parent-child relationships between subtask and task migrate as Jira Issue Links (Parent) with link type Blocks or is Sub-task of. We preserve the subtask hierarchy ordering based on Output Time's sequence or creation order field.

Output Time Milestones map to Jira Fix Versions. Milestone name becomes Version Name, target date becomes Release Date, and description maps to Version Description. If the Output Time milestone applies to a specific project, we scope the Fix Version to that Jira Project. If milestones span multiple projects, we create a global version and document the cross-project association for manual assignment in Jira.

Output Time Time Entries map to Jira Worklogs on the corresponding Issue. We map entry date to Worklog started (ISO 8601), duration in seconds to Time Spent (Jira format: 1h 30m), billable flag to a custom field jira_billable__c (boolean), and notes to Worklog Comment. Author resolves by email match against Jira User. Jira Free plan does not include time tracking; Standard plan or above is required for worklog functionality.

Output Time Users map to Jira Users by email address. We extract display name, email, and role (Admin/Member). Inactive users in Output Time are flagged and mapped to Jira Users with inactive status or documented for the admin to deactivate post-migration. Jira requires active accounts for assignee fields; any unmapped user goes to a reconciliation queue.

Output Time Clients are contact records associated with projects. Jira does not have a native client object. We map Clients to either a Jira Project Role (e.g., Client) with email addresses added as default users, or to a custom field of type User Picker (single user) or Multi-user picker depending on whether clients represent organizations or individuals. The customer chooses the mapping during scoping.

Output Time custom fields (key-value pairs) map to Jira custom fields of equivalent type: text values to Text Field, numeric values to Number Field, dates to Date Picker, true/false to Checkbox, and multi-select to Labels or Multi-select. Jira requires custom fields to be configured with Issue Type Context before they appear on issues; we handle context configuration as part of the schema design phase. Custom fields with unsupported value types default to Text Field.

Output Time Tags migrate to Jira Labels. Tags are stored as string arrays and become comma-separated Label values on the corresponding Issue. Jira Labels are shared across the instance, so tag collisions (identical tags from different Output Time projects) are preserved as a single Jira label. If the customer requires project-scoped tags, we document the alternative as a custom field with label picker.

Output Time file attachments on tasks and projects are not accessible via any documented API endpoint. We inventory all attachments at the start of the migration, recording original filenames, attached-to-record references, and storage locations. We provide a manual re-upload checklist so the customer's team can restore attachments in Jira post-migration. This limitation is documented in the pre-migration scope document.