Migrate from Baton to Trello

Baton Projects map 1:1 to Trello Boards. Project name, description, start date, and due date migrate as Board name, description, and date filters. We create one Board per Project using the Trello REST API. Project-level custom fields (non-formula) become Custom Fields on the Board if the destination tier supports them (Premium and Enterprise). The client's internal permissions matrix for each project maps to Trello Workspace membership levels; external-facing project sharing maps to Board-level invite rules.

Baton Milestones are first-class planning objects with their own start/due dates. Trello has no native milestone concept. We map each Milestone to either a dedicated List on the destination Board (one List per Milestone) or to a Card with a milestone Label and the Milestone due date set as the Card due date. The customer chooses the strategy during scoping. Milestone ordering and milestone-task grouping are preserved via List position or Card grouping.

Baton Tasks map directly to Trello Cards. Task name, description (rich text), assignee, due date, start date, and status migrate as Card name, description, member assignment, due date, start date (stored as a Custom Field if the Trello tier supports it), and List position. Status mapping uses the Trello List structure: we map each Baton task status value to a Trello List name or a label color. Archived or completed Baton Tasks migrate as closed Cards in Trello.

Baton Subtasks nested to arbitrary depth flatten into Trello Checklist items. Trello supports a single level of Checklist items per Card with no nesting beyond one parent Card. We preserve full subtask text and completion status as Checklist items on the parent Card. For subtasks that themselves have further subtasks in Baton, we flatten the full chain into a flat checklist ordered by nesting depth, with indentation prefixes (e.g., ' > subtask text') to indicate hierarchy visually. Subtask completion status migrates as checked/unchecked state.

Baton's native task dependency tracking (predecessor/successor relationships forming a critical path) has no native Trello equivalent. We flag this during scoping. Options include: Trello's Dependencies Power-Up (Premium and Enterprise tiers) which supports blocking and dependency visualization; or Butler automation rules that move Cards between Lists when a dependency Card is marked complete. We document the full dependency chain from Baton as a written mapping table with the recommended Trello rebuild approach per dependency.

Baton custom fields of type free text, dropdown, date, and number map to Trello Custom Fields. Trello supports text, number, date, dropdown (with options), and checkbox Custom Field types. We map each Baton field type to the nearest Trello equivalent. Dropdown options migrate as Trello Custom Field dropdown options. If the destination Trello workspace is on the Free or Standard tier (which does not include Custom Fields), we create label-based or card-description-based fallbacks and document the field-value mapping for manual re-entry.

Baton's Date Formula custom field type computes the number of days between two date pickers (e.g., Project Start Date and Task Completed Date) and auto-updates when either date changes. Trello has no computed field capability. We export the current computed value as a static number field on the Card during migration. We flag this in scoping so the customer decides whether to preserve the snapshot value or re-create the logic manually in Trello's Butler automation or a third-party formula Power-Up.

Baton documents attached at the task or project level migrate as Trello Card attachments. We extract attachment metadata (filename, upload date, associated task) and re-upload files to Trello if the file source is accessible. If the attachment is stored in an external system (Google Drive, Dropbox, SharePoint), we migrate a link reference rather than the file blob. Actual file storage migration requires attention during scoping because Baton does not expose a bulk download API.

Baton's client-facing portal grants external users read or comment access to project data as a native feature. Trello has no equivalent client portal. We treat the client permissions matrix as a permissions inventory to be rebuilt. Each client's access maps to a Trello Board invite (if the client is a named Trello user) or a public Board share link with restricted permission settings. We deliver a written permissions matrix documenting current client-to-project access for the customer's admin to re-configure post-migration.

Baton task assignees map to Trello Board members. We resolve assignees by email match. External collaborators and client-portal users in Baton may not have Trello accounts; we flag these as pending Board invites or convert them to Card-watchers rather than assignees. The customer's admin provisions any missing Trello workspace members before the production migration phase.

Baton's custom task status labels and pipeline workflow stages map to Trello Lists on each Board. We extract all distinct Baton task status values and create a corresponding Trello List per status. Custom status labels (e.g., 'In Review', 'Client Approved') become List names. The migration preserves the relative ordering of statuses as List positions.

Baton notes attached to tasks migrate as Card description content (if the note is the primary task description) or as Trello Card comments. We preserve note timestamps and author attribution in the comment metadata. Long notes exceeding Trello's description length limit split into multiple comments with a note delimiter header.