Migrate from Planview AdaptiveWork to Asana

AdaptiveWork Projects map to Asana Projects. All standard fields (name, description, start date, end date, status) transfer directly. Custom fields on Projects map to Asana Project-level custom fields by matching field type: picklist becomes enum, free-text becomes text, numeric becomes number, date becomes date. We pre-create custom fields in the destination Asana workspace before migration. Note that AdaptiveWork Business or Enterprise plan gating for certain entity types is confirmed during scoping; if the destination account uses Asana Free or Starter, only a subset of project-level features are available.

AdaptiveWork Tasks map to Asana Tasks within the mapped Project. The full task hierarchy (parent-child links) maps to Asana Subtasks under the parent Task. AdaptiveWork supports grandchild-level nesting (Tasks that are grandchildren of Projects through parent-child links); Asana supports one level of Subtask nesting, so we flatten grandchild Tasks as Subtasks of the immediate parent Task and flag this in the migration notes for the customer to review.

AdaptiveWork Milestones are standalone date-driven entities with dependency chain associations. Asana has no dedicated Milestone object type; the standard workaround is a Task with the Milestone checkbox enabled (Asana Business and Enterprise tiers only) or a date-type custom field marked as the milestone date. We map Milestone dates to the nearest Asana equivalent based on the destination account's tier. On Asana Starter or below, Milestone dates migrate as a date-type custom field on the mapped task with a 'Milestone' label.

AdaptiveWork predecessor-successor dependency chains map to Asana Dependency records (Start-to-Start and Finish-to-Finish types). Asana's dependency model requires a dependency to be explicitly added per task pair. We extract all dependency records from AdaptiveWork, build a dependency graph, and create Asana dependencies in the correct topological order. Circular dependency detection is performed during transformation; any circular chains are flagged for the customer to resolve before import.

AdaptiveWork Users map to Asana Users by email match. User name, email, and role transfer. AdaptiveWork working calendar definitions (regional calendars, personal working hours) have no direct Asana equivalent; these do not migrate. Assignment data on tasks migrates by resolving the AdaptiveWork user reference to the corresponding Asana User GID.

AdaptiveWork Time Entries track hours against Tasks and Projects with billing rates and approval workflows. Asana has no native time-tracking module. We map time entry data to numeric custom fields on the parent Task: hours logged, billing rate, and total cost become number-type custom fields. Approval workflows do not migrate and must be rebuilt as Asana Rules or a third-party time-tracking integration (Toggl, Harvest) post-migration.

AdaptiveWork financial line items (budget, actual costs, revenue, cost types, budget-vs-actual) migrate to number-type custom fields on the Asana Project. Currency fields migrate with the numeric value and a text field for currency code. Exchange rate handling is out of scope; the customer maintains the currency denomination in the custom field. Resource rate cards do not migrate as Asana has no rate card entity; these are documented for rebuild in a separate financial tracking tool.

AdaptiveWork custom fields across Projects, Tasks, and Milestones map to Asana custom fields by type equivalence. Picklist fields become enum fields, free-text becomes text, numeric becomes number, date becomes date, and user-reference becomes person. Note that Asana's custom field scope differs from AdaptiveWork: in Asana, a custom field is defined at the workspace level and then assigned to projects; in AdaptiveWork, custom fields are entity-specific. We pre-create the workspace-level custom field definitions before migration and attach them to the relevant projects. Free-text custom fields that appeared on AdaptiveWork hybrid view cards but not on standard views are flagged during scoping as a data-quality note.

AdaptiveWork resource capacity planning (workload distribution, skills, availability) has no direct Asana equivalent. Allocation data migrates as number-type custom fields on Tasks (e.g., allocated hours, utilization percentage). Asana's Workload view displays task assignments but does not calculate capacity against working calendars. Capacity-planning algorithms are platform-specific and must be rebuilt with a third-party tool or Asana Business/Enterprise workload configuration. We document the full capacity model for the customer's admin to implement.

AdaptiveWork documents are linked through SharePoint or Box connectors; the document references (URLs, share paths) can be extracted from AdaptiveWork, but actual file content must be transferred through the source document system. We do not migrate document files. The migration plan includes a document migration workstream flag with the list of document URLs and their associated Project or Task GIDs so the customer can execute the file transfer through SharePoint or Box admin tools separately.

AdaptiveWork Project and Task Templates encapsulate workflow structure, default fields, and pre-populated task skeletons. We export template definitions as a written inventory including task structure, default field values, and workflow rules. Templates cannot be migrated as reusable Asana templates because Asana templates are created manually by duplicating a Project. We deliver a template map so the customer's admin can create the corresponding Asana templates post-migration.

AdaptiveWork Workflow Rules automate actions based on criteria such as status changes, field updates, or date thresholds. Asana Rules (Business and Enterprise) provide trigger-action automation with a different model: triggers are limited to task status changes, due date shifts, and field changes; actions include assigning tasks, adding followers, moving tasks, and setting custom fields. We document all active AdaptiveWork Workflow Rules in a written inventory with trigger, conditions, and actions, plus a recommended Asana Rules equivalent. Workflow Rules are not migrated as code.