Migrate from Mission Control to Asana

Mission Control Projects map directly to Asana Projects. Project name, description, status, start date, and due date migrate to Asana's name, notes, color, and custom fields. Project owner from Mission Control maps to an Asana Project member with Admin access; we assign the owner as the first project member during migration. Sub-project hierarchies are flattened by Mission Control's export, so sibling sub-projects are imported as separate Asana Projects within the same Team and a parent_reference custom field is attached to preserve the original hierarchy context.

Mission Control Tasks map to Asana Tasks within the parent Project. Task name, description (rich text), status, priority, assignee, and due date migrate to Asana's name, notes, completion status, num_fields (custom priority), assignments (User lookup), and due_date. Mission Control status values (e.g., Open, In Progress, Blocked, Complete) map to Asana completion status (marked_complete or open) with any non-standard status values preserved as a custom field mc_original_status__c for audit.

Mission Control Subtasks map to Asana Subtasks under their parent Task. We reconstruct subtask hierarchy up to three levels; subtasks beyond level three are attached as sibling tasks with a parent_task_reference custom field pointing to the original parent. This is a known flattening consequence of Mission Control's export that customers with deeply nested task structures should review pre-migration. The Asana subtask limit of one level (subtasks cannot have their own subtasks in standard Asana) means any multi-level subtask chains require post-migration reorganization into sections or separate linked tasks.

Mission Control Teams map to Asana Teams. We extract team name, description, and member list and create the corresponding Asana Team. Team membership assignments migrate as Asana Team memberships attached to the matching Asana Users. If Mission Control has no explicit team concept, we create a default Team named after the Mission Control workspace and assign all users to it.

Mission Control Users map to Asana Users by email address. We extract name, email, role, and avatar metadata. Any Mission Control User without a matching Asana User is placed in a reconciliation queue for the customer's admin to provision before record migration continues. Role names from Mission Control are preserved as a custom field mc_original_role__c on the Asana User profile for reference during permission reconfiguration.

Mission Control Comments map to Asana Stories on the parent Task. We preserve full comment text, author (resolved to Asana User), and timestamp ordering to maintain thread sequence. Mission Control comments on Projects migrate as the first Story on the Project in Asana. Reactions or emoji reactions from Mission Control are not transferable and are documented in the migration handoff as a manual checklist item for the customer.

Mission Control Tags are simple string labels applied to Tasks and Projects. We export the full tag vocabulary and apply tag values to Asana Tags on the migrated records. If the customer uses tags for content classification across multiple projects, we recommend mapping these to Asana Topics during scoping; the customer chooses between Tags (per-task labeling) and Topics (organizational grouping) based on their workflow.

Mission Control custom field definitions vary per account and are stored per-object. We extract all custom field schemas (name, type, allowed values) before migration and present a pre-migration checklist for the customer to create matching custom fields in Asana. Asana custom fields must be created in the destination workspace before data import; their values are staged in a temporary holding object until the field exists. Custom field values that reference picklist options are mapped to Asana enum or multi-enum custom fields by exact value match.

Mission Control file attachments store name, size, mime type, and URL. We preserve the URL reference and download metadata. Actual file content transfer depends on whether the source storage is publicly accessible; if so, we populate Asana's external attachment URL. If the storage requires authentication, we flag the attachment for manual re-upload post-migration. Attachments without a resolvable URL are documented in the migration report for the customer to handle manually.

Mission Control workflow definitions (triggers, conditions, and actions) are stored in a proprietary format that is not executable in Asana. We export the full rule configuration as structured JSON documentation with a plain-English description of each rule's logic. This documentation is handed off to the customer's admin for manual rebuild in Asana Rules. We recommend scheduling a pre-migration review call to prioritize which workflows are business-critical so the admin can rebuild the most impactful rules in parallel with data migration.

Mission Control role-based permission configurations do not export as executable rules. We export a role matrix showing what each role can access in Mission Control (Project visibility, Task editing, Comment permissions, Admin rights). The customer must manually configure equivalent roles and grants in Asana using Asana's Team permissions, Project privacy settings, and guest access controls. We flag any users who will lose access after migration and provide an updated access audit report once Asana is live.

Mission Control exposes integration configurations for connected third-party tools with tokens and credentials sanitized (actual tokens replaced with placeholders). We export the list of active integrations, the connected tool name, and the connection type. The customer uses this inventory to reconfigure OAuth connections or re-enter API tokens in Asana's integration directory post-migration. We do not transfer active sessions or re-authenticate third-party connections during migration.