Migrate from Alian Hub to Jira

Alian Hub Projects map directly to Jira Projects using the platform's native Project ID as the Jira Project Key. We preserve the project name, description, and created date. Multiple Alian Hub projects map to separate Jira projects or to a single Jira project using Jira's issue type scheme (Epic, Story, Task) to partition work. The customer's project hierarchy intent is captured during scoping.

Tasks are the core work unit in both platforms. We map Task title, description (rich text), assignee (via user email lookup), due date, priority, and status label to Jira Issue fields. Custom status labels from Alian Hub are mapped to Jira Status values through the Status workflow configuration. Assignee resolution uses email as the dedupe key against Jira User accounts.

Alian Hub allows unlimited subtask nesting depth, while Jira enforces a three-level hierarchy cap (Epic > Story/Task > Sub-task). We detect all subtask nesting levels during scoping and flatten hierarchies deeper than three levels by converting mid-level items to standard issues at the appropriate level. Parent-child linkages are preserved as Jira Issue Links (Blocks/Blocked by or Related) to maintain traceability after flattening.

Alian Hub's Custom Field Manager definitions migrate to Jira Custom Fields with equivalent types: text fields to Jira Text Field, date fields to Jira Date Picker, dropdowns to Jira Select (single choice), multi-select to Jira Multi-select, number fields to Jira Number Field. We preserve the original custom field label and populate existing field values during import. Custom field context (project-level versus global) is mapped to Jira's field configuration scheme.

Alian Hub Timesheet entries map to Jira Issue Worklogs with the original duration, date, and notes preserved. The Jira user performing the migration must have the Log Work permission on the target project. We flag any time entries where the original Alian Hub user does not have a corresponding Jira User account; these are held in a reconciliation queue for the admin to provision accounts before the worklog phase resumes. JQL queries for time tracking reports should be validated post-migration.

Alian Hub user accounts migrate to Jira User accounts via email address resolution. Active Alian Hub users on paid tiers are provisioned as active Jira users; archived or deactivated accounts (from license downgrade below the Team tier user cap) are flagged during discovery and mapped to active Jira users or deactivated Jira accounts at the customer's direction. Jira Free tier enforces a 10-user limit and should be confirmed as the destination plan before user migration begins.

Alian Hub Channels and one-to-one chat messages have no direct Jira equivalent. We export channel metadata (channel name, member list, creation date) and message content from the Alian Hub database where available. At the customer's request, high-value discussion threads can be migrated as Jira Issue Comments attached to the relevant project or issue. The chat migration scope is agreed upon during scoping; standard scope documents chat history separately for the admin to archive or communicate to users.

File attachments linked to Alian Hub Tasks and Projects migrate as Jira Issue Attachments. Because Alian Hub stores files on the self-hosted server filesystem, we download files from the source and re-upload to Jira's cloud attachment storage or the Jira Data Center file store. Files exceeding Jira's 10MB per-attachment limit on Jira Cloud are flagged for the customer to store externally with a link reference in Jira. Bandwidth and volume planning for large attachment sets is included in the pre-migration infrastructure checklist.

Alian Hub Tags and Labels on Tasks and Projects map to Jira Labels. We preserve tag names and count exactly. If the customer's tag taxonomy is complex (more than 200 distinct tags or hierarchical tag groups), we recommend Jira Components or a custom Jira field instead of Labels during scoping, as Jira Labels are flat and not hierarchical.

Alian Hub's built-in AI assistant (available on paid tiers) has no direct Jira equivalent. Atlassian Intelligence on Jira Premium and Enterprise provides automated issue summaries and writing assistance, but it is not a migration target for Alian Hub AI-generated content. We document the existence of AI assistant usage during discovery and note it as a feature gap in the target platform. Customers relying heavily on AI assistant may evaluate Jira Premium or Enterprise for Atlassian Intelligence or a third-party AI integration post-migration.

Alian Hub's role-based permission structure (Admin Insight, User Permissions on paid tiers) maps to Jira Project Roles and Permission Schemes. We extract the Alian Hub role assignments during discovery and produce a written permission map that the Jira admin uses to configure Project Roles, Permission Schemes, and Issue Security Levels post-migration. Jira's permission model is more granular than Alian Hub's, so the admin makes the final mapping decision during configuration.