Migrate from Advantage to Asana

Advantage custom objects (defined in Schema Manager with fields, pick lists, and relationships) map to Asana custom fields. We pre-create the Asana field library with global fields where the customer requires cross-project consistency, and local fields where the data is project-specific. Pick list values from Advantage migrate as Asana enum options. Relationships between custom objects in Advantage are not natively supported in Asana — we document relationship types and recommend a lookup strategy (using a text field with the related record name) for the customer's admin to evaluate.

Advantage Projects map directly to Asana Projects. Project name, description, start date, target end date, and status migrate as Project fields. Project-level settings (visibility, notification preferences) are set during import. We preserve project hierarchy if Advantage uses nested project structures by mapping to Asana portfolios or section groupings.

Advantage Tasks map to Asana Tasks with title, description (rich text), due date, start date, and status preserved. Task notes migrate as the task description field. Completed status and completion timestamps carry over. We set the project association during import so tasks land in the correct Asana project.

Advantage subtasks nested under tasks migrate as Asana Subtasks. The parent-child relationship is preserved by setting the parent Task as the subtask's parent during import. Asana supports one level of subtasking (subtasks of subtasks are not supported natively — we flatten to a single level.

Advantage custom fields attached to projects migrate as Asana custom fields on the corresponding project. We map field types: text fields become Asana Text fields, number fields become Number fields, date fields become Date fields, and pick list fields become Asana Enum fields with the original options preserved.

Advantage custom fields attached to tasks migrate as Asana custom fields on the corresponding task. We match the field name and type, and set field values on each migrated task. If a global field with the same name exists in the Asana organization, we use it to maintain cross-project consistency.

Advantage user records (owners, assignees) resolve by email match against the Asana organization's member list. We extract all distinct owner IDs and assignee IDs from Advantage records and match them to Asana members. Any Advantage user without a matching Asana member goes to a reconciliation queue for the customer admin to provision before record import resumes.

Advantage tasks with a single assignee map directly to an Asana task assignee. The assignee is resolved via the user email lookup. This is the cleanest mapping path and requires no reconciliation.

Advantage tasks with multiple assignees require a split strategy. Options include: (1) assign to the primary owner and add secondary owners as task followers, (2) duplicate the task for each assignee. We agree on the strategy during scoping based on the customer's reporting and visibility requirements. The chosen strategy applies across all multi-assignee tasks in the migration.

File attachments linked to Advantage tasks and projects migrate as Asana Attachments. We preserve the file name, URL (if stored externally), and the association to the parent task. Files exceeding 100MB in size are flagged and skipped per Asana API constraints — we document each skipped file in the migration report for the customer to handle manually. Image attachments inline in task descriptions migrate as part of the rich text body.

Comments on Advantage tasks and projects migrate as Asana Comments with author and timestamp preserved. We use the author's email to match to the Asana member, and set the comment body and creation timestamp. Comment attachments are handled under the attachment mapping.

Advantage automation rules (triggers, conditions, and actions defined in the Admin Console) do not migrate as code. We export a written inventory of every active rule with its trigger type, conditions, and action sequence. We map each rule to an Asana Rule equivalent (trigger-action pairs) and document the specific Asana Rules configuration steps. The customer's admin rebuilds the rules in Asana post-migration.