Migrate from ZenPilot to Jira

ZenPilot organizes ClickUp workspaces into three operational areas—Growth, Delivery, and Operations—that represent organizational divisions. Each Space maps to a Jira Project. The mapping is 1:1 but Jira Projects do not enforce the same operational separation; we recommend labeling Jira Projects with the original ZenPilot area name (e.g., Project: Delivery) and configuring project-level permissions to enforce the boundary. Projects are created before any child objects (Lists, Tasks) are migrated.

ClickUp Folders are logical groupings within Spaces that ZenPilot often uses to separate client portfolios or service lines. Jira has no direct Folder equivalent. We recommend either using Jira Components (a flat list within a Project) for simple groupings or promoting Folder-level content to Jira Epic level if the folder represents a major deliverable area. The choice is documented during scoping based on how the source team used Folders.

ZenPilot Lists are the primary task containers and often represent distinct workflow stages, project phases, or client workstreams. We split Lists into Jira Epics if the List contains more than 20 sub-tasks and represents a multi-week initiative, or into standard Jira Issues (Story, Task, or Bug) if the List is a short-cycle task queue. The split rule is defined during scoping based on the actual List contents in the source workspace.

Core task data migrates directly: task name to Summary, task description (rich text) to Description, assignee to Assignee (via email match to Jira User), due date to Due Date, priority from ClickUp priority value (Urgent/High/Normal/Low) to Jira Priority (Highest/High/Medium/Low). Subtasks migrate as Jira Subtask issues linked to their parent Issue. Comments migrate as Jira Comments against the parent Issue. Dependencies migrate as Jira Issue Links (Blocks/Blocked by).

ClickUp supports 30+ custom field types including text, number, date, dropdown, rating, checkbox, URL, email, phone, currency, user, formula, and relation fields. Jira Cloud custom fields support a narrower set of types. We pre-create Jira custom fields with matching types before migration: ClickUp dropdown maps to Jira Select List, checkbox maps to Checkboxes, rating maps to Ratings (requires Jira Premium), and date maps to Date Picker. ClickUp formula fields have no direct Jira equivalent without the Misc Calculated Fields app; we document these as custom field gaps requiring post-migration rebuild or app installation.

ZenPilot uses ClickUp Tags for cross-cutting classification by work type, client, priority, or department. Tags map directly to Jira Labels (a native Jira field). We preserve all tag names and reassign them to migrated Issues. Jira Labels is a free-text field with autocomplete rather than a controlled vocabulary, so tag consistency depends on the source tag naming conventions being consistent.

ClickUp time tracking entries (duration, assignee, associated task, timestamps) migrate as Jira Worklog entries against the corresponding Issue. We preserve time entry timestamps and assignee by matching the ClickUp task assignee to the Jira User by email. Jira aggregates worklogs into the Issue's time tracking totals automatically. If the source workspace used ClickUp's billable time flag, we carry it as a custom field on the Jira Issue.

ZenPilot creates extensive ClickUp Docs for process documentation, meeting notes, and project briefs as part of their methodology. Jira has no native Docs feature. We split migration by content type: standalone process documentation and meeting notes migrate to Confluence (the standard Atlassian documentation tool) as new Pages in a designated space; project briefs and task-adjacent docs migrate as formatted content in Jira Issue Description fields. The split is determined by content scope during the scoping phase.

ZenPilot builds ClickUp automations for task routing, status updates, notifications, and recurring task triggers. Jira automations use a completely different rule model with triggers (field changed, issue created, scheduled), conditions (issue properties, JQL filters), and actions (transition, comment, notify, webhook). We do not migrate automations as code. We audit all active ClickUp automations during discovery, document each rule's trigger, conditions, and actions in a written inventory, and map each to a recommended Jira Automation for Jira (or Jira Cloud workflow) equivalent. The customer's admin rebuilds them post-migration.

ZenPilot's ClickUp Dashboards—including their proprietary Profitability Reporting add-on that connects task data to client and project margin widgets—are the most migration-sensitive artifacts. Dashboard widget configurations reference specific custom fields, filters, and time tracking data that lose their context in a new Jira project. We document every active dashboard with its widget types, data sources, and filter criteria in a written inventory for the customer's admin to rebuild using Jira Dashboard gadgets. Time tracking data is preserved (see Worklog mapping); the dashboard rebuild scope is the customer's responsibility.

ZenPilot curates ClickUp Views (List, Board, Box, Table, Calendar, Map) for different team roles. Jira replaces these with Board views (Scrum Board, Kanban Board) and saved Filters. We document each ZenPilot View's filter configuration, grouping, and sorting during discovery and map them to equivalent Jira Board configurations and saved JQL filters in a written deliverable. The team's board layouts are rebuilt by the admin post-migration.

ZenPilot sometimes uses ClickUp Goals for OKR-style tracking within Growth or Delivery areas, linking targets to tasks or custom metrics. Jira has no native Goals object. We map active Goals to Jira Epics within a designated OKR project, or document them for rebuild using Jira Product Discovery (a separate Jira product) if the customer licenses it. Goals without active targets are archived as inactive deliverables.