Migrate from Twproject to Asana

Twproject Projects with their Gantt WBS hierarchy map to Asana Projects. The parent-child task structure (phases, sub-phases, tasks) migrates as subtasks within the Asana project. We preserve the project name, description, start date, target/end date, status, and any custom field values. Asana project privacy settings default to the destination organization's sharing rules; we coordinate with the customer's admin to set project visibility during import.

Twproject Tasks map to Asana Tasks within the parent project. We preserve task name, description (rich text), assignees (resolved via email match to Asana workspace users), start date, due date, status, priority, and the subtask hierarchy. Twproject's parent-child relationship becomes Asana's subtask nesting. Task completion status migrates from Twproject's done/undone flag to Asana's completed_at timestamp. We flag that Twproject's ToDo feature (a lightweight checklist distinct from Tasks) has no direct Asana equivalent — we recommend treating ToDos as notes on the parent task.

Twproject Resources (user accounts with allocation, cost rates, and department metadata) map to Asana workspace Members. We resolve by email address during import. Resource allocation percentages from Twproject's workload view become task assignment confirmations in Asana; we do not replicate a workload balancing view because Asana does not have a native allocation planning module at Starter/Advanced tiers. Twproject cost rates migrate as a numeric Custom Field on the user's Asana profile section or as a project-level custom field.

Twproject Worklogs (hours logged against tasks) are not included in the JSON project export and must be fetched via API using the task ID association. We pull all worklog records within the customer's specified date range, then create numeric Custom Fields on the corresponding Asana Tasks to store total hours logged. For detailed time entry history, we attach worklog details as task notes in a structured format. Date-range scoping is set during discovery because large worklog volumes increase extraction and transformation time.

Twproject's Costs & Revenues section (project-level costs, additional expenses, budget-vs-actual forecasts) has no native Asana equivalent. We extract cost data via API during the extraction phase, then create numeric Custom Fields on the destination Asana Project to store budgeted amount, actual cost, and variance. For multi-category cost breakdowns, we create multiple custom fields (e.g., labor_cost__c, material_cost__c, contingency__c). The customer's project manager rebuilds any cost dashboard in Asana Portfolios or exports to a spreadsheet.

Twproject wizard-defined Custom Fields on Tasks and Projects enumerate during discovery via API. We map each to Asana Custom Fields using type normalization: Twproject text fields become Asana Text fields; numeric fields become Number fields; date fields become Date fields; single-select and multi-select fields become Enum (Drop-down) or Multi-enum fields. Asana requires Custom Fields to be added to each destination project individually (local fields) or to the workspace field library (global fields). We recommend global fields for reusable classification and coordinate with the admin on which fields are local versus global before import.

Twproject's Gantt WBS hierarchy (project → phases → sub-phases → tasks) maps to Asana subtask nesting and the Timeline view. We preserve the parent-child relationship via Asana's subtasks. The Asana Timeline view is enabled on the destination project and displays tasks with Start Date and Due Date; we do not replicate Twproject's dependency arrows in the Gantt unless the customer explicitly requests dependency mapping, as that requires manual configuration in Asana Timeline.

Twproject's Kanban is a daily planning view driven by task assignments and status rather than a top-level board object. Task assignments and statuses migrate as standard Asana task fields. The board column configuration (columns, swimlanes) does not migrate as Asana Board columns — we recommend the customer review the Twproject column structure during scoping and manually configure Asana Board columns to match their workflow post-migration.

Twproject tags on Tasks and Projects retrieve via API and map to Asana Tags. Tags in Asana are workspace-level objects that can be applied to any task or project. We extract the full tag list from Twproject, create matching Tags in the destination Asana workspace, and apply them to migrated tasks during import. Tag normalization handles any differences in casing or special characters between the platforms.

Twproject's resource workload view shows per-user assignment distribution across time. We extract the allocation data per resource from Twproject's API and reconstruct it as task assignments in Asana. Twproject stores allocation as a percentage of total resource capacity; we convert this to direct task assignments with estimated hours where applicable. Asana's workload view (Advanced tier) can display task assignments per team member for visual capacity planning.

Twproject supports MS Project file import and export. Projects that originated in MS Project and live in Twproject can be re-exported as MPP files or XML, then processed for migration to Asana. We handle the task hierarchy, dates, and assignments from the MS Project XML export and map them directly into Asana Projects and Tasks. This is most relevant for customers who received Twproject-originated data from external parties and need to consolidate it into Asana.

Twproject attachments are not included in the JSON export and are explicitly omitted from the project export path. We enumerate attachment metadata (filename, file URL, associated task ID) from Twproject's API during extraction and generate a written inventory of files that must be re-uploaded manually to Asana. We provide the list in CSV format with source URLs and destination task references. File re-upload is not automated because Twproject's on-premise deployments may use internal file servers with authentication that differs from the API environment.