Migrate from Huly to Jira

Huly workspaces are the top-level container holding multiple spaces. Jira has no workspace layer above projects, so we map each Huly workspace to one or more Jira projects based on team boundaries, access control requirements, and the customer's preferred project structure. If the customer uses workspaces to represent business units (e.g., Serenity, Bebop, Falcon), we create separate Jira projects per workspace and map the Huly workspace name to the Jira project key and description. Projects are the first objects created because all downstream issues reference their parent project.

Huly's default 'Classic project' space type maps directly to a Jira project. The space configuration, including space type settings and member list, migrates to Jira project settings and project role memberships. If multiple Huly spaces belong to the same workspace and should share a Jira project, we consolidate them under a single project key and use Jira components to distinguish between the original spaces.

Huly's default Issue task type maps directly to Jira Issue. Assignee, priority, labels, due date, description (rich text), and custom fields migrate. The Huly process state (Backlog, Todo, In Progress, Done) maps to Jira status values (To Do, In Progress, Done) configured as a Jira Workflow. Huly's issue number is preserved in a custom field huly_issue_number__c for traceability.

Huly's GitHub Pull Request task type has distinct properties (PR number, merge state, review status) that have no Jira equivalent. We migrate PR metadata as structured custom fields on Jira issues: huly_pr_number__c (number), huly_pr_state__c (text: Open, Merged, Closed), huly_pr_reviewers__c (multi-user), and huly_merge_commit_sha__c (text). The actual GitHub commit graph, branch history, and CI status remain in GitHub and are referenced via links on the Jira issue. GitHub Integration for Jira or similar Atlassian Marketplace apps can re-link commits to migrated Jira issues post-migration.

Huly custom task types each carry their own set of process states. We enumerate all custom task types during discovery, map each type's state machine to a Jira Workflow and Status configuration, and assign each type to a Jira Issue Type (Bug, Story, Epic, Task) or a custom Issue Type if the destination Jira allows it. Per-type state mapping tables are built before any issue data migrates. Jira's Workflow schemes control which workflow applies to each Issue Type per project.

Huly wiki pages migrate to Confluence pages inside a designated Confluence space. Content blocks, embedded links, and collaboration metadata transfer. Huly's document hierarchy (folders, nested pages) maps to Confluence page hierarchy. Embedded images and file attachments migrate as Confluence attachments. Jira Software projects can be linked to Confluence spaces for requirements and documentation co-location. Jira does not have a native documentation feature; Confluence requires a separate license.

Huly Inbox messages and threaded discussions have no direct Jira or Confluence equivalent. We export message text, sender metadata, timestamps, and threading structure as structured JSON for the customer to review. Threading metadata (reply-to chains, reaction counts) is preserved in the export but cannot be rendered natively in Jira. Customers typically onboard this data into Atlassian Loom, Slack, or Microsoft Teams post-migration. Chat messages are flagged as non-migratable in the scope document with the export provided as a data archive.

Huly Milestones group issues toward a common goal or deadline. We map Milestones to Jira Versions (also called Releases), preserving the target date as the Version release date and the milestone description as the Version description. Issues associated with a milestone are linked via the Fix Version field in Jira. Version-level burndown and release reports in Jira provide equivalent progress tracking.

Huly Action Items are tasks captured within conversations, carrying assignee, due date, and completion status. We migrate Action Items as Jira Sub-tasks linked to their parent Jira Issue. The action item text becomes the sub-task summary, assignee maps directly, and completion status maps to the Done status in the sub-task workflow. Action items without a clear parent issue are escalated to the customer's PM for manual parent assignment before migration.

Huly labels with color metadata migrate to Jira Labels. Jira labels are single-word tags stored as a multi-select list on each issue. We preserve the Huly label name and color metadata in a custom field huly_label_color__c for reference. Jira labels are not colored natively; the color field is informational only.

Files attached to issues, wiki pages, or chat messages migrate as Jira attachments on the corresponding issue or Confluence page. Huly cloud storage limits apply to attachments only (not to Huly objects); Jira Cloud attachments are subject to Jira site storage limits. We flag attachment-heavy records during scoping and recommend sizing the Jira site storage plan appropriately. Jira Cloud individual attachment size limit is 10 MB on free plans and 256 MB on paid plans; Huly attachment sizes are preserved during transfer subject to these limits.

Huly workspace members and their roles (owner, member) map to Jira users and project role memberships. Email addresses and display names resolve to Jira user accounts. Active vs. archived status is preserved. Huly has no separate 'groups' object; Jira groups are created during migration based on Huly team or workspace membership patterns. Jira requires each migrating user to have an active Jira account or to be provisioned by an admin before record migration.