Migrate from Asana to Microsoft Project

Each Asana Project maps to one Microsoft Project plan. We export project name, description, default view configuration, color, and archived status. In Project for the Web, the plan becomes a Microsoft Planner bucket or a standalone Project plan. In Project Desktop, it becomes an MPP file. We preserve the Asana project GID in a Project custom field (Asana_GID__c) for audit tracing. Multi-project portfolios map to separate MPP files linked via a Project professional template rather than a native portfolio object.

Asana Tasks map directly to Microsoft Project Tasks. Standard fields (Name, Notes, Start Date, Finish Date, Assignee, Due Date, and completion status) map to their Project equivalents. Asana's completed_at timestamp becomes the Actual Finish date in Project. We set Task Mode to Auto Scheduled by default and flag any tasks with manually set start dates for the customer to review, since manual scheduling in Project can break the dependency chain.

Asana Subtasks map to child rows in the Project WBS hierarchy. We flatten subtask nesting to a maximum of three outline levels (Section = WBS level 1, Task = WBS level 2, Subtask = WBS level 3) to ensure all rows render correctly in Project's Gantt and sheet views. Deeply nested subtask chains beyond WBS level 3 are consolidated as notes on the level-3 row with a prefix indicator. We flag any subtask that lacked a project association in Asana (orphaned subtasks) for explicit confirmation before including them in the import.

Asana Sections become Project Summary Tasks at the top of each outline group. We map the section name to the summary task name and preserve the task ordering within each section. In Project for the Web, sections map to plan buckets with individual tasks as bucket items, which the customer can then restructure as tasks within a Gantt timeline. Section colors are not natively supported in Project and are documented as a post-migration styling preference.

Asana custom fields of type Text, Number, and Date map to identically-typed Project custom fields. Text fields become Text custom fields in Project; Number fields become Number custom fields; Date fields become Date custom fields. We preserve the field name and any enum color coding as a note in the migration manifest. Custom field values attached to subtasks carry through to the corresponding WBS child row in Project. Formula and Rollup fields in Asana have no direct equivalent in Project and are converted to read-only notes fields with a 'Calculated in Asana — value at export date' label.

Asana Enum (dropdown) custom fields map to Project drop-down custom fields. We export all enum option names and map them to Project's drop-down value list. The Asana enum option color coding is not available in Project and is documented as a post-migration formatting preference. If enum options have been renamed over time, only the current option name migrates; historical option labels are not preserved per Asana's API behavior.

Asana task dependencies use GID references with dependency_type (predecessor/successor). We preserve the full dependency graph and reconstruct it in Project using the target platform's format. Project for the Web accepts Finish-to-Start only; any Start-to-Start, Finish-to-Finish, or Start-to-Finish dependencies from Asana are converted to FS with a lead or lag time (in days) and flagged for the customer's PM to verify the schedule behavior. Project Desktop supports all four dependency types natively. We output a dependency audit report listing every converted link and its lag calculation.

Asana attachments include both files uploaded directly to Asana (stored at attachments.docker.asana.com) and external links (Google Drive, Dropbox, Box). We resolve direct uploads by downloading the file and re-linking via a local file path or SharePoint URL. External links migrate as URL custom fields pointing to the original document. Attachments stored in Google Drive or Dropbox without shareable links cannot be migrated without explicit re-authorization from the document owner and are flagged as a manual-recreate step.

Asana comments are stored as Stories linked to tasks. We export comment text, author, and created_at timestamp. HTML formatting in comments is sanitized to plain text for Project. Whether comments migrate to Project depends on the destination format: for Project Desktop MPP files, comments become task notes with a [Comment] prefix. For Project for the Web, comments have no native equivalent and are documented in the migration manifest as a manual-recreate item. We recommend the customer decide during scoping which approach applies.

Asana Tags are flat cross-project labels applied to tasks. We export all tag names and apply them to Project as a text custom field (Tags__c) with comma-separated values. If the customer uses tags for categorization rather than scheduling, we offer an alternative mapping to Project's Outline Number structure where tag categories become WBS prefix codes. Tag color coding is not available in Project and is documented as a formatting preference for the customer's admin.

Asana Users map to Microsoft Project Resources. We resolve by email match. Resource names, email addresses, and profile photo URLs migrate as Resource properties. If Asana users have no email (guests with display names only), they are mapped to generic resources with an Asana_Guest__c flag. Resource rates and calendar availability do not exist in Asana and must be entered manually in Project or provisioned via a Resource Engagement in Project for the Web. Team membership lists are documented as a resource grouping recommendation in the migration manifest.

Asana Portfolios aggregate multiple projects for executive dashboards but hold no independent data beyond the project membership list and owner. Microsoft Project has no native portfolio object. We export the full portfolio membership list (project names and GIDs) and owner, and deliver it as a structured manifest for the customer's PMO to recreate groupings using SharePoint folders, Project for the Web workspaces, or a Power BI portfolio dashboard. Portfolio recreation is a post-migration administrative step, not part of the data migration scope.