Migrate from TaskRay to Asana

TaskRay Projects map directly to Asana Projects. Each Project in TaskRay carries a name, description, status, start date, target end date, custom fields, and file attachments. We export via Salesforce REST API, map dates to Asana's due_date and start_date fields on the Project, and create the Project in Asana before importing any child records. TaskRay project-level Chatter threads do not migrate; we flag thread content as a written attachment inventory for manual re-posting if the conversations contain action items.

TaskRay Sub-Projects are child records of Projects and can contain their own Task Groups and Tasks. When the source hierarchy is two levels deep, we create a corresponding Asana Project and nest it inside the parent Project using Asana's section or subgroup structure. When Sub-Projects exceed the two-level depth limit in TaskRay, we flatten deeper children at export time and warn the customer that original nesting depth will be reduced. Asana does not support multi-level project nesting beyond one level of sections, so deeply nested TaskRay structures require a flattening strategy agreed upon during scoping.

TaskRay Task Groups represent phases or thematic groupings within a Project and map cleanly to Asana Sections. We preserve the TaskGroup-to-Project parent linkage by creating Sections inside the corresponding Asana Project before importing child Tasks. Task Group descriptions migrate as Section descriptions in Asana. Custom fields on TaskGroup records migrate as custom fields on the Section, though Asana Sections do not natively support custom fields — these attach to the first Task in the Section or become project-level custom fields per customer preference.

The core work unit maps directly to Asana Task. We preserve task name, description (rich text), due date, start date, assignee, blocked and locked states (via custom fields), repeating flags (as custom fields or Notes), and predecessor links. Checklist containers migrate separately as subtasks. Custom fields on TaskRay Task objects map to Asana custom fields, which must be pre-created in the destination project because Asana enforces a project-level custom field model. Status mapping depends on the TaskRay status field values and the Asana workflow chosen during scoping.

TaskRay Milestones are a distinct Task record type rendered as diamond icons in Plan View. They map to Asana Milestones directly. The milestone date migrates as the Task due date with the milestone flag set to true. We identify Milestones separately during extraction using the TaskRay milestone flag field and import them after all regular Tasks to avoid dangling dependencies. TaskRay milestones with checklist sub-items require those sub-items to migrate as regular Tasks under the milestone, since Asana Milestones cannot contain checklists.

TaskRay Checklist Items map to Asana Subtasks. Each Checklist is a container on a Task; we create a Subtask for every Checklist Item, preserving the completion status (completed/incomplete), name, and notes. The parent Task in Asana holds the Checklist container concept. Subtask completion ordering is preserved from the source Checklist sequence. Asana does not support nested subtasks under a subtask, so deeply nested TaskRay checklists require a flattening step.

TaskRay task dependencies use predecessor and successor links on the TaskRay Task object. We export these as Asana dependency records using Asana's dependency_type (Finish-to-Start, Start-to-Start, etc.) and the Asana REST API's dependency endpoint. After importing all Tasks, we submit the dependency pairs in a second pass. We validate dependency chains post-import to flag any dangling predecessor links caused by tasks that were flattened or not migrated. Note: Asana has documented dependency date-shift bugs in complex timeline configurations — we warn customers and suggest validating dependency chains manually post-migration.

TaskRay stores files on the Salesforce ContentDocumentLink model. We export files attached to TaskRay records via Salesforce's file APIs and re-attach them to the corresponding Asana Task using the Asana attachments endpoint. File size limit in Asana is 100MB per attachment; files exceeding this limit are flagged for manual upload. We preserve the original file name and link to the task in a migration inventory document.

TaskRay custom fields on Project and Task objects are Salesforce custom fields accessible via the REST API. We detect all custom fields during discovery, classify them by data type (text, number, date, picklist, checkbox, lookup), and create corresponding custom fields in each destination Asana project before data import. Asana custom fields are project-scoped (local) or organization-scoped (global) — we recommend global fields for fields used across multiple projects. Picklist values in TaskRay map to Asana enum options, and multi-select picklists map to Asana multi-enum fields.

TaskRay Resources represent individual users who own and complete work; Roles are placeholder owners. We resolve Resources by email match against the Asana workspace members. Any Resource without a matching Asana User is held in a reconciliation queue. TaskRay Role placeholders (non-user job function assignments) are noted in the mapping inventory and must be converted to named Asana users or removed post-migration, since Asana does not have a Role concept as a placeholder assignee.

TaskRay capacity data, utilization percentages, and Dynamic Team Builder configuration exist only on the Premium tier and are stored as custom fields or configuration records in Salesforce. We can migrate the numeric capacity and utilization values as custom fields on the corresponding Task or Project in Asana, but the interactive Resource Planner, Capacity heatmap, and Assignment Decision Making tools do not transfer — Asana has no native equivalent. We flag this gap and recommend Asana's portfolio workload view as a partial replacement for capacity visibility.

TaskRay Template Projects and the Template Builder feature are migratable as standard Salesforce records, but the Template Migration feature (Premium-only) that copies templates across Salesforce environments does not apply when moving to Asana. We export template Projects as Asana Projects with a template naming convention and flag them as templates in a custom field. The customer recreates the template structure in Asana's own template feature post-migration if needed. Collaboration Hub and Communities configuration do not migrate — these are Salesforce-specific settings with no Asana equivalent.

TaskRay's Timer and Timesheet features (Standard tier and above) store time entries on Tasks. We export time entry records as numeric duration values in hours and migrate them as custom fields on the corresponding Asana Task. Asana does not have native time tracking; if the customer requires time logging, we recommend connecting an Asana time tracking integration (Harvest, Toggl, or similar) post-migration and setting the time entry field mapping accordingly.

TaskRay's Field Trickler propagates Account and Opportunity lookups from the Project level down to all Tasks automatically. These are Salesforce IDs that have no meaning in Asana. We extract the Trickler target values during export, match them by name to destination Account and Opportunity records (if the customer maintains those in a connected CRM), and store the linked name in a custom field on the Asana Project or Task. The actual Salesforce lookup relationship cannot be preserved without a Salesforce-Asana integration layer, which is outside migration scope.