Migrate from awork to Asana

awork Projects map 1:1 to Asana Projects. The awork project name, description, start date, and end date migrate directly. awork's project status (per-workspace custom vocabulary) requires a value map because Asana uses global On Track, At Risk, and Off Track statuses rather than custom names. We collect the full workspace status schema during discovery and apply the mapping during the load step. If the destination Asana org uses Teams, we group migrated projects under the appropriate Team based on the awork workspace or client association.

awork Tasks map directly to Asana Tasks. Assignee, due date, description (rich text), and task status migrate as native Asana fields. The awork project assignment maps to the Asana project membership. Tasks that belong to no project in awork (standalone tasks) require a decision during scoping: either create a catch-all Asana project for them or exclude them from the migration scope.

awork workspace Users map to Asana Users. We match by email address during migration. Any awork User with no matching Asana User is held in a reconciliation queue for the customer's admin to provision before record import begins. User display name, email, and role migrate as profile fields.

awork Custom Fields require per-project activation before they appear at the task level. We audit every custom field's project-level activation status during scoping and flag any gap where a field exists at the workspace level but is not active in a given project. For migrated projects, we replicate the same field configuration as active custom fields in Asana, using text, number, date, or multi-select picklist types matched to the awork field type. Fields inactive in awork for a given project are not created in Asana for consistency.

awork Tags are key-value labels applied to Tasks. They map directly to Asana Tags. Tag names migrate as-is. If Asana enforces any tag naming restrictions, we normalize during the transform step before loading.

awork Time Entries carry billable/non-billable flags, user attribution, start/end timestamps, and task association. Asana does not have a native time tracking object. We preserve time entry data by creating custom fields on Asana Tasks: total_hours (number), billable (checkbox), and tracked_date (date). For detailed time logs, we attach a structured Note to the task with the time entry table. The customer's admin can connect a third-party time-tracking integration (Harvest, Toggl, Timely) post-migration to replace this for ongoing tracking.

awork Project Templates define reusable task structures, default statuses, and custom field configurations. Asana supports Project Templates natively only on Business tier ($24.99/seat/mo). For Premium or Personal tiers, we document the template structure as a written deliverable and recommend manual project duplication or Asana's duplicate-project workflow as the replacement. We migrate the template definition as a JSON manifest and a descriptive record for the customer's admin to use as a rebuild reference.

awork Subtasks are structured child objects of Tasks. They map directly to Asana Subtasks. The parent-child relationship is preserved. If subtask ordering is critical, we include a sort_order field in the migration payload so the destination maintains the original sequence.

awork allows each workspace to define a custom set of project statuses with distinct names, colors, and ordering. These have no global equivalent in Asana, which uses three fixed status options. We collect the full status vocabulary during discovery, build a value map to the nearest Asana global status (On Track, At Risk, Off Track), and apply the mapping during load. The original awork status name is preserved in a custom field original_awork_status__c on the project for audit and reporting.

awork has a distinct Client object above Project in the hierarchy. Asana does not have a native Client object. For teams that rely on client billing or client-level reporting in awork, we recommend creating an Asana Team per Client and grouping Projects under that Team. The customer decides during scoping whether to create Teams per client or to use a project name prefix convention.

awork Notes attached to Tasks or Projects migrate to Asana Notes. Rich text content, attachment references, and user attribution (author) migrate. If awork notes include file attachments, those become Asana attachment links pointing to the original URL.

awork internal task-type engagements map to Asana Tasks within the same project. Status, assignee, due date, and description migrate directly.