Migrate from ProjectManager to Asana

ProjectManager Workspaces map to Asana Teams. The Workspace name and description carry over as the Team name and team bio. Workspace-level permissions in ProjectManager map to Asana team membership with the closest matching permission level (Member, Admin, Guest). We extract all distinct Workspace memberships from the source and provision matching Asana team memberships during migration.

ProjectManager Projects map directly to Asana Projects. The project name, description, start date, end date, and status carry over. ProjectManager's dynamic scheduling flag (whether the project uses auto-scheduling) does not have an Asana equivalent; we note this per project and advise the customer to review the project timeline in Asana after migration. ProjectManager custom ProjectFields migrate as Asana project-level custom fields.

ProjectManager Tasks map to Asana Tasks with parent-child hierarchy preserved as subtasks. TaskStatus values (Not Started, In Progress, Completed, On Hold) map to Asana TaskStatus equivalents. The task name, description, start date, due date, and completion status carry over 1:1. Dependencies in ProjectManager (Finish-to-Start, Start-to-Start, Finish-to-Finish) map to Asana Dependencies (Waiting On, Blocked By) as task-level links. Because Asana does not auto-cascade dates through dependency chains, we document every dependency chain during discovery and attach the chain as a formatted note on the lead task of each chain for the customer's PM to rebuild manually in Asana.

ProjectManager ProjectFields are custom properties scoped to the Workspace. We discover existing ProjectField definitions via GET /api/data/projects/fields, then create matching Asana custom fields via POST. Field types (string, number, date, choice) map directly to Asana custom field types. Whether the migrated field is global (org-wide) or project-local depends on the reuse scope defined during discovery. Choice fields with options migrate as picklist custom fields with all options preserved.

TaskFields in ProjectManager follow the same two-step API process as ProjectFields (schema definition then value write). We run this pipeline for each task field, respecting the per-project field attachment in Asana. Not all ProjectManager field types have native Asana equivalents; formula fields and calculation fields require manual rebuild as Asana custom formula fields (available in Asana Advanced+). Fields with no equivalent are flagged for the customer to configure post-migration.

ProjectManager allows multiple TaskAssignees per task, driving the workload view. Asana permits one assignee per task. We assign the primary TaskAssignee to the Asana Task directly and convert additional assignees to subtasks named '[Assignee Name] — supporting task', with the additional assignee assigned to the subtask. This preserves every assignment while satisfying Asana's one-assignee constraint. The full assignee list is also written to a multi-select custom field assignee_list__c for reference.

ProjectManager Resources (team members or equipment) map to Asana Users. We match Resources to Asana Users by email address during owner reconciliation. Resource availability windows and cost rates do not have native Asana equivalents; if the customer requires this data post-migration, we create custom fields resource_availability__c and resource_hourly_rate__c on the User profile and recommend a resource management add-on for ongoing workload heat-map functionality.

ProjectManager ResourceTeams group Resources for scheduling and workload reporting. These map to Asana Teams independently from the Workspace-to-Team mapping. We preserve ResourceTeam memberships and cross-reference with TaskAssignees during migration to ensure the assignee relationship is accurate in Asana. If ResourceTeams overlap with Workspace groupings, we use the ResourceTeam as the source of truth for team membership and consolidate if the customer confirms overlap during discovery.

ProjectManager Risks are standalone objects linked to Projects with severity, status, and RiskFiles. Asana has no native Risks object. We create a risk_severity__c and risk_status__c custom field on the project for each open Risk, and migrate the Risk description as a dedicated task named '[Risk] Risk: [title]' with the severity, status, and linked ProjectId in custom fields. Closed risks are migrated as completed tasks in a Risk Review section. RiskFiles attach to the risk task as Asana attachments subject to the 100MB per-file limit.

Timesheets record actual hours logged by Resources against Tasks. ProjectManager embeds billing rates in some historical Timesheet records, which do not map directly to Asana's data model (Asana does not have a native timesheet object at base tiers). We migrate the hours logged as a custom field timesheet_hours__c on the linked Task for each Timesheet record. Billing rates are flagged during discovery; customers choose to migrate hours only or attempt rate reconciliation with the understanding that rates may require manual cleanup post-migration.

ProjectManager Tags and TaskTags are lightweight labeling objects used for categorization. These map to Asana Labels with the tag name preserved. Label color assignment in Asana is not deterministic from ProjectManager's tag colors; we assign default colors and the customer can reorganize post-migration. Tag counts exceeding Asana's label-per-organization limits (500 labels) are flagged during discovery.

ProjectManager UserRoles define permissions within a Workspace. Asana's team permission model is simpler (Admin, Member, Guest). We map source permission profiles to the closest Asana built-in role and flag any custom roles that have no direct equivalent. Customers requiring fine-grained role-based access control in Asana should plan for a permission audit post-migration; Asana Enterprise offers advanced permission controls beyond team roles.

ProjectManager dependency types (Finish-to-Start, Start-to-Start, Finish-to-Finish) map to Asana 'Waiting On' (Finish-to-Start) and 'Blocked By' relationships. We import dependency links via the Asana Dependencies API. However, because Asana does not auto-recalculate downstream dates when upstream task dates change, we also generate a dependency chain document during discovery that lists every chain of three or more tasks connected by dependencies. This document is delivered as a task note on the lead task of each chain so the customer's PM can manually verify and reconstruct the schedule logic in Asana.