Migrate from Husky to Jira

Husky Projects map directly to Jira Projects. The project name, description, status (active/completed), start date, and end date transfer as Project name, description, ProjectTypeKey (software/business), and start/end date in Jira's project settings. We flag any Husky project with archived status for the customer to decide whether to import as an active Jira project or skip. Jira project must be created before any issue import so that the Project key is available as the parent reference.

Husky Tasks map to Jira Issues using the customer's chosen default issue type (typically Story or Task). Parent-child task hierarchy in Husky maps to Jira's Epic-to-Story or Story-to-Sub-task relationship. We resolve the parent Issue key at migration time by matching the Husky parent task ID to the Jira issue created from that parent record. Sub-task is used when Jira's Subtask Issue Type is enabled and the depth warrants it. Assignee maps via email resolution to Jira User; unassigned tasks retain the assignee email in a custom field.

Husky Client records contain contact details, billing addresses, and tax settings. We map Clients to Jira Users (if the customer uses Jira for client-facing issue tracking) or to a custom Client custom field on issues (if clients are contacts rather than system users). Billing address and tax settings have no Jira equivalent and are flagged in the mapping document for the customer to handle in their accounting system. The customer chooses the Client strategy during scoping based on their use of Jira Service Management or Jira Software-only.

Husky Time Entries link a user, a project or task, and a duration or start/end time. We map these to Jira Worklog records on the corresponding Issue. Date-range scoping is applied to avoid mid-billing-period imports. Billable versus non-billable flags from Husky have no native Jira equivalent; we store the billable flag in a custom field on the Worklog or on the Issue itself. Time entry description migrates as the Worklog comment field.

Recurring Jobs in Husky store a frequency, interval, and last-run date. These rules do not transfer as active schedules in Jira because Jira has no native recurring issue creation feature beyond Jira Automation Rules (which require manual configuration). We export the job template name, description, recurrence metadata (frequency, interval, last-run date), and assigned project. The customer recreates recurrence logic as Jira Automation Rules or as a documented manual step in the post-migration checklist.

Husky allows per-account custom fields on Projects and Tasks. The field names and data types vary by tenant and change without notice. We enumerate all custom fields during discovery, generate a field map, and apply value transformations for picklist and date types. Jira custom fields are created in the target project before migration. Any custom fields added after discovery require a supplemental mapping pass; we recommend scheduling the migration window to minimize post-discovery configuration changes.

Husky Users carry role and permission data. Active users are mapped to Jira by email match. We flag any inactive or archived Husky users and defer to the customer on whether to import them as inactive Jira users or exclude them. Jira user provisioning (active license assignment) must complete before record import so that OwnerId references are satisfied on issue creation.

Finalized invoices in Husky are locked financial records and represent a financial record under the customer's accounting jurisdiction. We do not import finalized invoices to avoid duplicate financial exposure. We export invoice history as a reconciliation report (CSV) and advise the customer to handle financial record continuity through their accounting team or CPA.

If Husky stores file attachments on tasks (e.g., uploaded documents, images), we map these to Jira Issue Attachments. Attachment migration requires URL or file path resolution from the Husky export, upload to Jira's attachment endpoint, and linking to the correct issue key. Large attachment sets may require batch processing with retry logic on upload failures.

Husky tags stored as multi-value properties on tasks migrate to Jira Labels. Jira Labels are a flat string array, so multi-select tag values are comma-separated into the Jira label field. The customer confirms during scoping whether tag-based filtering is mission-critical and whether Labels provide sufficient filtering capability in Jira.