Migrate from Kantree to Jira

Kantree Workspaces are top-level containers holding projects, card types, views, and automations independently. Jira has no direct Workspace equivalent. We map each Kantree Workspace to a Jira Project or a group of Jira Projects under a shared Jira Configuration. Workspace-level card-type inheritance becomes Project-level Issue Type configurations. Workspace color themes and branding do not migrate; we document these for the customer's admin to re-apply in Jira project settings.

Kantree Projects (nested inside Workspaces) map 1:1 to Jira Projects. Project metadata (description, start date, target date, status) migrates to Jira Project fields. Project-level card group structures (columns) map to Jira Status columns or to Jira Swimlanes on the Board. Project-level custom fields (defined per-project in Kantree) are migrated as Jira Custom Fields scoped to the destination Project.

Kantree Cards are the atomic work unit and map directly to Jira Issues (Stories, Tasks, Bugs, or custom Issue Types). The card title becomes Issue Summary; card description migrates as Issue Description. Assignees map to Jira Assignee. Dates (due date, start date) migrate to the corresponding Jira date fields. Card priority maps to Jira Priority. Status is resolved from Kantree's group (column) assignment and mapped to the equivalent Jira Status value in the destination project's workflow.

Kantree Card Types define the available field schema per card category (Bug, Feature, Invoice, Patient). Jira uses Issue Types (Epic, Story, Task, Bug, custom) with Screen configurations that control which fields appear at each workflow transition. We export the full card-type schema including field names, field types, and field options, then create the equivalent Jira Custom Fields and assign them to the appropriate Screens for each Issue Type. Card types with no direct Jira equivalent become custom Issue Types.

Kantree supports 20+ field types: text, number, date, rating, single-select, multi-select, user reference, card reference, and formula. Single-select and multi-select migrate to Jira Select and Multi-Select Custom Fields. User reference migrates to Jira User Picker (single or multi). Rating migrates to Jira Rating or Number field. Card references (Kantree's internal link fields) require special handling: we extract the referenced card's ID and title, then create a Jira Issue Link of the configured relationship type at migration time. Formula fields compute dynamically in Kantree; we export the last-known computed value and store it as a Jira Number field, noting to the customer that Jira has no native formula engine and the value will be static unless a Jira plugin is installed.

Kantree supports one-to-one, one-to-many, and many-to-many card relationships defined at workspace level. Jira Issue Links (blocks, is blocked by, relates to, clones, etc.) support directed one-to-one and one-to-many links but not native many-to-many without a linking plugin. For N:N relationships, we create a separate Jira Issue Link for each direction, preserving the original relationship type label. The relationship label from Kantree is stored as a custom Issue Link type or as a label on the Jira Issue Link record if the destination Jira version supports it.

Kantree's seven view types (Kanban, Table, Matrix, List, Timeline, Calendar, Gantt) have partial Jira equivalents. Kanban view maps to Jira Kanban Board. List view maps to Jira Saved Filter with the same JQL conditions. Timeline and Calendar views map to Jira Roadmap (Premium) or to Jira Saved Filters with date-based JQL. Matrix view and Gantt view require Jira Marketplace plugins (Structure, BigGantt) or manual rebuild in Jira's native Roadmap. We export view definitions including filters, sort orders, and visible fields, and produce a written view-inventory document for the customer's admin to recreate.

Comments migrate as Jira Comments attached to the corresponding Issue. Author, timestamp, and edit history migrate where available. Kantree's 2-hour editable window for authors does not have a Jira equivalent; the final comment state migrates as the authoritative version. Rich text in Kantree comments (mentions, formatting) is converted to Jira's wiki-markup equivalent where possible.

Attachments migrate as Jira Attachments on the corresponding Issue. File metadata and download URLs are exported from Kantree's storage layer and re-uploaded via Jira's Attachment API. Jira Cloud enforces a 10 MB per-file limit and a 10 GB org-level storage limit; we flag any Kantree attachments exceeding these thresholds during scoping and discuss storage reduction options (compressed archives, link-only migration) before migration begins.

Kantree automations consist of triggers (card events, schedule, form submission), KQL-based conditional branches, and action chains (set field, move card, post comment, copy card). Jira Automation (cloud-native) uses rule-based triggers and actions but does not support KQL-style multi-card queries or the same conditional expression language. We export automation rule definitions as a written inventory document including trigger type, conditions, and action chain steps, with a recommended Jira Automation equivalent for each rule. We do not migrate automations as code. The customer's Jira admin rebuilds them using the inventory document.

Kantree distinguishes between billable organization members, project-level observers (free but read-only), and external guests. Jira has no native observer role equivalent; all Jira users consume a paid seat at Standard or above. We export user records with role assignments, workspace memberships, and observer/guest flags. Guest accounts (read-only in Kantree) are mapped to Jira users with Browse Projects permission only. Member accounts map to Jira users with the appropriate project roles. The customer confirms the Jira license tier before user migration.

Kantree Forms are public-facing input interfaces that create cards on submission. We export form definitions including field structure and submission routing. Jira does not have a native form-to-issue creation equivalent in Jira Software core; the replacement is a Jira Issue Collector (for quick feedback) or a Jira Service Management Request Type with a portal form. We document form definitions as a written spec for the customer's admin to configure in Jira Service Management if they have that product, or to implement via a Jira Issue Collector or third-party form plugin.