Migrate from KANNA to Asana

KANNA Projects map directly to Asana Projects. Each KANNA Project carries a name, status, date range, and client or property association. We export KANNA Projects via the native Data Import/Export feature and import them into Asana as Projects, preserving the project name and date range. KANNA project status values map to Asana project-level custom fields or section headers depending on the customer's preference during scoping.

KANNA Tasks map to Asana Tasks within the parent Project. Task name, description, due date, assignee, and status migrate directly. KANNA's task-level status values (customizable per workspace) map to Asana's Task status model or a custom field if the KANNA taxonomy does not map cleanly to a binary complete/incomplete. The original assignee is resolved by email against Asana Users during import.

KANNA Sub-projects are used to break phased or multi-site work within a parent Project. Asana has no native Sub-project object; instead, we flatten Sub-projects into Sections within the parent Project. Tasks belonging to each Sub-project are placed inside the corresponding Section, preserving the original grouping and phase context. We flag any Sub-project with its own Sub-projects as a nested section hierarchy.

KANNA custom fields are configured per project template via Settings > Customize Settings and are not globally defined. We extract both the field definitions and the values stored on each record. In Asana, we create global custom fields (text, number, date, single-select, multi-select) and attach them to the relevant projects. Template-bound fields with different schemas per project result in a custom field created per template variant; we document the template-to-field mapping to avoid duplicate custom field names in Asana.

KANNA's Photo Reports are a first-class export category. We extract each photo and its caption, then attach the file to the corresponding Task in Asana. Photo captions are stored in the task description or a custom field depending on caption length. File attachments over 100MB are not supported by the Asana API and are flagged for manual handling. We validate each photo attachment post-import to confirm the file is viewable in Asana.

KANNA Documents attached to Projects and Tasks migrate as Asana Attachments on the equivalent Project or Task. Document content itself is not extracted or transformed; the file is preserved and re-attached. We preserve the original file name and any KANNA-specific metadata in the attachment description field.

KANNA in-platform chat and reporting threads on Projects and Tasks are treated as comment threads in Asana. We extract the author name, timestamp, and text content. KANNA's Data Import/Export does not list comments as a named export category, so we extract them from the UI export where accessible and flag any gap explicitly before migration begins. Asana comments are fully API-accessible for post-migration validation.

KANNA's Data Import/Export separately handles customer information and property information as distinct data types. Asana does not have native objects for Customers or Properties outside of a project context. We map these to a custom field on the Project (e.g., Client Name, Property Address) or include them in the project description depending on how the customer uses this data in KANNA.

KANNA's Gantt Chart data is derived from task start dates, end dates, and dependencies. We export the underlying task date fields from KANNA and reconstruct the timeline in Asana's Timeline view using the Start Date and Due Date fields. KANNA dependency relationships (Finish-to-Start) map to Asana dependencies linked between Tasks.

KANNA's configurable project and task statuses are captured from the workspace settings and mapped to Asana equivalents. If KANNA uses a simple Open/Closed model, we map to a two-option custom field. If KANNA uses a multi-stage pipeline model, we create a single-select custom field with the stage values and optionally use Asana's Section to visually group tasks by stage within a project.

KANNA user accounts and task assignments are exported separately from the task records. We map each KANNA user to an Asana User by email address. Any assignee in KANNA with no corresponding Asana User account goes to a reconciliation queue for the customer's admin to provision before the migration runs, because task OwnerId cannot be set without a valid Asana User reference.

KANNA's approval flow feature has no direct Asana equivalent in the Starter or Free tier. Asana's Business tier supports approval workflows via Rules (record-triggered automations). We do not migrate KANNA approval flows as code. We document the approval chain (approver, approvee, approval criteria, notification) in a written inventory with recommended Asana Rule equivalents for the customer's admin to configure post-migration.