Migrate from OneDeck to Jira

OneDeck Boards map 1:1 to Jira Projects. Board name becomes Project key and name; Board description maps to Jira Project description. We pre-create Jira Projects in the destination using the Jira REST API before any Issues are imported, ensuring the project key is available as a lookup reference during task migration. If OneDeck workspaces contain boards from multiple business units, we recommend mapping each to a separate Jira Project with appropriate permission schemes.

OneDeck Tasks map to Jira Issues with the Issue Type inferred from task characteristics identified during discovery. Tasks with type labels suggesting software defects map to Jira Bug; tasks with acceptance criteria and story-point estimates map to Story; tasks representing action items map to Task. Jira's issue type hierarchy (Epic, Story, Task, Bug, Subtask) is available from Jira Software Standard. We set the Project key, Issue Type, Summary, Description, Status, Priority, and Assignee via the Jira REST API. Parent-child task relationships in OneDeck map to Jira Sub-Task or linked Issues.

OneDeck View configurations (Kanban, Table, Calendar) are not directly transferable to Jira because Jira separates Project structure from visualization. We document each OneDeck View's filter criteria, column configuration, and grouping logic as a written specification. The customer's Jira admin recreates these as Jira Boards (Scrum or Kanban) or Saved Filters using JQL. Views do not migrate as executable configurations.

OneDeck custom fields on records (text, number, date, dropdown, checkbox) map to Jira Custom fields of equivalent type. We extract all custom field definitions during discovery, map field types (OneDeck text to Jira Text Field, OneDeck dropdown to Jira Select List, OneDeck checkbox to Jira Checkbox), and pre-create the Jira custom fields in the destination project before record import. Jira's custom field configuration is project-scoped for team-managed projects and global for company-managed projects; we confirm the target architecture during scoping.

OneDeck Document Builder files (quotes, invoices, work orders) migrate as Jira attachments linked to the corresponding Issue. We export file content and upload via Jira's REST API attachment endpoint. OneDeck PDF formatting does not automatically render in Jira's document viewer; customers should review a sample of migrated documents post-migration to confirm the file is accessible and readable. Formatted PDF layout is not preserved; underlying data fields are transferred as file content only.

OneDeck Automation Scenarios do not export in a transferable format. The platform uses platform-specific trigger-action logic (Record Created, Record Updated, Document Published triggers with CRM and task actions) that has no equivalent serialization. We do not migrate automations as code. During discovery we identify every active scenario, capture its trigger conditions and actions in a written inventory document, and deliver it to the customer's Jira admin for manual rebuild using Jira Automation Rules (available from Jira Software Standard). This is a time-consuming step that is often underestimated during planning.

OneDeck user accounts and task assignee assignments map to Jira User records. We resolve users by email match. Any OneDeck user without a matching Jira account is placed in a reconciliation queue for the customer's Jira admin to provision before record import continues. Jira's user management requires appropriate project role assignments (Administrators, Developers, Consumers, etc.) which the admin configures as part of the project permission scheme.

OneDeck task and record comments migrate to Jira Issue Comments where the source API exposes them. OneDeck comment availability varies by plan and workspace configuration; we verify accessibility during discovery and include comment migration in scope only when the API exposes them. When comments are inaccessible, we document the gap and inform the team that comment history will not appear in Jira unless manually exported or screenshots are taken.

OneDeck subtasks embedded within a parent task migrate as Jira Sub-Task issues linked to the parent Issue. Jira Sub-Task is a standard issue type that must be enabled in the destination project's Issue Type Scheme before migration. We set the Parent field on each Sub-Task via the Jira REST API, and the parent-child relationship renders as a collapsible hierarchy in Jira's issue view.

OneDeck board column statuses (To Do, In Progress, Done, and any custom columns) map to Jira Status values within the destination project's workflow. Each OneDeck status becomes a Jira Status with a corresponding state category (To Do, In Progress, Done). Custom column names are translated to Jira status descriptions. We configure the Jira workflow's Status values to match the source board's status semantics so that issue cards appear in the correct swimlane on the Jira Kanban board.

OneDeck task due dates migrate directly to Jira Issue Due Date. Jira stores due dates in the duedate field, which displays in the Jira issue card, board card, and calendar view. We validate date format (YYYY-MM-DD) during the transform step. If a OneDeck task has a due date but no corresponding Jira status transition path to handle overdue issues, we document the gap for the admin to configure in the Jira workflow.

OneDeck record tags and labels map to Jira Labels on Issues. Labels in Jira are free-form text tags that appear in issue cards, board filters, and JQL queries. We extract all unique tag values from OneDeck records and apply them as Jira Label values during issue import. Jira Labels are per-project or global depending on whether the project is team-managed or company-managed.