Migrate from Matilda Workspace to Asana

Matilda Teamspaces define permission boundaries and contain all child objects. We map each Teamspace to an Asana Workspace or Organization, depending on whether the destination Asana tenant is structured as a single org or multiple workspaces. Team-level permission scoping in Asana is configured post-migration by the customer's admin based on the original Teamspace membership. If multiple Teamspaces exist with overlapping member sets, we flag the scope for review before mapping.

Matilda Projects with start/end dates, status, and linked Tasks map directly to Asana Projects. Project-level custom properties migrate to Asana custom fields scoped at the project level. We preserve the project description as the Asana project Notes field and map Matilda project status (active, archived) to Asana project archived state. Auto-schedule dates from Matilda are exported as explicit Start Date and Due Date fields rather than relying on Asana's Timeline auto-schedule to replicate the same sequence.

Matilda Tasks with assignees, due dates, status, subtasks, and description map to Asana Tasks. Task status values from Matilda map to Asana completion state (complete/incomplete). Subtasks in Matilda are mapped as linked subtasks under the parent Asana Task using Asana's subtask relationship, preserving the hierarchy as a nested structure rather than flattening to a flat list. Assignee resolution uses email matching against the destination Asana workspace members.

Matilda subtasks map to Asana subtasks within the parent Task. Subtask-level assignees, due dates, and completion status migrate as fields on the child task. If a Matilda subtask contains further nested subtasks beyond two levels, we flatten the deeper hierarchy into a linked parent-child chain to avoid depth limits in Asana's task model.

Matilda Docs are rich-text documents embedded within Projects. We export doc content as structured HTML and import as an Asana Project Brief (using the Brief description field) or as a linked Google Doc, Notion page, or Confluence page depending on the customer's documentation strategy. Doc-to-task links migrate as task descriptions referencing the original doc name and URL path. We do not migrate embedded images or file attachments within Docs as part of the Doc object migration; those are handled under the Attachments object.

Matilda integrates Chat threads per-project. Asana has no native chat object, so we export thread metadata and message content as a chronological log (author, timestamp, body) and deliver it as a CSV or JSON archive. Customers choose whether to link the archive to the corresponding Asana Project as a custom field reference, convert high-signal messages into task comments, or store the archive in a linked document tool. Rich context linking between chat messages and specific tasks requires field-level remapping and is scoped at discovery.

Matilda custom fields on Projects and Tasks migrate to Asana custom fields. We inventory all custom field types during discovery (text, number, date, dropdown, checkbox, multi-select) and generate a field-mapping table that maps each Matilda field to the equivalent Asana field type. Asana custom fields are accessible via the Asana API at task, project, portfolio, and workspace levels. Custom field values on Tasks and Projects are set during the Task and Project import phases respectively.

Matilda attachments on Tasks and Docs store file references within the platform. We export attachment metadata (filename, URL, uploader, timestamp) and re-link files to the destination Asana task if the customer has an attached storage service (Google Drive, Dropbox, SharePoint) configured, or provide a download package of all exported files with a mapping table linking each attachment to its parent task. Direct file hosting within Asana is not available as a migration target; files must be hosted externally and linked.

Matilda task assignee and project membership records map to Asana workspace Users. We resolve assignees by email address match against the destination Asana workspace. Any Matilda user without a matching Asana User record goes to a reconciliation queue for the customer's admin to provision before the assignment import phase. Active and inactive user status is preserved as a custom field for visibility.

Matilda project-level member assignments map to Asana Project members. We preserve the member role (owner, member, commenter, viewer) as the closest Asana Project membership level available. Matilda's permission-aware knowledge graph at the project level does not map to a granular permission model in Asana at the project level; permission scoping is handled at the Organization and Team level in Asana.

Matilda Tables is listed as coming soon with no stable, publicly documented schema. We do not migrate Tables objects until the feature reaches general availability and the schema is documented. We flag this as a deferred object in the pre-flight report and revisit during a post-GA migration if the customer requires it.

Matilda Customers CRM is listed as coming soon with no stable schema. We do not migrate Customers records. If the customer has active CRM data in Matilda, we recommend migrating to a dedicated CRM tool (Salesforce, HubSpot) as a separate migration engagement and linking the CRM records to Asana Projects via custom fields.