Migrate from Zenkit to Asana

Zenkit Collections are the top-level container, mapping to Asana Workspaces. Personal-tier Collections are capped at 100 and Plus at 1000, which we validate during scoping against the destination Asana plan. We create one Asana Workspace per Zenkit Collection, preserving the Collection name and description. Member assignment migrates by email match to Asana Users; any owner without a matching Asana account enters a reconciliation queue for admin provisioning before the migration phase begins.

Zenkit Lists inside a Collection map to Asana Projects inside the target Workspace. Each List's own field schema must be reconciled against Asana's project-level custom field model. Sub-lists within a Zenkit List map to Asana Sections, preserving the grouping hierarchy. We create the Project structure in Asana via the API before Items are imported so that Section lookups resolve at insert time.

Zenkit Items are the core record and map 1:1 to Asana Tasks. Standard fields (name, due date, assignee, status, priority) map directly to their Asana equivalents. Custom fields require type mapping (see Custom Fields entry). We insert Tasks via the Asana REST API in batches of up to 100, with rate-limit handling and exponential backoff on 429 responses. Task creation timestamps and modified dates carry over as the Task created_at and modified_at values.

Zenkit Reference fields create bi-directional relational links between Items across Lists. These map to Asana Dependents (predecessor-successor relationships) on tasks within the same project, or cross-project Dependencies on Business and Enterprise plans. CSV import does not support dependency creation natively; we resolve each Zenkit Reference to a source and target Task GID, then create the Asana Dependency record via the REST API after the parent tasks exist. Circular references are detected and collapsed to a single directional link.

Zenkit supports per-List field schemas with types including text, number, date, checkbox, select, multi-select, reference, and formula. Asana uses global custom fields attached to projects. When the same field name appears in multiple Zenkit Lists with consistent types, we merge into one Asana custom field. When types conflict (text in List A, number in List B), we resolve to the most comprehensive type or split into two fields with a suffix. Select fields map to enum picklists; multi-select to multi-enum. Formula fields from Zenkit are not natively supported in Asana and require manual re-creation or a third-party calculation tool.

Zenkit Labels are flexible tag values attached to Items, used for priority, category, or any taxonomy. They migrate as Asana Tags, preserving the label name and color where set. Tags in Asana are workspace-level objects; we deduplicate label names across all Lists into a single tag namespace per Workspace. If a Zenkit Label field was multi-select, we create a corresponding Asana tag array on the Task. Tags do not carry field-level metadata (which List defined the label); this is documented for the customer to reconcile post-migration.

Zenkit Comments attach threaded discussions to Items with body text, author, and timestamp. They migrate as Asana Stories attached to the corresponding Task. We preserve the comment body, the commenting user's email (resolved to an Asana User where possible), and the original timestamp. Asana's Stories system also captures system events (status changes, assignments); we filter to comment-type stories only during migration to avoid duplicating system-generated entries. Rich text formatting in Zenkit comments is converted to plain text with line breaks preserved.

Files attached to Zenkit Items migrate as Asana Attachments linked to the target Task. We download each attachment to local storage, then upload to Asana via the attachments API using the task GID as the parent reference. File name, file size, and MIME type carry over. Attachments above 100 MB are flagged during scoping because Asana's file upload limit is 100 MB per attachment. The customer's admin must decide whether to split large files, store them externally with a link, or exclude them from the migration.

Zenkit Items can be archived, hiding them from default views. We migrate archived Items as inactive or completed Tasks in Asana, depending on whether the original archive was soft-deleted or marked complete. Archived Items with attachments and comments carry those over as well. The customer chooses whether archived Items migrate during the standard migration pass or as a separate phase, which affects total record volume against Asana's per-task pricing implications.

Zenkit Sub-items exist as nested records within an Item, each with its own fields and status. Asana Subtasks are stripped-down tasks attached to a parent Task. We convert each Sub-item to an Asana subtask linked to the parent Task GID, preserving the name, due date (if set), assignee, and completion state. Sub-item custom fields map to the same custom field logic as top-level Items. Sub-items nested more than one level deep are flattened to a single level in Asana.

Zenkit Views (Kanban, Gantt, Table, Calendar, Mind Map) are display configurations on a single List dataset. They are not separate data objects and have no export mechanism. We document the primary view type of each Zenkit List in the migration metadata and note that the customer can re-apply the closest Asana equivalent (Board for Kanban, Timeline for Gantt, List for Table) during project setup. Global filters and saved views are UI-layer constructs that do not migrate and must be recreated manually in Asana.

Zenkit automations (Business tier) trigger actions based on field changes or events. They have no standard export format. We capture every automation's trigger, conditions, and actions during the discovery phase and deliver a written specification that maps each automation to an equivalent Asana Rule or a Zapier/Make scenario. The customer or an automation specialist implements the rebuild post-migration; automation recreation is outside standard migration scope. Automations are the most common reason teams underestimate migration scope if they rely heavily on workflow rules in Zenkit.