Migrate from Braid to Asana

Braid Projects map directly to Asana Projects. We preserve project name, description, status (active, archived), start date, and target end date. Braid's client-linked projects are tagged with a client-facing Asana Tag during import so that the client's engagement set is filterable. Archived projects migrate with archived=True to preserve the historical record without cluttering active workspaces. Braid's multi-location project flags map to a custom project field for geographic classification.

Braid Resources map to Asana Members invited to the workspace. We map resource name, email, role title, and multi-location availability flags to Asana user profile fields. Capacity hours per week from Braid carry forward as a custom field resource_capacity_hours__c so that the customer's admin can configure Workload view settings in Asana Business. Resource status (active, inactive) maps to Asana workspace member active/inactive. Any Resource without a valid email for Asana provisioning goes to the reconciliation queue.

Braid's native Client entity has no direct Asana equivalent. We map each Braid Client to an Asana Team (for organizational grouping) and apply a Tag named with the client name and a billing classification suffix. The client contact details (name, email, phone) migrate as a custom record or to a shared Tag description field. Client billing preferences and payment terms flag in a custom field client_billing_terms__c that the customer's finance team uses when reconciling in a connected accounting tool.

Braid Time Entries map to Asana Tasks with hours captured in a custom number field entry_hours__c, the billable flag in billable__c (checkbox), and the entry date in a custom date field time_entry_date__c. The task description carries a reference to the original Braid time entry ID for audit trail. Braid's link between time entries and Resources (the person who logged hours) maps to the Asana task assignee. Note: Asana has no native timesheet or billing layer; these custom fields feed Asana Reports or a connected BI tool for hour-based billing.

Braid exposes budget and actual figures per project with revenue recognition data. Asana has no native financial object. We create custom currency fields on the Asana Project: budget_amount__c, actual_amount__c, and variance__c (formula or computed). The customer documents their revenue recognition model during scoping, and we note whether the figures represent committed, recognized, or billed revenue so the finance team maps them correctly to any connected accounting or BI system. These fields are informational post-migration; Asana does not generate invoices or track billing cycles.

Braid's schedule assignments (Resource availability, firm bookings, soft bookings) map to Asana's Workload view, which is available on Business tier ($24.99/user). We carry forward each Resource's capacity hours and assignment allocations as task assignments in Asana Projects. Hard booking flags from Braid map to confirmed task assignments; soft booking flags map to task assignments with a note flag in a custom field booking_type__c. Multi-location availability flags migrate as a custom picklist field resource_locations__c. Workload view configuration (hours per day, capacity thresholds) is documented for the customer's admin to set in Asana.

Braid's multi-location support tags Resources and Projects with geographic location identifiers. We create an Asana multi-select custom field project_locations__c at the workspace level, populating it with the distinct location values from Braid. Resources inherit location from the Braid Resource record and carry it as a custom field resource_primary_location__c for filtering in Workload view and reporting.

Braid supports custom fields scoped to Projects. We run a pre-migration discovery pass against the customer's Braid instance to enumerate all project custom field names, types, and picklist values. Each Braid custom field type (text, number, date, picklist, checkbox) maps to the nearest Asana custom field equivalent. Picklist values migrate as Asana enumerations. If Braid uses a field type not supported in Asana (e.g., a formula or currency with specific formatting), we flag it during scoping and use the nearest native type with a documented note for the customer to adjust post-migration.

Braid Resources carry custom fields for employee-specific attributes (skills, department, cost center, employment type). We create equivalent Asana custom fields on the user profile level where supported, or document them as a separate HR record that the customer's admin maintains externally. Resource cost rate fields from Braid migrate as read-only custom fields in Asana (cost_rate__c) if the customer intends to use Asana for capacity reporting against billable rates.

Braid engagement notes (internal commentary on client interactions, project status updates) migrate as comments on the linked Asana Project or Task. We map the note body, timestamp, and author (resolved to the corresponding Asana Member by email). If the note references a specific Braid record ID, we preserve that as a text reference in the comment body for audit trail.

Braid project templates (pre-configured task structures, field defaults, and assignment rules) have no automated Asana migration path because Asana's template model is a project duplication feature rather than a stored template object. We document every Braid project template identified during scoping — including task names, task dependencies, default custom field values, and section structure — in a written template inventory. The customer's admin recreates these as Asana project templates post-migration. Templates with complex scheduling rules are flagged for manual configuration or Asana partner assistance.

Braid task dependencies (finish-to-start, start-to-start) map to Asana's native dependency feature available on Premium and Business tiers. We extract the dependency graph from Braid, map it to Asana dependency format, and apply it during import so that the project's critical path is preserved. If any Braid dependency type is not natively supported by Asana (e.g., a lag-time offset beyond Asana's 0-day minimum), we flag the specific dependency in the reconciliation report for manual resolution.