Migrate from Nozbe to Asana

Nozbe Projects map directly to Asana Projects. We extract the project name, color label, completion status, and member visibility from the Nozbe JSON and set these as Asana Project fields (name, color, is_public). Project Groups from Nozbe Classic become Asana Portfolios if multiple related projects need cross-project tracking. Nozbe's private project flag maps to Asana's team-scoped access controls.

Nozbe Tasks map to Asana Tasks. The Nozbe due_date maps to Asana due_on, done (boolean) maps to completed (boolean), priority maps to a custom Priority picklist field since Asana uses a numeric importance/urgency matrix rather than a named priority label, and the task creator maps to the Asana created_by reference. Assignee resolution runs by email match against the Asana workspace User list.

Nozbe does not have a native subtask object, but Asana supports one level of subtask nesting. If the Nozbe export contains nested task structures (task-within-task), we flatten the hierarchy and map the inner task as an Asana Subtask under the parent. Recursion beyond one level of nesting is not supported by Asana's API and is documented for manual reconstruction.

Nozbe stores recurrence as a rule on the Task object. Asana's CSV Import Wizard does not preserve recurrence rules on import. We must expand each recurring task into a series of individual Tasks with explicit due dates. A task with a biweekly recurrence over three years generates 78 individual tasks, which can inflate task counts substantially. We flag this during scoping and offer two paths: expand all recurrences into individual Asana Tasks, or store the recurrence rule as a custom Recurrence_Rule__c text field on the first task instance.

Nozbe Comments are threaded under Tasks as the primary communication mechanism. We preserve the full comment history under each Task in Asana as Subtask Comments (Asana's native comment structure on Tasks). Author email, timestamp, and @mentions carry over. Nozbe file attachments embedded in comments migrate as attachment links in the Asana comment body. Comment ordering by timestamp is preserved by insertion order during the CSV load.

Nozbe Tags are a flat label list per workspace and map directly to Asana Tags. The tag name becomes the Asana Tag name. If Nozbe Classic export does not include the full tag list (it is sometimes excluded from the JSON backup), we scrape the workspace tag list from the Nozbe web UI during scoping. We flag any tags not recoverable from either path and recreate them as Asana Tags from task references.

Nozbe Categories are part of its GTD implementation (e.g., @calls, @home, @work contexts) and have no native equivalent in Asana. We map Categories to Asana Tags using a naming convention (Category name prefixed with @) so that the GTD context is visible and filterable in Asana. Teams relying heavily on Categories should define a consistent naming scheme during scoping because Asana Tags have no native grouping or hierarchy.

Nozbe attachments stored in comments and projects migrate as external URL links attached to the corresponding Asana Task or Subtask Comment. Nozbe Classic export includes attachment URLs. We validate each URL during migration and flag any that return 404 or are no longer accessible. Large binary file uploads (e.g., PDFs over 100MB) may exceed Asana's file size limit and require alternative storage with a link left in the task.

Nozbe Inbox is a GTD capture zone for unsorted tasks with no equivalent in Asana. We migrate Inbox items as Asana Tasks placed in the Inbox view without a project assignment, preserving the original capture timestamp. Assignee remains unset on migrated Inbox items because they represent items awaiting GTD processing rather than assigned work.

Nozbe Team Members are matched to Asana Users by email address during scoping. We generate a member mapping table and invite any matched Asana users to the destination workspace. Members without an existing Asana account are flagged in a reconciliation queue for the customer admin to provision before the final migration phase begins.

Nozbe Business Spaces (enterprise-only organisational unit in new Nozbe) do not have a direct Asana equivalent because Asana uses a single Workspace per organisation. We map all Business Spaces into one Asana Workspace, using Asana Teams to differentiate business units. If the customer has more than one Business Space and requires strict data separation, we recommend consolidating under one Workspace with Team-scoped access controls.

Nozbe Project Templates do not migrate to Asana as reusable templates. We document the template structure (project name, default task list, and any default assignees) in a written handoff sheet so the customer's admin can recreate the template in Asana. Template recreation is out of scope for the standard migration engagement.