Migrate from Baton to monday Work Management

Baton Projects map to monday.com Boards as the top-level container. Project name, description, start date, and due date migrate directly to Board name, description, and date columns. Baton's Project-level Custom Fields attach to the Board as Columns. We create one Board per Project and set the Board type (Team, Shareable, or Private) based on the Project's client-facing status in Baton. If a Baton Project has multiple client views configured, we document the view rules for manual rebuild in monday.com Board sharing settings.

Baton Tasks map to monday.com Items. Task name becomes Item name, assignee maps to the Person column, due date maps to the Date column, status maps to a Status column, and custom field values map to typed Columns. Task ordering within the Project migrates as Group ordering within the Board. We resolve the assignee by matching Baton's user email to monday.com's User table; any unmatched assignee is flagged in the reconciliation report.

Baton subtasks at any nesting depth map to monday.com Subitems attached to the parent Item. The nesting hierarchy is flattened to one level of subitem (monday.com's native subitem model), preserving the full task name, assignee, due date, and status from each subtask level. We flag any subtasks with further nested subtasks during scoping so the customer decides whether to flatten or create additional subitem layers manually post-migration.

Baton Milestones carry their own start and due dates and group related Tasks. In monday.com, Milestones map to either a dedicated Group with a milestone label in the Item name, or a specific Status column value labeled Milestone, depending on how the customer uses Milestones for planning. The milestone dates migrate to Date columns on the Items. We configure this mapping during scoping based on the customer's Baton milestone usage pattern.

Baton free-text custom fields migrate to monday.com Text Columns. The column name in monday.com matches the custom field label from Baton. Text content migrates as-is without transformation.

Baton dropdown custom fields migrate to monday.com Dropdown Columns if the field has more than 8-10 values, or to a Status Column if the field represents a task state. We map the dropdown options from Baton's field configuration to the monday.com label set during scoping, preserving the option order.

Baton date custom fields migrate to monday.com Date Columns. The date value (day, month, year) transfers directly. Time component, if present in Baton, is preserved in the Date column's time field in monday.com if available or stripped to date-only if not.

Baton's Date Formula custom field type computes the number of days between two selected date pickers and auto-updates when either date changes. monday.com has no native equivalent formula that computes duration between date columns. We export the current computed value as a static Number Column at migration time. The customer decides during scoping whether to re-create the logic using monday.com's Formula column (which supports basic arithmetic) or accept static values. Any future changes to the source dates in monday.com will not auto-update the number field.

Baton's native task dependency relationships map to monday.com's Dependency Column on Items. Each predecessor-successor pair in Baton becomes a Dependency Column entry on the successor Item pointing to the predecessor Item. monday.com's dependency chain then drives Gantt and Timeline views automatically. We validate the dependency graph during extraction to detect cycles, which would block import, and flag them for customer resolution before migration begins.

Baton documents attached at the Task or Project level migrate as File Column entries on the corresponding Item in monday.com. We migrate file metadata (filename, upload date, associated object) and flag that actual file blob storage requires attention during scoping. If Baton documents are stored in a third-party cloud location (Google Drive, Dropbox), we migrate the link as a URL column entry rather than re-uploading the file; the customer's admin updates the links post-migration if needed.

Baton's custom task and project status labels migrate to monday.com Status Column values. We map each unique Baton status value to a monday.com Status label, preserving the order. If Baton's status workflow includes color coding, we approximate it using monday.com's color options for Status labels. Custom status labels that represent milestone states map per the Milestone mapping decision above.

Baton assignees on Tasks and Subtasks map to monday.com Person Column values. We resolve each Baton user by email match against the monday.com User table. External collaborators and client-portal users in Baton may not have monday.com accounts; we flag these as Guest user candidates and the customer provisions guest access during scoping. Unresolved assignees appear in a reconciliation report for admin resolution before the main migration phase.

Baton's client-facing portal grants external users read or comment access to Project data. This is a permissions configuration, not a data object. We extract the portal access rules (which projects are shared, which external users have access, and at what permission level) and deliver them as a written inventory document. The customer's admin rebuilds these rules in monday.com using Board sharing settings and guest invitations. We do not migrate the portal as a data construct.