Migrate from Project.co to Asana

Project.co Projects map directly to Asana Projects. We extract project name, description, status, created date, and custom field values per project, then create a corresponding Project in Asana. The Project co value from Project.co migrates to the Asana Project's Notes or a custom field. Active and archived status maps directly; completed status translates to an archived Asana Project.

Project.co Tasks map to Asana Tasks with title, description (notes), assignee, due date, and status preserved. Task status in Project.co maps to the corresponding Asana section within the destination Project or to the task's completion state. Subtasks in Project.co are not a distinct object — we preserve the parent-child relationship by creating Asana subtasks under the migrated parent task. Task custom field values migrate to matching Asana custom fields on the task.

Project.co Discussions are per-project threaded message feeds. We flatten each thread as a chronological list of comments with author, timestamp, and body text, then attach each comment as an Asana Task comment on the corresponding migrated task. File attachments referenced in discussion threads migrate as separate file attachments on the task. The thread structure is not preserved as a distinct object in Asana; the chronological comment sequence on the task provides the equivalent content.

Project.co Notes are standalone rich-text documents attached to projects. We create an Asana Project or Task note with the same title, content, and project association. Rich-text formatting is preserved where the destination supports it; Asana task notes accept HTML-formatted content. The customer specifies during scoping whether Notes map to Project-level notes or to notes on the primary task within the project.

Project.co files stored in project-level folders are downloaded as binary content and re-uploaded to Asana with the same folder path maintained as the attachment target. We map file uploads to the corresponding migrated Project or Task. File metadata (uploader, upload date) is preserved in the upload attribution in Asana. Version history beyond the current file is not preserved as Asana attachments do not track revision history. The 100MB per-file limit in Asana applies; we flag any source files exceeding this threshold during scoping.

Project.co time entries (duration, date, billable flag, task association) map to Asana time tracking entries if the destination Asana organisation has a Premium tier subscription that includes time tracking. Duration and billable flag transfer; hourly rate data is absent in Project.co and is not migrated. If the destination Asana org is on a lower tier, time entries migrate as a custom field on the task (duration in minutes) and a boolean billable flag. The customer configures the hourly rate separately in Asana.

Project.co recurring tasks store a recurrence rule and next-run date. We create the task in Asana with the same title, description, assignee, and due date, then apply the recurrence pattern as an Asana native recurrence rule. The recurrence syntax differs between platforms; we convert Project.co's rule to the nearest Asana-supported recurrence pattern (daily, weekly, monthly, yearly) and flag any complex or non-standard recurrence patterns for manual verification during the sandbox migration.

Project.co custom field definitions (name, type, options) and values per Project and Task record migrate to Asana custom fields. We pre-create the custom field definitions in the destination Asana organisation before any data import, matching field names and types. Asana's single-select fields are capped at 500 options; we flag any Project.co fields exceeding this during scoping. Multi-select, number, date, and text types map directly. Note that removing a custom field value option in Asana does not remove existing values from tasks — this differs from Project.co's behaviour.

Project.co uses granular per-user roles scoped to individual projects. Asana does not support project-level per-user role assignments; access is controlled through Team membership and project sharing settings. We extract all role assignments per user per project during discovery and surface them in a written permission matrix. The customer's admin reconstructs the access model by adding users to the appropriate Asana Teams and configuring project sharing. Client portal access requires separate setup in Asana (Guest user type or external collaboration).

Project.co clients access projects via a client portal link and are not counted as paid seats. We create Guest user accounts in Asana for each migrated client and map their project invitations to Asana project sharing permissions. Client email addresses and names migrate; client-specific custom fields transfer if the destination custom fields exist. Asana Guest accounts have limited permissions and cannot access all Asana features; we document these constraints in the scoping report.

Project.co team member accounts (team members scoped to the project) map to Asana workspace members. We match users by email address during import. Any assignee without a corresponding Asana account is held in a reconciliation queue; the customer provisions the account before the relevant task import phase. Seats consumed in Project.co may differ from Asana seats because the two platforms price differently; this is surfaced during scoping but is a commercial decision for the customer.

Project.co file folders are a foldering layer within Projects used to organise file attachments. Asana does not have a native file folder concept. We map folder structure to Asana Sections within the Project, with a note in each Section description indicating the original folder name. File attachments attach to the relevant Section's primary task or to the Project directly. Large attachment libraries with deep folder hierarchies may require manual reorganisation in Asana post-migration.