Migrate from Kantata Professional Services Cloud (formerly Mavenlink + Kimble) to Jira

Kantata OX Workspaces and Kantata SX Projects map directly to Jira Projects. During extraction we identify which product line each workspace belongs to by querying the workspace's internal product_type identifier, then apply the correct field map. The Jira Project must be created with the appropriate issue type scheme and workflow before workspace records insert, because Jira requires the project key prefix to exist before Issues can be assigned to it.

Kantata OX Tasks and Stories map to Jira Issue subtypes (Story, Task, Bug) based on the task's type identifier in Kantata. We read the task.type field and map STORY to Jira Story, TASK to Jira Task, and any BUG identifier to Jira Bug. The parent-child hierarchy (task.subtask_ids) reconstructs as Jira subtasks attached to their parent Issue. Subtask nesting beyond two levels in Kantata may exceed Jira's subtask depth, which we flag during scoping.

Kantata Subtasks attach to parent Tasks and inherit some parent-level fields. Jira Subtasks are a first-class issue subtype. We map subtask.parent_id to the Jira parent Issue key, preserving the title, description, status, and assignee. WBS numbering from Kantata's New Task Tracker does not transfer to Jira; we include the original WBS path in the Issue description as a reference note.

Kantata Users (internal staff and contractors) map to Jira Users by email address. We extract every user referenced on resource assignments, time entries, and task assignments, then resolve by email against the Jira Cloud or Data Center instance. Any Kantata user without a matching Jira account goes to a reconciliation queue for the customer's admin to provision before record import begins.

Kantata resource assignments carry User, Task, Role, hours allocated, and billing rate. Jira has no native role or billing rate field. We map the assigned User to Jira's standard Assignee field and encode the Role and billing rate as Jira custom fields (single-select for role, currency for rate). The hours allocated becomes a custom number field. If billing rate visibility is sensitive, we discuss field-level security configuration during scoping.

Kantata time entries carry date, user, hours (billable/non-billable), task reference, and notes. Jira natively supports Worklogs on Issues. We map the time entry date and hours to Jira Worklog entries linked by Issue key, with the original Kantata billable flag preserved as a custom Worklog field if Jira Premium is in use, or as a Jira Issue custom field if Standard tier.

Kantata Estimates model supply-and-demand scenarios using role-based resource composition and margin projections with versioned scenarios per workspace. Jira has no scenario modeling feature. We extract all active and historical estimate records as structured JSON and attach them as Jira Issue links or store them in a Confluence page linked from the Project, with the estimate values migrated as custom fields on the Issue for immediate visibility.

Kantata custom fields are organized by subject_type (Estimate, Story, User, Workspace, WorkspaceGroup, Resource). Custom Fields and Custom Field Values are separate API objects, each with independent rate limits. We apply subject_type-scoped pagination and queue-based rate management during extraction to avoid 429 errors. Destination Jira custom fields are created at the project level and mapped by field name and type (text, number, date, single-select, multi-select) with exact value matching for choice fields.

Kantata billing allows multiple invoices per project, tied to workspace and resource assignment records with billing rates, milestone triggers, and expense codes. Jira has no accounts receivable or invoicing module. We export the full invoice history as a structured data file and attach it to the Jira Project as a linked record, or store it in Confluence pages linked from the Project homepage. Line items that reference specific tasks are cross-referenced by task name in the attachment.

Kantata WorkspaceGroups organize workspaces into portfolios or folders and carry their own custom fields. Group-level custom field values require a separate API call scoped to WorkspaceGroup. Jira equivalents are Jira Project Categories (for grouping related Projects) or Jira Portfolio for hierarchical portfolio views. We map the workspace group hierarchy to the chosen Jira grouping structure during schema design.

Kantata external references link workspace and task records to objects in external systems—for Kantata SX customers this includes Salesforce Opportunity and Account IDs. Jira Issue Links provide a native way to express cross-system relationships. We map Kantata external references to Jira Issue Links using the referenced system's identifier (e.g., Salesforce ID stored in a custom field with a link type such as 'References SF Opportunity').