Migrate from Hive to Jira

Hive Projects map directly to Jira Projects. Each Hive project becomes a Jira project with the same name, description, and start/end dates preserved. Jira project type (company-managed or team-managed) is determined during scoping based on the customer's Agile methodology preference. Project-level visibility (public/private) maps to Jira's project sharing settings and permission scheme.

Hive Tasks map to Jira Issues. We map Task priority to Jira Priority (Highest, High, Medium, Low, Lowest). Task assignees resolve to Jira User accounts by email match. Due date and start date map to Due Date and Start Date on the Jira Issue. Hive's task description (rich text) migrates as the Jira Issue Description field. Sub-tasks within a Hive task map to Jira sub-task Issues linked via the Parent Link field.

Hive Actions nested under a Task map to Jira sub-task Issues. The parent-child relationship is preserved by setting the Jira parent link to the mapped Issue. Jira allows only one level of sub-task nesting, so any deeply nested Hive action hierarchy is flattened into a chain of sub-tasks linked to the root parent Issue.

Hive Actions that are not attached to a specific project (standalone quick-capture items) are grouped by assignee and mapped to Jira Issues within a designated catch-all project. We create a dedicated Jira project or use an existing project as the target for orphaned Actions, with the original Hive Action date preserved as the Jira Issue creation timestamp.

Hive task and project custom fields map to Jira Custom Fields. We extract the field type from Hive (text, number, date, dropdown) and create the equivalent Jira Custom Field of matching type before migration. Jira Cloud assigns custom field IDs in the format customfield_XXXXX, which we use for subsequent API writes. Hive custom field options map to Jira custom field options with exact text matching; case sensitivity is enforced per Jira's requirement that option labels match exactly.

Hive Labels (flat tag strings applied to tasks) map directly to Jira Labels. We create any missing label values in Jira before migration and apply them to the corresponding Issues. Jira Labels are a standard field on the Issue and support the same filtering and board grouping use cases as Hive Labels.

Hive allows each project to define its own set of custom statuses with arbitrary names, meaning the same status field can mean different things across projects in the same workspace. We extract the status schema per Hive project and create a per-project mapping table. Each mapped Hive status becomes a Jira Status value within the project's Status scheme. We apply the mapping during task replay to avoid status-value collisions and ensure that tasks land in the correct workflow state.

Hive time-tracking entries are user-attributed records linked to tasks with hours, date, and optional notes. We map these to Jira Worklog records linked to the corresponding Issue. Time entries require a resolved Jira User account; if the original Hive user does not exist in Jira, the entry is flagged as orphaned and held for reassignment. Jira's billable flag maps from a Hive custom field if one exists; otherwise it defaults to billable.

Hive task and project attachments are downloaded to our staging storage and re-uploaded to Jira Issues via the Jira REST API, preserving filenames and the original task-to-attachment association. We handle attachment size within Jira's 10 MB per file limit and chunk large files as needed. Files exceeding the Jira limit are flagged for the customer's admin to host externally and link from the Issue description.

Hive workspace members with roles (Admin, Editor, Viewer) map to Jira Users. We resolve members by email match against the destination Jira site. Any Hive member without a matching Jira User is placed in a reconciliation queue for the customer's admin to provision before task assignment migration resumes. Jira project roles (Administrators, Developers, etc.) are mapped from Hive's role model during project permission migration.

Hive Views are presentation-layer configurations and do not carry as data records. We do not migrate Views. Jira's native Kanban boards and Scrum boards are created after migration using the migrated Issues as source data. The customer's team configures board filters and swimlanes based on their Agile process.