Migrate from QuickStart Admin to Asana

QuickStart Admin Projects map to Asana Projects as the top-level container. We probe the customer's live instance during discovery to confirm that Projects are the root object and that no additional grouping layer (portfolios, programs, workspaces) exists in QuickStart Admin before mapping. If the source exposes a workspace or division concept, it maps to an Asana Team or Organization structure. Project-level custom fields from QuickStart Admin migrate to Asana Custom Fields scoped to the project or added as portfolio-level fields.

QuickStart Admin Tasks map to Asana Tasks with a direct name, description, due date, and status mapping. QuickStart Admin's status labels (e.g., Open, In Progress, Complete) are mapped to Asana's task completion state (completed: true/false) and the Asana custom field structure if a status field is implemented. Task notes and description fields migrate as the Task body in Asana.

QuickStart Admin subtasks are expected to exist as hierarchical task records. We flatten them to Asana Tasks with a parent_task GID reference. Asana does not support recursive nesting beyond one level of subtask, so any deeply nested QuickStart Admin structure is preserved as a chain of parent-child Task references. We check for circular parentage during discovery and flag any data anomalies before migration.

QuickStart Admin assignee IDs are resolved against the Asana user directory by email match. We extract every distinct assignee email from the source data and provision matching Asana user accounts before record import. Any assignee without an Asana user account goes to a reconciliation queue for the customer's admin to provision. Orphaned assignments — where a QuickStart Admin task references a user email that cannot be resolved — are logged as exceptions and migrated as unassigned tasks pending admin review.

QuickStart Admin custom fields are discovered during the pre-flight audit: we infer field names from the customer's export headers and sample data, and deduce data types (text, number, date, picklist) from the values. We then create corresponding Asana Custom Fields via the Asana Custom Fields API before populating any values, because Asana requires the field resource to exist before data can be written to it. Asana Custom Fields are created as enumerations (single-select, multi-select), text, number, or date based on the inferred source type. Custom field values are written to tasks after the parent Task records are inserted.

QuickStart Admin comments on tasks map to Asana Story records. Stories in Asana capture the comment text, author (by email lookup to the Asana user directory), and created_at timestamp. Rich-text formatting in QuickStart Admin comments is simplified to plain text during migration. Story records are inserted after parent Task records using the Asana Stories endpoint.

QuickStart Admin file attachments are a discovery dependency. If QuickStart Admin exposes an export mechanism for binary files or file URLs, we migrate attachments as Asana Attachments using the attachment upload API (100 MB limit per file). If no file export mechanism is confirmed during discovery, we document the constraint and migrate task-attachment references as text notes containing the original file URL or filename for manual re-attachment post-migration. We do not guarantee binary file transfer for this platform.

QuickStart Admin user accounts map to Asana Organization Members. We extract user records by email as the unique identifier. Display name, role, and status from QuickStart Admin are preserved as custom fields on the Asana User profile if accessible. If QuickStart Admin exposes a permission or role model, it is documented in the migration scope and mapped to Asana Admin, Member, or Guest roles where the equivalents exist.

QuickStart Admin task sections or groupings — if present in the export — map to Asana Sections within a Project. Sections in Asana are ordered containers that group tasks without being records themselves. We map the section name and task order from the source to the destination section structure. If QuickStart Admin uses a tag or label model instead, those map to Asana Tags as a multi-purpose tagging mechanism.

QuickStart Admin tags or labels on tasks migrate to Asana Tags. Tags in Asana are organization-wide and can be applied across projects, which provides flexibility that may exceed QuickStart Admin's tag scoping. We extract distinct tag values from the source and create corresponding Asana Tags before inserting tag assignments on tasks.

QuickStart Admin created date, last modified date, and any custom timestamp fields migrate to Asana Task created_at and modified_at fields. Asana does not allow direct writes to created_at; we set start_at for tasks where a planned start date exists in QuickStart Admin, and due_date for due dates. Historical activity timestamps are preserved in Story records.

Automations, workflow rules, or triggers in QuickStart Admin are not migrated as code. We document every observed automation during the discovery audit — including trigger conditions, actions, and any scheduling logic — in a written inventory delivered post-migration. The customer's admin rebuilds these as Asana Rules using Asana's automation builder. Automations that rely on third-party integrations not present in Asana require an integration audit to determine a replacement approach.