Migrate from ZenPilot to Asana

ZenPilot organizes ClickUp workspaces into three operational areas—Growth, Delivery, and Operations—that mirror the client's organizational structure. We map each ClickUp Space to an Asana Team, preserving the space name and any ZenPilot-specific naming conventions in a migration notes field on the Team. The Asana Team becomes the top-level organizational unit in the destination workspace. Teams are created before any Projects are imported so that Project-Team membership resolves at import time.

ClickUp Folders represent logical groupings within Spaces, often corresponding to client portfolios or service lines. We map Folders to Asana Projects if the Folder contains a small number of Lists, or to Asana Portfolio groupings if the Folder contains multiple deeply nested Lists representing distinct workstreams. The decision is made during scoping based on the actual Folder depth observed in the workspace. Folder naming conventions are preserved in the Project name with any ZenPilot methodology shorthand documented in the migration manifest.

ClickUp Lists are the primary task containers in ZenPilot-managed workspaces and often represent distinct workflow stages, project phases, or workstream types. We map each List to an Asana Section within the parent Project, preserving List-level status conventions as Section headers. If a ZenPilot workspace contains Lists that are not nested inside Folders (flat at the Space level), we create a standalone Asana Project to contain those Lists as Sections and flag the organizational gap in the migration manifest.

ClickUp Tasks carry the core workload data. We preserve task names, descriptions (migrated as rich text), assignees (resolved by email against Asana User accounts), due dates, priorities (mapped to Asana priority levels), dependencies, subtasks (preserved as Asana subtasks), comments, and attachments. Task status maps from the ClickUp List's status scheme to Asana task completion state. Dependencies are preserved as Asana dependencies where both platforms support the same dependency type; cross-platform dependencies that Asana does not support are flagged in the manifest.

ClickUp subtasks map directly to Asana subtasks. We preserve the parent-child relationship by resolving the parent task's new Asana ID at migration time before inserting the subtask. Subtask descriptions, assignees, due dates, and comments migrate with the same fidelity as top-level tasks. Subtask depth in ZenPilot workspaces is typically one or two levels; deeply nested subtask trees are flattened into a maximum of two levels in Asana, with a manifest note flagging any subtasks that exceed Asana's supported nesting depth.

ClickUp Custom Fields (30+ types including text, number, date, dropdown, rating, formula, and rollup) map to Asana Custom Fields of the equivalent type. Text fields map to Asana text fields; number fields map to Asana number fields with currency or percentage formatting preserved; date fields map to Asana date fields; dropdown fields map to Asana dropdown fields with option values preserved. Formula fields and rollup fields require manual rebuild in Asana as Asana does not support computed custom fields. Custom fields are created in Asana before any task data is imported, and the mapping table is validated during the Sandbox migration phase.

ClickUp's built-in time tracking entries—duration values linked to tasks with assignee and timestamps—migrate to Asana time tracking entries if the destination Asana workspace is on a Premium plan or above that supports timesheets. We preserve the duration value, the associated task, the assignee, and the original timestamp. If the destination Asana workspace is on a lower plan, time tracking entries are migrated as a custom number field (hours) on each task so the data is preserved even without the native time tracking add-on. Time tracking data is particularly important in ZenPilot workspaces that track billable client hours.

ClickUp Tags provide cross-cutting classification across tasks and lists. ZenPilot uses tags to label work by type, priority, or client. We preserve tag names and all tag assignments across all tasks, mapping them to Asana Labels. Tag color coding migrates if available; if not, we assign a default color. Label cleanup is recommended post-migration to consolidate any duplicate or near-duplicate tags that arose during the ZenPilot onboarding process.

ClickUp Docs store process documentation, meeting notes, and project briefs. ZenPilot creates extensive Docs as part of their methodology. We migrate Doc content, formatting, and internal links intact into Asana Docs attached to the relevant Project. If the Doc contains a link to a ClickUp task that has been migrated, we update the internal link to point to the new Asana task URL. Docs that reference un-migrated objects are flagged in the Doc migration manifest for manual link correction.

All standard ClickUp views—List, Board, Box, Table, Calendar, and Map—are evaluated for migration. List views map naturally to Asana's list view; Board views map to Asana's Subtasks board or a kanban-style section arrangement; Calendar views map to Asana's Calendar view; Gantt-style views map to Asana's Timeline view on Premium and above. ZenPilot's curated role-specific views (common in agency workspaces) are documented in the migration manifest with a recommended Asana equivalent for each viewer role. View-level filters and saved filter states migrate as documented configuration notes for manual recreation.

ZenPilot builds ClickUp automations using ClickUp's automation engine for task routing, status updates, and notifications. Asana Rules use a trigger-action model that differs structurally from ClickUp's automation engine. We do not migrate automations as code. We produce a written automation audit document that inventories every active ClickUp automation, describing its trigger, conditions, and actions, and recommending the equivalent Asana Rule configuration. The customer's Asana admin rebuilds each rule post-migration. Automations that reference custom fields by ClickUp field ID will break in the migrated workspace even if not rebuilt; the automation audit document includes a field ID remapping manifest for any rules rebuilt before the migration cutover.

ZenPilot's custom dashboards—including their Profitability Reporting module—connect widget configurations to specific task data, custom fields, and time tracking entries. Asana's Dashboard (Premium and above) provides portfolio-level status widgets but has no native Profitability Reporting equivalent. We migrate all underlying task data, custom fields, and time tracking so that the data is available for rebuild. We deliver a dashboard requirements document describing each ZenPilot dashboard widget, its data source, its visualization type, and the recommended Asana approach (native Dashboard widget, Asana's reporting API, or a third-party BI tool). The ZenPilot Profitability Reporting add-on requires the most significant rebuild effort; this is documented separately with specific field mapping for margin calculations if those were used.

ClickUp Goals link targets to tasks, numerical goals, or custom metrics. ZenPilot sometimes uses Goals for OKR-style tracking within Growth or Delivery areas. Asana Goals (available on Business and Enterprise tiers) provide a similar linking model but with different structure. We flag Goal artifacts in the migration scope and deliver a written mapping document describing each ClickUp Goal, its linked tasks, target values, and time period. Goals require manual recreation in Asana because the linking model differs. If the destination Asana workspace is on a lower tier without Asana Goals, the Goal data is preserved as task-linked custom fields and documented for later activation.

ZenPilot's library of process templates—including recurring workflow patterns for new client onboarding, sprint cycles, and project delivery—reside in ClickUp as List or Folder templates. We identify which templates have been used to create live tasks in the past 90 days and migrate those as active templates. Templates with no recent usage are migrated as inactive assets with a label indicating they were unused. Asana Project Templates are created by saving a Project as a template; we document each migrated template's source List or Folder structure and the recommended conversion steps for Asana admin recreation.