Migrate from Gauss Box Projects to Jira

Gauss Box Projects map 1:1 to Jira Projects. Each Gauss Box Project name becomes the Jira Project name and key prefix (e.g., GAUSSPROJ). We preserve project-level deadlines, budgets, and the Gantt start/end dates as the Jira Project's start and due dates. Jira project-level configurations (permission scheme, issue type scheme, workflow scheme) are created before migration using the Jira API and assigned at import time.

Gauss Box Phases have no direct Jira equivalent; Jira uses Fix Versions (releases) to group issues by milestone. We map each Gauss Box Phase to a Jira Fix Version with the phase name as the version name and phase start/end dates as the Fix Version's release date. Where phases are used purely as sequential work stages rather than milestones, we offer an alternative mapping to Labels (prefixed with phase:) for teams that prefer label-based filtering over Fix Version grouping.

Gauss Box Tasks map to Jira Issues. We use the Jira Issue Type as the discriminator: tasks with deliverable scope and acceptance criteria map to Jira Story; tasks representing work items without story-level scoping map to Jira Task. Status, Priority, Assignee, and due date migrate directly. We preserve the Gauss Box task description as the Jira Issue description field. The Gauss Box task name becomes the Jira Summary field.

Gauss Box Subtasks map directly to Jira Subtask issue type. We preserve the parent-child link by resolving the Gauss Box parent task to its Jira Issue key at migration time and setting the Subtask's Parent link accordingly. Jira enforces a maximum nesting depth of three levels (Epic > Story/Task > Subtask), which is consistent with Gauss Box's subtask model. We flag any subtasks that would exceed this depth at scoping.

Gauss Box Gantt data consists of project start/end dates, phase timelines, and task dependencies (finish-to-start, start-to-start). We map project start/end dates to the Jira Project's start and release dates, and phase dates to Fix Version release dates. Task dependencies migrate as Jira Issue Links of type 'Blocks' or 'is blocked by' using the Jira Issue Links API. Jira's native Gantt view (via Structure or native boards) renders these dependencies without additional configuration.

Gauss Box Kanban columns map to Jira Status values within a Jira Kanban Board. We inventory all column names during discovery, create corresponding Status values in Jira (or map to existing statuses if the target project uses a shared scheme), and preserve card ordering within each column using the Jira Rank field (or manual ordering via the board API). Column-to-status mapping is configured in Jira before migration so that the first import populates the correct board state.

Gauss Box time entries map to Jira Worklog records on the corresponding Jira Issue. We resolve the Jira Issue key from the Gauss Box task reference, the Jira User from the Gauss Box user email, and the duration from Gauss Box's time tracking fields. Time estimates (Gauss Box budget hours) migrate as Jira Original Estimate (originalEstimateSeconds) and actuals as Worklog timeSpentSeconds. Jira's Time Tracking must be enabled on the target project; we configure this during the project schema setup phase.

Gauss Box comments on tasks migrate to Jira Issue comments. We preserve the comment body, author (resolved by email to Jira User), and timestamp. Threaded comments where Gauss Box supports reply chains map to Jira's flat comment structure; we do not preserve threading depth as Jira does not support it natively. Rich text formatting in Gauss Box comments is converted to Jira's wiki-markup format during import.

Gauss Box file attachments on tasks migrate to Jira Issue attachments via the Jira Attachment API. We inventory total attachment volume and file type distribution during scoping. Jira Cloud allows attachments up to 256MB per file on Premium and Enterprise plans; Standard caps at 32MB per file. We flag any files exceeding the destination plan's limit and advise on storage tier before migration. Attachment links to the correct Jira Issue are resolved via the Gauss Box task reference at migration time.

Gauss Box custom fields via attribute sets are fully user-defined with no fixed schema. We inventory every attribute set during discovery, record the field name, data type (text, number, date, single-select, multi-select), and which projects and tasks use each field. Each Gauss Box attribute maps to a Jira custom field of the matching type. Single-select Gauss Box fields become Jira single-select custom fields; multi-select become Jira multi-select. The Jira custom field is created in the target project before record import and linked to the relevant issue types.

Gauss Box users map to Jira users by email match. We extract the full user list including department assignments and Gauss Box role names during discovery. Jira Groups are created to mirror Gauss Box departments, and Jira project-level role assignments (Browse Projects, Edit Issues, Administer Project) are mapped from Gauss Box role permissions. External collaborators in Gauss Box with limited-view access map to Jira users with Reporter or Watcher roles if the destination Jira project requires external input. Any Gauss Box user without a matching Jira account is placed in a reconciliation queue for the customer's Jira admin to provision before record import.