Migrate from WeTrack to Asana

WeTrack Projects map 1:1 to Asana Projects. The Project name, description, date range, and status fields transfer directly. WeTrack's RAG status on the Project level maps to a pre-created color-coded custom field in Asana. Sections in the Asana Project are created to mirror WeTrack's task grouping if present in the export. Projects without active tasks are migrated as empty containers with all metadata intact.

WeTrack Tasks map 1:1 to Asana Tasks within the parent Project. Start date maps to Asana Start Date, due date maps to Due Date, and the task name and description fields transfer directly. Assignee is resolved by email against the Asana User mapping. The WeTrack task status (Active, Complete) maps to Asana completion state. If Dependencies are enabled in the destination Asana Workspace, we set the dependency relationship for tasks that reference other tasks.

WeTrack Subtasks are child records under a parent Task with auto-sync date inheritance. Asana supports native subtasks within a task, or tasks can be linked as separate records with a Finish-to-Start dependency. The migration design choice is made during scoping: native subtask mapping preserves the WeTrack hierarchy exactly but limits subtask depth; dependency mapping creates a flat task structure with explicit links. Both approaches preserve the parent-child linkage. We flag which approach was chosen in the mapping spec before migration begins.

WeTrack attachments of all types (documents, images, PDFs) are extracted as file references and metadata from the export. We map file name, upload date, and uploader to Asana Attachment records and attach them to the correct Task. Actual file content is transferred if the export contains downloadable URLs; if the export is metadata-only, we document the attachment list for manual re-upload post-migration.

WeTrack Risk Registers use industry-standard Inherent Likelihood and Impact fields with template risks. Asana has no native risk object, so we create a custom Risk object with Likelihood (enum: Very Low, Low, Medium, High, Very High), Impact (enum: Very Low, Low, Medium, High, Very High), Risk Owner (user reference), and Mitigation Plan (text) fields. Risk records from WeTrack are migrated into this custom object. RAG status on the Risk Register maps to the calculated RAG value (Likelihood x Impact) stored as a read-only formula field or enum in the destination.

WeTrack's Sustainability module tracks ESG indicators and metric values. Asana has no native ESG object. We create a custom ESG object with Metric Name (text), Metric Value (number), Unit (enum: tCO2e, kWh, m3, kg, percentage), Reporting Period (text), and Notes (text) fields. ESG records are migrated as instances of this object, linked to the relevant Project via a lookup field. The customer configures the ESG schema in Asana before migration if they are on Asana Premium or Enterprise.

WeTrack Job Categories restrict valid options on task fields to prevent data entry errors. If the category set is finite and fixed (under 500 options), we map them to a single-select custom dropdown field in Asana. If the set is open-ended, we use Asana Tags as the mapping target. We validate option counts during scoping and flag any categories that exceed Asana's per-field option limit.

WeTrack RAG updates run on predictable schedules and cascade from parent tasks to subtasks via auto-sync. Asana has no native RAG equivalent. We create a color-coded custom single-select field (Red, Amber/Yellow, Green, Grey for not applicable) and map WeTrack RAG values directly. Inherited RAG values on subtasks that originate from parent cascade are flagged during migration to distinguish them from explicitly set subtask values. Post-migration, Asana users should update the custom field manually or via an Asana Rule; there is no native cascade automation.

WeTrack Incident Reports are operational records that track incidents during event delivery. Asana has no native incident object. We create a custom Incident object with Incident Title (text), Severity (enum: Low, Medium, High, Critical), Status (enum: Open, Investigating, Resolved, Closed), Description (text), and Reported Date (date) fields. Any attachments from the incident record are mapped as files on the Incident record. The customer provisions the Incident custom object schema in Asana before migration.

WeTrack user accounts and task owners are referenced by email and ID. We match WeTrack owners to Asana workspace members by email address. Any WeTrack Owner without a matching Asana User is placed in a reconciliation queue; the customer's admin provisions the missing Asana User before record import resumes. Inactive or orphaned WeTrack users are flagged for deactivation or reassignment in Asana.

WeTrack supports custom fields on Projects and Tasks with varying data types. We validate each WeTrack custom field's type and create a corresponding Asana custom field before migration. Text fields map to Asana text custom fields, numbers to number custom fields, and dates to date custom fields. Single-select custom fields require an additional API step: we query the destination Asana Workspace to retrieve the enum GID for each option value before writing any records, because Asana's API requires the enum GID rather than the option label for single-select field values.

WeTrack read-only configuration records (template risk registers, ESG measurement templates, workflow rules scoped to event delivery) cannot be extracted as data during the export. We flag every read-only configuration record identified during scoping and document it in the migration handoff with the recommended manual rebuild steps in Asana. No configuration record is silently skipped; each one appears in the inventory document with a rebuild recommendation.