Migrate from SP Project Tracker to Asana

SP Project Tracker Projects map to Asana Projects. Project name, description, start date, end date, and status migrate directly. Any custom fields on the SP Project Tracker project become Asana custom fields scoped to that project. We create the Asana project in the designated Workspace or Team before any task import so that the project_gid is available for task assignment.

SP Project Tracker tasks map to Asana tasks. We detect subtasks in the CSV export by checking for non-null parent_task_id values, then create parent tasks first, capture the resulting Asana task_gid, and link child tasks as Asana subtasks in a second pass. Task name, assignee, due date, priority, and completion status migrate directly. The completion percentage from SP Project Tracker maps to the task's completed flag in Asana. We validate the reconstructed hierarchy against the source row count before closing migration.

Subtasks in SP Project Tracker's CSV export appear as flat rows with a parent_task_id column rather than a nested structure. We identify subtask rows by non-null parent_task_id, then create them in Asana as native subtask objects linked to the parent Asana task_gid. The sequence of parent creation before child creation ensures the lookup relationship is satisfied. We validate that the number of subtask rows in Asana matches the source count within a tolerance of zero.

SP Project Tracker time entries attach to tasks and record hours worked. Asana does not have a native billable time-entry object on its task record. We present two options during scoping: log total hours as a numeric custom field on the mapped Asana task (simpler, no additional setup), or recreate each time entry as a separate Asana task with a time-tracked flag and hours logged in a custom field (preserves per-session granularity). The customer selects the strategy before migration begins. SP Project Tracker does not consistently enforce a billable/non-billable flag, so we carry forward whatever flag value exists or default to non-billable.

SP Project Tracker attachments are stored as internal URLs valid only within an active platform session. We request temporary elevated access credentials during the attachment phase, validate each URL resolves to a downloadable file, and re-upload each file as an Asana attachment on the corresponding task. Files exceeding Asana's 100MB per-file limit are flagged and escalated to the customer for resolution (either splitting the file or storing externally with a link). We log any URLs that resolve to 404 or permission-denied responses for manual follow-up.

SP Project Tracker team members are referenced by display name and email in tasks and time entries. We resolve each to an Asana Workspace User by email match. Any team member whose email does not resolve to an existing Asana User is placed in a reconciliation queue, and the customer's admin provisions the user in Asana before record import resumes. Unresolved names (display name only, no email in the export) are flagged separately for manual assignment by the customer's admin.

SP Project Tracker task-level comments migrate to Asana task comments. We preserve the author name and original timestamp. Threaded nesting in SP Project Tracker is not preserved if Asana's comment model does not support nested replies; comments import as a flat chronological list on the task. Rich text in comments migrates as plain text where HTML parsing is not available in the destination.

SP Project Tracker tags are flat labels applied to tasks. We map them to Asana task tags. Tags containing special characters are converted to a slug-safe format during import. If Asana's tag count per task exceeds any active limits during migration, we consolidate tags into a single combined tag label and document the mapping for the customer's admin to refine post-migration.

SP Project Tracker stores project-level custom fields as property bags (key-value pairs). We extract all key-value pairs, match them against Asana's custom field schema, and create Asana custom fields of the matching type (text, number, date, dropdown) scoped to the destination project. Any custom field type that cannot be matched (e.g., a complex relational field) is created as a text custom field with the original value preserved, and the discrepancy is documented in the migration report.

Task-level custom fields in SP Project Tracker migrate to Asana custom fields on the corresponding task. We detect field types from the source data (string, numeric, date, picklist) and map to the equivalent Asana custom field type. Dropdown options in SP Project Tracker map to Asana enum options. We pre-create custom fields in Asana before any task import so that field_gid references are available during the task insert phase.

SP Project Tracker project-level status values (active, on-hold, completed) map to Asana project status updates or to milestone tasks within the project. We preserve the original status and timestamp as a custom field if the destination Asana project's status field does not support the full range of source values.

SP Project Tracker task priority values (e.g., low, medium, high, urgent) migrate to an Asana custom field of type enum. If the customer does not want a dedicated custom field, we map priority values to task tags using a priority-{value} tag convention. The customer chooses the strategy during scoping, and we document the mapping for post-migration reference.

SP Project Tracker task descriptions migrate to Asana task notes. HTML formatting in the source description is preserved where Asana's rich text model supports it. Inline images referenced in task descriptions that point to SP Project Tracker's internal file store are treated as attachments and downloaded, re-uploaded, and linked in the Asana task notes as separate attachment records.