Migrate from Zenkit to Jira

Zenkit Collections are top-level containers analogous to Jira Projects. Each Collection maps to one Jira Project, and we set the Project key based on the Collection name (uppercased, stripped of spaces, max 10 characters). If the customer has multiple Collections and prefers to consolidate them into fewer Jira Projects, we map Collections to Jira Project categories or use Project prefixes to preserve namespace isolation. Tier-based Collection quotas (Personal: 100, Plus: 1000, Business: 5000, Enterprise: unlimited) are validated against the destination Jira tier's project limits before migration.

Zenkit Lists live inside Collections and each has its own field schema, making them closer to Jira Projects than to Jira sub-objects. We map each List to a Jira Project Component within its parent Collection-Project, or we create separate Jira Projects if the Lists have fundamentally different workflows or issue types. The customer's preference is captured during scoping: consolidated (fewer Projects with Components) or split (one Project per List). Lists with custom statuses map to Jira Status Categories (To Do, In Progress, Done) and individual Status values.

Zenkit Items are the core record type and map 1:1 to Jira Issues. Standard Item fields (name, due date, assignee, priority) map to Jira Summary, Due Date, Assignee, and Priority. Custom fields map to Jira custom fields of the matching type (see Custom Field mapping). Each Item's original Zenkit ID is preserved in a Jira custom field zenkit_item_id__c for audit and cross-reference. Items are imported in topological order relative to their Sub-items and Reference dependencies so that parent records exist before child records.

Zenkit field types map to Jira custom field types as follows: Zenkit Text to Jira Text Field (single line) or Text Area (long text); Zenkit Number to Jira Number Field; Zenkit Date to Jira Date Picker; Zenkit Checkbox to Jira Checkbox; Zenkit Select to Jira Single Select; Zenkit Multi-select to Jira Labels or Multi-select; Zenkit Formula and Aggregation fields map to Jira Calculated Number fields (if the destination is Jira Data Center with ScriptRunner) or are documented as unsupported and preserved as read-only custom fields for manual re-entry. Reference fields map to Jira Issue Links (see Reference mapping).

Zenkit's bi-directional Reference fields connect Items across Lists, acting as a lightweight relational database. We extract the full reference graph from Zenkit's JSON export, resolve each Reference to its target Item ID, then map it to a Jira Issue Link relationship. The default link type is 'Relates To'. If the Reference has a directional semantic (e.g., 'blocks' or 'depends on'), we map to the corresponding Jira link type. Circular References are detected and collapsed to a single 'Relates To' link to prevent infinite loops in Jira's link index. All original Reference metadata is preserved in the zenkit_reference__c field on the Jira Issue Link for audit.

Zenkit Labels (flexible tag fields on Items) map directly to Jira Labels. We extract the full label taxonomy from Zenkit and bulk-create the corresponding Jira Label values before Item import so that label autocomplete works immediately. Labels used for categorization map to Jira Labels; if a customer used Labels for numeric scoring or boolean flags, we map those to Jira custom fields instead during scoping.

Zenkit Comments attach threaded discussions to Items with body, author, and timestamp. We map them to Jira Comments on the corresponding Issue. Comment body migrates as rich text, stripping or escaping HTML markup from Zenkit's CSV export to produce clean text in Jira's comment renderer. Mentions of other Zenkit users are preserved as @mention text and documented in the handoff notes for the customer's admin to re-link in Jira. Comment timestamps are preserved exactly to maintain the activity timeline ordering.

Zenkit Items can contain Sub-items, creating a one-level hierarchy. We map Sub-items to Jira Sub-tasks linked to their parent Issue via the Jira Subtask subtask issue type. Sub-items have their own fields, assignees, and due dates that migrate as subtask fields. Jira Sub-task creation requires the parent Issue to exist first, so we import all parent Items before any Sub-items, using batched insert with the Jira Bulk API to maintain parent-child ordering.

Zenkit Attachments are files linked to Items. We download all attachments from Zenkit to local storage during the extraction phase, map each attachment to its target Jira Issue by Zenkit Item ID, then re-upload via the Jira REST API. Attachments with null filenames are flagged and excluded from migration; the customer must assign a valid filename before re-importing. File size limits apply per Jira tier (Jira Cloud: 32 MB per file; Jira Data Center: configurable, typically 50 MB). Attachments exceeding the destination limit are documented with size details for the customer to decide whether to host externally and link.

Zenkit Items that are archived export as inactive records. We map archived Items to Jira Issues with status set to the appropriate closed state (Done, Closed, or Resolved) in the target project's workflow. The original archived status is preserved in a custom field zenkit_archived__c for reporting. Archived Items are imported after active Items so they do not pollute the active workflow during migration.

Zenkit supports Kanban, Gantt, Table, Calendar, Mind Map, and other view types. Views are display configurations, not separate data. We migrate the underlying Items and Fields (see Item and Custom Field mappings) and document the dominant view type per List in the migration inventory. Jira Boards are rebuilt from the imported Issues by the customer's admin post-migration. Saved Zenkit filters are documented as named filter specifications and recreated manually in Jira.

Zenkit Business-tier automation rules (triggers based on field changes, assignments, due dates, or comments) have no export mechanism. We capture every automation during the discovery phase, document its trigger type, conditions, and actions, and produce a written specification that maps each rule to its Jira Automation equivalent. The customer's Jira admin rebuilds the rules post-migration. We do not migrate automations as code.