Migrate from KANNA to Jira

KANNA Projects map directly to Jira Projects as the top-level container. Each KANNA Project becomes a Jira Project with the same name, description, and date range (stored as custom fields if Jira project dates are not enabled). The Jira project must be created before any Issues migrate so that the project key is available for issue-key generation. We use the Jira REST API to provision projects before bulk issue creation begins.

KANNA Sub-projects are a first-class container for phased or multi-site work. Jira has no Sub-project object; the nearest equivalent is the Epic issue type, which groups related Stories and Tasks under a single parent. We evaluate each KANNA Sub-project during scoping: if it contains more than 10 Tasks, we create it as a Jira Epic; if it contains fewer Tasks, we flatten the Sub-project level and link the Tasks directly to the parent Project. The customer chooses the grouping strategy during scoping based on their Jira board configuration.

KANNA Tasks map to Jira Issues. The choice of Story versus Task in Jira depends on the customer's use case: Tasks represent discrete work items (analogous to KANNA Tasks with assignees and due dates), while Stories represent user-facing deliverables with acceptance criteria. We use Task as the default KANNA Task mapping and apply Story mapping where KANNA Tasks carry a deliverable description. Status (Open, In Progress, Done) maps to Jira status values; due dates map to Jira Due Date; assignees map by email resolution to Jira User accounts.

KANNA's Data Import/Export separately handles customer information and property information. Jira uses Components as a label-level grouping within a project (not a global object like Account). We map KANNA Properties to Jira Components on the migrated Project. KANNA Clients without a Jira-native equivalent are stored as a custom field (client_name__c) on each Issue for filtering and reporting.

KANNA custom fields are defined per project template via Settings > Customize Settings and store property-specific or client-specific data. Jira supports custom fields globally from the Jira Administration > Issues > Custom Fields screen. We capture both the KANNA field definition (name, type) and the values stored on each record during extraction, then pre-create equivalent Jira custom fields (Text Field, Date Field, Number Field, Select) before any issue migration begins. Field types are mapped by KANNA input type: text inputs to Jira Text Field, date inputs to Jira Date Field, dropdown selects to Jira Select.

KANNA Photo Reports are a first-class export category in KANNA's Data Import/Export. We extract photos and their captions and attach them to the corresponding Jira Issue. Each photo becomes a Jira attachment on the migrated issue with the KANNA caption stored in the attachment description field. Photo metadata (capture date, location if present) migrates as custom issue fields if the customer requests it during scoping.

Documents attached to KANNA Projects or Tasks migrate as Jira Issue attachments. We preserve the original filename and attachment association. Document content is not extracted or transformed; the file is attached as a binary to the Jira Issue. If a document is attached to a Project in KANNA but Jira has no project-level attachment, we attach it to the first issue in the project as a reference.

KANNA's in-platform chat and reporting threads on Projects and Tasks map to Jira Issue Comments. We preserve the author (by email resolution to Jira User), timestamp (set as Jira comment creation date), and text content. KANNA chat threads that span multiple Tasks are split into per-issue comments; threads with no Task association are attached to the parent Project as a Project-level comment in Jira if the destination project has a project description or documentation page. We flag any thread history that cannot be cleanly attributed to a specific Jira Issue for manual handoff.

KANNA user accounts and task assignees are exported separately. We resolve each KANNA user by email address to a Jira User account in the destination site. Any KANNA assignee with no matching Jira User account goes to a reconciliation queue before migration begins; the customer's Jira admin provisions the missing accounts. Inactive Jira users are supported: we set AssigneeId to the inactive user's account if the customer requires historical accuracy, or we reassign to an active user if the project is actively worked post-migration.

KANNA Project and Task statuses are configurable per workspace. We capture the full status taxonomy from KANNA during extraction and map each to a Jira Status value in the destination project's workflow. The Jira workflow must be configured before migration so that status transitions are valid. We use Jira status categories (To Do, In Progress, Done) to group KANNA statuses into the nearest Jira equivalent.