Migrate from Wrike to Asana

Wrike Spaces map to Asana Teams as the top-level organizational container. Wrike's Space-level permission model becomes Asana Team membership scoping. We map Space name to Team name and transfer Space-level custom field configurations to the equivalent Asana Team settings. Note: Asana Teams live inside a Workspace or Organization; we do not create new Workspaces or Organizations but can create new Teams within an existing destination structure.

Wrike Folders map to Asana Projects if the Folder contains child Projects (preserving the parent-child hierarchy). Folders containing only Tasks map to Asana Projects with their Tasks as top-level items. If a Wrike Folder has no child Projects but has Tasks, we flatten those Tasks into a Project and note the original Folder name in the Project description. This preserves the organizational intent without introducing a non-native construct.

Wrike Projects map directly to Asana Projects. We preserve the project name, description, start date, due date, status (Active, Completed, Archived), and custom field values. Project permissions are scoped to the target Asana Team created from the parent Wrike Space. If a Wrike Project has a status not natively supported by Asana, we map it to the closest Asana Project section or a custom field tracking the original Wrike status.

Wrike Tasks map to Asana Tasks with title, description, start date, due date, and custom field values preserved. Assignee resolution uses the primary assignee from Wrike mapped directly to Asana's single-assignee field. Status maps from Wrike workflow stage to Asana section membership (or the closest status value if sections are not used). Tasks are imported in dependency order to preserve the cascade if dependency resolution runs during import.

Wrike Subtasks map to Asana Subtasks within their parent Task. Asana allows one level of Subtask nesting only. If Wrike source data contains Sub-subtasks (Subtasks of Subtasks), we flatten these to a second-level Asana Task linked to the parent Subtask as a regular Task with a custom field wrike_original_depth__c = 'sub-subtask' so the customer can identify and restructure them manually. We flag this during scoping so the customer can decide whether to flatten, convert to Sections, or accept the structural change.

Wrike Custom Fields map to Asana Custom Fields with type-level equivalence: DropDown to Dropdown, Numeric to Number, Date to Date, Currency to Number with formatting note, Percentage to Number (percentage), Contacts to People, Checkbox to Checkbox, Rating to Rating. CalculatedNumeric and CalculatedDate fields from Wrike export as static values—we do not attempt to recreate the formula in Asana because Asana Formula fields are not equivalent. Every Calculated field is flagged in the data audit with a recommendation to either accept static values or build a manual recomputation process post-migration.

Wrike Users map to Asana workspace members by email address match. We extract the full user list from Wrike including deactivated users. Active users are invited to the Asana workspace as part of the migration scope; deactivated Wrike users are noted in the migration log with a recommendation to either create inactive Asana members or clear their assignments depending on the customer's audit requirements.

Wrike task dependencies map to Asana dependencies via the Asana API using the dependent task GID and the dependee task GID. Finish-to-Start dependencies map directly. Start-to-Start dependencies also map via the Asana API. Finish-to-Finish and Start-to-Finish dependencies are not natively supported in Asana—these are documented in the migration log with a recommendation to either convert to an equivalent Finish-to-Start chain or accept a manual tracking workaround. After migration, we recommend running a manual verification pass in Asana Timeline for any dependency chain longer than five tasks because of known red-arrow behavior in Asana's Timeline.

Wrike time entries (hours, dates, and billing categories) map to Asana's built-in time tracking if the destination Asana Organization has the Timesheets add-on enabled. If not enabled, time entries migrate as a custom number field wrike_time_logged__c with the total hours value, and a text field wrike_time_category__c carrying the billing category label. Duration-based entries that store duration rather than start and end time convert to hours in decimal format.

Wrike file attachments are referenced by URL. We preserve the download URL in the migration log and re-link attachments in Asana by re-uploading or by storing the original Wrike URL as an Asana attachment link. Large attachment sets may require a separate storage migration step; we flag accounts with total attachment volume over 5 GB during the pre-migration storage audit. Wrike's 2GB Free tier storage cap is a source-side constraint that we audit before export.

Wrike task and project comments map to Asana task comments with author, timestamp, and text content preserved. Thread structure (parent-child comment relationships) migrates as parent-child comment nesting in Asana where the destination supports it. We use the Wrike author email to match against the migrated Asana user for display attribution.

Wrike Workflows define custom status sets and transition rules per project or globally. These do not migrate as automation code to Asana Rules because the trigger models and condition types differ structurally. We export every active Wrike Workflow definition—including all custom statuses, transition conditions, and assigned project scoping—into a written inventory document. The inventory includes the Workflow name, associated projects, trigger type, conditions, and a recommended Asana Rules equivalent configuration. The customer's admin rebuilds the Workflows in Asana Rules post-migration.

Wrike Tags migrate as Asana Tags. Tags are freeform labels on tasks and projects in Wrike and map directly to Asana Tags as key-value labels. We preserve the tag name exactly. Asana Tag filtering works at the project and portfolio level, so no structural conversion is required. If a task had multiple Wrike tags, all of them become Asana Tags on that task.

Wrike Dashboards aggregate widgets showing project health, workload, and custom metrics. We export dashboard configurations and widget definitions where the API exposes them and deliver them as a written dashboard inventory document. Asana Portfolios provide a similar aggregate view but are configured differently. We do not build Asana Portfolios inside the migration scope; the inventory document guides the admin in recreating the equivalent view. Custom Reporting requires a separate reporting setup in Asana that falls outside standard migration scope.