Migrate from Tability to Jira

Tability Objectives map to Jira Projects if the Objective represents a standalone initiative, or to Jira Epic within an existing Project if Objectives are sub-divisions of a larger Jira Project. We advise on this split during scoping based on the customer's Jira setup. The Objective title, description, owner, start/end dates, and current status migrate. Parent-child Objective hierarchies map to Epic-to-Epic links or Jira issue dependencies (Blocks, is Blocked By). We preserve the Objective's overall progress percentage as a custom number field so admins can reference it post-migration.

Tability Key Results map to Jira Stories in most cases, or to Sub-tasks if the Key Result is tightly scoped to a parent Story. The metric type (number, percentage, currency, binary) maps to a corresponding Jira custom field type: number fields for numeric KRs, percentage fields for percentage KRs, currency fields for currency KRs, and a checkbox custom field for binary KRs. Current value, target value, and unit label transfer as field values. We cannot preserve Tability's auto-calculated progress percentage; instead we store the raw current and target values and let Jira admins decide whether to display progress via custom dashboards.

Tability Tasks linked to Objectives map to Jira Tasks or Sub-tasks depending on the customer's Jira issue hierarchy preference. The assignee, due date, and completion status migrate. We preserve the Objective linkage as a Jira Epic Link custom field or as a parent Epic association. If Tability Tasks have no Objective linkage, they migrate as standalone Jira Tasks. Tability Task dependencies map to Jira issue dependencies (Blocks, is Blocked By, Clone, Relates To).

Tability check-ins (timestamped progress updates with author notes) merge into Jira as Comments on the mapped Epic or Story. We export the full check-in history as a dated log (date, author, note, updated progress value) and post each entry as a Jira Comment in chronological order with the author attributed. Jira's native activity stream then shows the goal's evolution over time. If the customer is on a Tability tier that restricts activity log access, we flag the gap and advise on pre-export screenshots for critical check-in periods.

Tability Owners (users assigned to Objectives or Key Results) match by email to Jira users in the destination Jira Cloud site. We extract all owner references from the export and resolve against Jira's user directory. Owners without a matching Jira user go to a reconciliation queue; the customer's Jira admin provisions any missing users before record import proceeds. Unmatched owners are noted as ghost assignees requiring manual reassignment post-migration.

Tability's Strategy Map visualizes cross-team Objective dependencies and alignment. There is no export format for the dependency graph; we query each Objective's linked dependencies manually from the Tability UI and construct a structured adjacency list. For organizations with fewer than 20 cross-linked Objectives, we reconstruct dependencies as Jira issue links (Blocks, is Blocked By, Relates To) during import. For organizations with more than 20 cross-linked Objectives, we flag this as a manual re-linkage gap and deliver a dependency matrix document for the customer's admin to rebuild in Jira after migration.

Tability custom fields on Objectives and Key Results export as name-value pairs in the CSV. We map these to Jira custom fields, creating them with matching names and appropriate field types (text, number, date, select, multi-select) during the Jira schema preparation phase. We apply type coercion where Tability's loosely-typed custom fields map to Jira's strictly-typed equivalents. Mismatched type conflicts are flagged for admin resolution.

Tags applied to Tability Objectives and Key Results export as string arrays. We map them to Jira Labels on the corresponding issues. Labels are the closest Jira equivalent; there is no native tagging taxonomy in Jira. We do not preserve tag hierarchy or color coding from Tability.

Tability Standups are async daily updates scoped to individuals. They are transient, conversation-level data with no structural equivalent in Jira. We do not migrate standups. We flag them as out of scope during scoping so customers do not expect this data to carry over.

Tability Dashboards are saved view configurations with chart layout and filter state. These are UI-level constructs without semantic data content. We do not migrate dashboard layouts. We deliver a written inventory of the customer's dashboards and their filter logic so the customer's Jira admin can recreate equivalent Jira board configurations post-migration.

Tability AI-generated goal drafts and suggestions exist within the platform's AI feature layer and are not stored as exportable database records. They cannot be migrated to any destination platform. We document this boundary upfront so customers do not expect their AI-generated draft library to carry over. Jira's own Atlassian Intelligence features regenerate recommendations post-migration.