Migrate from Redbooth to Jira

Redbooth Workspaces map directly to Jira Projects. We preserve the workspace name as the Jira project name, the workspace description as the Jira project description, and the workspace member list as Jira project administrators and default members. Each workspace maps to one Jira project; if the customer has more than 50 projects Jira may require project templates or a project类型 configuration to manage at scale.

Redbooth Task Lists map to Jira Backlog sections (if using the Backlog view) or to Jira Components (if using the Board view). We preserve Task List ordering via the weight/sort-order field, mapping it to Jira rank (IssueRank or the native backlog ordering). If a Task List contains more than 200 tasks, we split it into multiple sprints in Jira during migration.

Redbooth Tasks map to Jira issues with the issue type determined by the task's content and subtask count. Tasks containing subtasks (Business plan) map to Jira Epic. Tasks with no subtasks that describe a deliverable map to Story. Tasks describing an action item without acceptance criteria map to Task. Tasks explicitly labeled as bug or error in the Redbooth name or description field map to Bug. The original Redbooth task name becomes the Jira Summary field.

Redbooth Advanced Subtasks (Business plan only) map to Jira Sub-task issue type, which requires the Jira Standard or Premium plan. Subtasks are linked to their parent Jira issue via the Parent Link field. If the source account is on the Pro plan without Advanced Subtasks, tasks are stored as flat linked records and we map them as Jira Tasks with a custom redbooth_parent_id__c field for manual parent assignment in Jira after migration.

Redbooth priority levels (Low, Normal, High, Urgent) map to Jira Priority values (Lowest, Low, Medium, High, Highest) using the closest semantic match. Redbooth due dates map to Jira Due Date (duedate field) directly. Start dates from Redbooth's Timeline view map to Jira Issue Start Date (startDate field) on Jira Premium plans only; on Standard plans startDate is not available natively and we document this gap for the customer's admin to handle through a custom field.

Redbooth task assignee (a user email reference) maps to Jira Issue Assignee via email-based user matching. We resolve each Redbooth assignee to a Jira user account by email before migration. If a Redbooth user has no corresponding Jira account, we flag the record in a reconciliation queue and map it to the project default assignee or leave it unassigned pending user provisioning.

Redbooth workspace-scoped tags map to Jira Labels (labels field) as plain text strings. The task-to-tag associations migrate as Jira label values on each issue. If tags function as a categorization system (e.g., team, category, product area), we recommend creating Jira Components or a custom picklist field instead during post-migration cleanup.

Redbooth task-level Comments migrate to Jira Issue Comments. The comment body, author (by email), and timestamp (created and updated) transfer directly. Workspace-level Conversation threads are not a native Jira object; we map each conversation as a series of Jira Comments on the relevant project default issue (or a designated Documentation Epic) for visibility, with a comment header noting it was a Redbooth conversation thread.

Redbooth standalone Notes (workspace-level, not attached to a task) have no direct Jira equivalent. If the destination Atlassian instance has Confluence linked, we map Notes to Confluence Pages within the matching project space. If Confluence is not available, Notes migrate as Jira Comments on a designated Documentation issue with a Note: prefix in the comment body.

Redbooth exports file metadata and URLs, not actual files. We extract every attachment reference (file name, URL, upload date, uploader) into a re-attachment manifest. The customer manually re-uploads source files to Jira after migration because Redbooth stores files in Redbooth's own cloud and the export bundle does not include binary data. We flag the re-attachment manifest as a required post-migration step before the migration sign-off.

Redbooth time tracking entries (Pro+ plans) map to Jira Worklog records if the destination is Jira Premium with time tracking enabled. Each entry carries duration, user (by email match), task reference, and date. If the destination Jira is Standard plan (no native time tracking), we export time entries as a structured CSV with task reference, user, duration, and date for manual import or reporting. Jira Premium time tracking requires explicit enabling by the admin before worklog import.

Redbooth's Timeline view renders task start/end dates and dependency links. We extract start date, end date, and predecessor task references. Complex dependency chains (finish-to-start, start-to-start) do not map directly to Jira's dependency model; we import the dates as Jira Due Date and Start Date fields (Premium) and document the dependency graph as a CSV for manual rebuild in Jira's linked issues.

Redbooth user profiles (name, email, avatar, role) map to Jira user accounts by email lookup. Member roles (Admin, External, Participant) inform Jira project role assignments (Administrators, Developers, Members) during migration. External members who should not have Jira access are flagged for the customer's admin to deactivate in Jira after migration.