Migrate from Baton to Asana

Baton Projects map directly to Asana Projects. Each project carries its name, description, start date, and due date. We preserve the project creation timestamp as a custom field since Asana's native created_at is the import timestamp rather than the original Baton creation date. If the customer uses Baton's milestone-oriented date structure, we create corresponding Milestones in Asana (Premium tier) or Sections with milestone-style naming in Basic/Starter.

Baton Tasks map 1:1 to Asana Tasks within their parent Project. Task name, description, assignee, due date, start date, and completion status migrate directly. Task ordering within the project is preserved through Asana's section structure. The assignee mapping resolves Baton Owner email to Asana User email; any unresolved owner goes to a reconciliation queue for admin provisioning before the migration batch runs.

Baton Subtasks nest under Tasks to arbitrary depth. We preserve the full parent-child nesting hierarchy in Asana, which supports subtasks at multiple levels natively. The migration flattens depth to Asana's practical limit (3-4 levels recommended) and documents the full original hierarchy as a custom field subtask_depth_path__c on each subtask for reference and audit.

Baton Milestones map to Asana Milestones. This mapping requires the destination Asana account to be on a Premium plan or higher, as Milestones are a Premium-tier feature. We flag this during scoping. Milestone name, start date, due date, and associated task grouping migrate. If the destination is on Starter or lower, we create milestone-equivalent Sections and document the upgrade requirement.

Baton custom fields of type free text, dropdown, date, and checkbox map to equivalent Asana custom field types. Dropdown options migrate as Asana enum options. Date fields migrate as Asana date custom fields. We create the custom field schema in Asana before any record import so that field IDs are stable and can be referenced in bulk record writes. Field-level security defaults to admin-visible only on Asana; we configure visibility during migration based on Baton's field access settings.

Baton's date-formula custom field type auto-computes days between two named date fields (e.g., Project Start Date and Task Completed Date) and updates dynamically. Asana does not support formula custom fields. We export the current computed numeric value from Baton as a static number on a custom field in Asana. The date-formula name is preserved in the custom field label (e.g., 'Days: Start to Completion'). This is a one-time snapshot value. Customers requiring ongoing auto-calculation must configure a separate automation or spreadsheet integration in Asana.

Baton native task dependencies track predecessor/successor relationships. Asana's native dependency model (predecessor tasks, Start-After-Finish, Start-After-Start) requires a Premium plan or higher. For Premium destinations, we map dependencies to Asana's native dependency model using the predecessor field on each dependent task. For Starter and Basic destinations, we preserve dependency relationships as a text custom field dependency_chain__c listing the predecessor task names in sequence order, so the customer's admin can manually recreate dependencies post-migration or upgrade to Premium.

Documents attached to Baton Tasks and Projects migrate as Asana Attachments. We migrate attachment metadata (filename, associated task, upload date) and flag that actual file blobs require attention during scoping because storage location and access credentials differ. Asana's API does not accept attachments exceeding 100 MB; any file in Baton exceeding this limit is flagged for manual re-upload by the customer after migration.

Baton's client-facing portal is a permissioned view layer over existing project data, not a separate data object. We treat the portal configuration as a permissions matrix to be documented rather than data to be transferred. The migration handoff includes a written list of each project, its current client portal access level (read, comment, full access), and the external email addresses with access. The customer's Asana admin recreates access using Asana's project sharing links and guest user invitations. If Baton's external users are not already in Asana, guest accounts must be provisioned.

Baton task and project status labels define the workflow pipeline. We map each custom Baton status value to either Asana Sections (task grouping) or a custom single-select status field that the customer's admin configures in Asana. Status color mapping migrates where the destination supports color customization. Custom statuses that have no clear Asana equivalent are flagged in the mapping document for manual assignment during post-migration onboarding.

Baton assignees on Tasks and Subtasks map to Asana Users by email address. External collaborators and client-portal users in Baton may have different role semantics in Asana. We resolve each Baton owner and assignee to an Asana User record; any assignee with no matching Asana User goes to the reconciliation queue. External users from Baton's client portal are mapped as Asana guest users, which require a paid Asana seat on Starter or above.

Baton automations (if any active workflow rules are configured) do not migrate to Asana Rules. We do not migrate automations as code. We deliver a written inventory of each active Baton automation including its trigger, conditions, and actions, with a recommended Asana Rule equivalent. The customer's Asana admin rebuilds these in Asana's Rules builder (available on Starter and above) or documents the gap if Asana's native rule model does not support an equivalent action.