Migrate from Kantree to Asana

Kantree Workspaces map to Asana Organizations as the top-level container. Each Kantree workspace's settings (color theme, default view preferences) are documented as a configuration note for manual setup in Asana. Teams within the Organization are created to mirror Kantree project groupings if the customer uses project-level team assignments. Organization-level settings (branding, domain verification, SSO) are applied after workspace migration.

Kantree Projects map 1:1 to Asana Projects. Project metadata (description, color tag, dates) transfers directly. Kanban column groups in Kantree map to Sections in Asana List view. Projects are created in Asana before card import so that the project membership and default view settings are available at task insertion time.

Kantree Cards map to Asana Tasks with all standard fields (title, description, assignees, start date, due date, status) preserved. Card IDs are stored in a custom field kantree_card_id__c on the Asana task for audit traceability. Sub-cards in Kantree map to Asana Subtasks using the parent task reference. Card priority and rating fields map to custom number or enum fields in Asana.

Kantree card types (Bug, Feature, Invoice, Patient, etc.) define the available field schema per card category. We export the card-type schema and recreate it in Asana as a set of project-scoped custom fields. On Asana Business and Enterprise tiers, custom fields can be made organization-wide and applied across projects, which preserves consistency. On Starter and Professional, fields are project-scoped and must be added per project.

Kantree's 20+ field types map to Asana equivalents: text to text, number to number, date to date, single-select to enum, multi-select to multi-enum, user reference to people, rating to number with visual scale. Card reference fields require special handling: they resolve to a task dependency in Asana (marked as blocking or dependent) and the referenced card's Asana task gid is stored in a custom field.

Kantree formula fields compute dynamically from related field values at read time. We export the last-known computed value as a static custom field in Asana during migration, and document the original formula logic for the customer to recreate using Asana Intelligence (Business and Enterprise tiers) or a third-party formula app. The customer chooses during scoping whether to store migrated values as static fields or invest in formula recreation.

Kantree's seven native views are exported as view definition records. In Asana, each project supports List, Board, Calendar, Timeline, and Gantt natively. Matrix view has no direct Asana equivalent — we document the Kantree matrix configuration (row grouping, column grouping, cell aggregation) as a manual setup guide for the customer. Workspace-wide view consistency in Kantree translates to portfolio or team-level view templates in Asana Business and Enterprise.

Kantree supports one-to-one, one-to-many, and many-to-many card relationships defined at the workspace level. We export relationship records as structured link data and recreate them in Asana as task dependencies (marked as blocking or dependent-on). Multi-hop relationship chains are flattened to direct dependencies where the Asana dependency model requires it.

Kantree comments attached to cards migrate to Asana task comments preserving author, timestamp, and rich text content. The 2-hour edit window from Kantree is not enforced in Asana — comments are imported as static history. Author attribution uses email matching against the migrated Asana user list.

Kantree card attachments migrate to Asana task attachments. File metadata (filename, size, mime type, upload timestamp) is preserved. Files under 100MB use Asana's REST API attachment endpoint. Files exceeding 100MB are flagged for manual upload because the Asana API rejects attachments above this threshold. The customer receives a list of oversized files with upload instructions.

Kantree Forms capture submitted field values, submitter info, and timestamp. We export form definitions and submission records as structured JSON. Asana Forms are a separate feature that must be created manually in the destination — we deliver a form recreation guide mapping each Kantree field to its Asana form field equivalent. Submissions are imported as tasks with a custom field tracking the original form source.

Kantree Reports display aggregated workspace and project statistics as configuration artifacts rather than stored datasets. We export report definitions (filters, groupings, displayed fields) as a written specification. Asana's portfolio and dashboard features replace Kantree Reports on Business and Enterprise tiers. The customer rebuilds reports using the FlitStack AI specification as a reference guide.

Kantree members map to Asana users by email match. Kantree observers (free but read-only) map to Asana members on the paid tier — note that Asana does not have an observer equivalent, so any Kantree observer granted edit access by being converted to a full member will become a billable Asana seat. We flag this distinction during scoping so the customer controls which accounts consume a paid seat at the destination.

Kantree workspace and project-level permissions (card edit, comment moderation, field visibility, view sharing) are exported as role assignment records. Asana's permission model uses Organization roles (Admin, Member, Guest) and project-level membership (Full Member, Guest). We map Kantree workspace roles to Asana Organization roles and project permissions to Asana project membership levels, noting where the semantic difference requires admin review post-migration.