Migrate from Planview Daptiv to Asana

Daptiv's portfolio hierarchy (parent portfolios with child portfolios, status rollup, and financial fields) maps to Asana Portfolio (Advanced tier) or to nested project groupings within a folder structure (Starter tier). We preserve parent-child relationships and any portfolio-level status fields as custom fields in the destination. If the destination org is on Asana Starter, we map the top-level Daptiv portfolio to a Team and lower-level portfolios to project folders, noting that cross-project rollup views are not available without the Advanced tier.

Daptiv Projects map directly to Asana Projects. Project-level fields including start date, end date, status, owner, and budget fields transfer 1:1. Daptiv workflow states are translated using the status mapping table generated during scoping so that records land in the correct completion or custom state rather than as null or default.

Daptiv Tasks map to Asana Tasks with dates, assignments, effort, and cost fields preserved. We map predecessor-successor relationships from Daptiv's Gantt dependency structure to Asana's depends_on and blocking dependency fields, preserving the task chain ordering. Daptiv subtasks map to Asana subtasks within the parent task.

Daptiv Resources (people with billing rates, skill assignments, and allocation percentages) map to Asana Users by email match. We capture every distinct billing rate value and store it as a custom numeric field on the corresponding Asana User record. Allocation percentages store as a custom allocation field on tasks or as a workload percentage if Asana Advanced with Workload Management is confirmed.

Daptiv Milestones are first-class objects carrying target dates and deliverable descriptions. We map them to Asana Tasks with the milestone flag enabled, preserving the target date and linking to the parent project. Milestone deliverables transfer as the task description in Asana.

Daptiv time entries linked to tasks and resources migrate as numeric effort fields (hours) on the corresponding Asana tasks. Time entry dates and descriptions preserve. If Asana Advanced with the Timesheets and Budgets add-on is active, we land entries as native timesheet records; without the add-on, time data lands as historical custom fields. The customer's admin confirms add-on status before migration scope is finalized.

Daptiv custom fields on projects and tasks map to Asana custom fields of the equivalent type (text, number, date, dropdown, checkbox). We inventory all custom fields during scoping and generate a field-mapping table before any import. Tenant-specific picklist values migrate as Asana dropdown options within the custom field.

DeskDocs files are extracted as binary blobs and re-associated to the correct Asana task or project via the Asana Attachments API. We use file naming conventions or DeskDocs metadata to match each file to its parent record. This step requires the task and project records to be present in Asana first so that GIDs are available for attachment linkage; it runs in parallel with or after record migration.

Daptiv allocation percentages and demand-vs-availability data map to Asana Workload Management (Advanced tier) or to a custom numeric allocation percentage field on tasks. We flag any rounding differences in percentage precision. Asana's workload view shows allocation against task assignments but does not compute against billing rates without a custom integration.

Daptiv's planned cost (derived from assigned billing rates and resource effort) migrates to a custom numeric field on the project in Asana. Asana's native project budgeting is available via the Timesheets and Budgets add-on on Advanced tier; we document the activation and configuration steps for the customer's admin. Without the add-on, cost figures land as read-only historical custom fields.

Daptiv's configurable workflow statuses vary by tenant. We collect the complete status vocabulary during discovery, build a translation table, and translate statuses to Asana Sections within a project or to a custom status field. Records land in the correct state rather than as null or default, preventing tasks from appearing in an unintended completion state after migration.

Daptiv dashboards and saved report definitions are tightly coupled to its data model and reporting engine. We do not migrate dashboard configurations. We deliver a written inventory of each dashboard's key metrics, data sources, refresh cadence, and recommended Asana equivalents (Portfolio views, custom fields, connected BI tools) for the PMO to rebuild post-migration.

Daptiv project owners and task assignees map to Asana Users by email match. Any Daptiv owner without a matching Asana User is held in a reconciliation queue for the customer's admin to provision before record import resumes. Owner mapping must complete before task migration begins because OwnerId is a required reference on many standard objects.