Migrate from CONTACT Project Office to Asana

CONTACT Project Office Projects map directly to Asana Projects within the target Workspace. We extract project metadata (name, description, status, start date, due date) and create the corresponding Asana Project via the POST /projects endpoint. If the source uses a hierarchical folder or program structure above the project level, we map the top-level program to an Asana Portfolio and the child projects under it. Project color and icon settings in CONTACT have no direct Asana equivalent and are noted for admin configuration post-migration.

CONTACT Project Office Tasks map to Asana Tasks linked to the parent Project via the projects array. Standard task fields (name, description, start date, due date, priority, status) map to Asana's name, notes, start_on, due_on, and custom fields for priority. Assignee resolves via the User mapping by email lookup and sets the Asana assignee field. Tasks without a valid assignee are created as unassigned and flagged in the reconciliation report.

CONTACT Project Office Subtasks map to Asana Subtasks by creating the task under its parent via the parent gid field. Asana supports one level of subtasking; if the source has sub-subtasks or deeper nesting, we flatten them to the first-level subtask level and flag the remainder in the reconciliation report for manual rebuild as separate tasks. The subtask's assignee, dates, and notes migrate identically to a standard task.

CONTACT Project Office Users and Assignees map to Asana Workspace Members by email match. We extract all distinct user emails from the source data (task assignees, project leads, comment authors) and match them against the destination Asana Workspace membership. Any email without a matching Asana User goes to the provisioning queue for the customer's admin to invite before record migration proceeds. User display name and role/title migrate as custom fields if the source includes this data.

CONTACT Project Office Custom Fields require manual extraction and type inference from the source data because there is no documented API field model. We inspect the extracted values to classify each field as text, number, enum (single-select), multi-enum (multi-select), date, or Boolean. We pre-create the corresponding Asana Custom Field definition in the target Workspace via POST /custom_fields, then associate it with the target Project via a Custom Field Setting. Enum and multi-enum options migrate with their labels intact.

CONTACT Project Office file attachments are extracted from whatever export format the customer can produce (exported zip, linked file URLs, or file references in the data dump). We re-upload each file to Asana via the POST /tasks/{task_gid}/attachments endpoint using the multipart/form-data upload method. File name, size, and resource subtype (document, image, spreadsheet) are preserved. If the source stores only URLs rather than file content, we create an Asana attachment with the original URL as a link attachment.

CONTACT Project Office Comments map to Asana Stories on the parent task. The comment body migrates as the story's text field; the author timestamp and author name migrate from the source comment metadata. Asana Stories are immutable once created, so we create them read-only on the target task. Rich text formatting (bold, italic, hyperlinks) in source comments attempts to map to Asana's supported HTML subset; unsupported formatting is stripped and noted in the reconciliation report.

If the CONTACT Project Office export includes task groupings or sections, these map to Asana Sections within the parent Project. We create sections via POST /projects/{project_gid}/sections and then move tasks into their respective sections via the move task endpoint. Section ordering is preserved by setting the section's created_at timestamp from the source sequence.

CONTACT Project Office Milestones map to Asana Tasks with the custom field or marker set to indicate milestone status. Asana's native milestone feature is project-scoped; we create a task in the project, set its due date to the milestone date, and configure a custom field dropdown with a 'Milestone' option if the customer's Asana plan supports custom fields. If no custom fields are available on the plan, we use a 'milestone_name' prefix in the task name for identification.

CONTACT Project Office Project Leads map to Asana Project Members with Editor-level permissions. We extract project-lead assignments from the source data and add the corresponding user as a project member via POST /projects/{project_gid}/addMembers. If the source distinguishes between lead and member roles, leads receive Editor access and general members receive Commenter or Viewer access based on the source role.

CONTACT Project Office Tags or labels migrate to Asana Tags on the parent task. We create tags via POST /tags and associate them with tasks via POST /tasks/{task_gid}/addTag. Tag colors from the source map to Asana tag color names where possible; unmapped colors default to 'none'. Tags used for categorization in the source are preserved as-is on the task.

CONTACT Project Office task dependencies (finish-to-start, start-to-start) do not have a direct Asana API equivalent without third-party tools. We capture the dependency relationship as a custom text field on the dependent task (e.g., 'Depends on: [Task Name]') and flag the dependency for the customer's admin to rebuild using Asana's native dependency feature (available on Advanced and Enterprise plans) or a compatible integration post-migration.