Migrate from Dart to monday Work Management

Dart Workspaces map directly to monday.com Workspaces as the top-level organizational unit. Both platforms use workspaces to group projects (Dart) or boards (monday.com) and manage team membership. We preserve workspace name, description, and member list with role assignments migrated to monday.com Team permissions. Workspace settings are scoped to the destination workspace creation phase before any Board data loads.

Dart Projects map to monday.com Boards. The Project name becomes the Board name, and Project settings (visibility, notification preferences) map to Board-level settings in monday.com. The Project's task list becomes the Board groups or the default group in monday.com. We maintain the Project-to-Workspace parent relationship by placing the newly created Board inside the corresponding monday.com Workspace.

Dart Tasks map to monday.com Items on the target Board. Standard fields migrate directly: title to Item name, description to the Update or Description column, due date to Date column, status to Status column, and priority to Priority column. Custom field values map to corresponding Board Columns created from the Dart custom field definitions. We use Item name as the dedupe key to avoid duplicate Items on re-run.

Dart Subtasks map to monday.com Sub-items under their parent Item. The parent_id reference from Dart becomes the sub-item relationship in monday.com. We preserve nesting depth for subtasks nested under subtasks by resolving the parent Item ID before creating the sub-item. This requires two-pass loading: parent Items first, then sub-items with resolved parent references.

Dart assignee user IDs map to monday.com People column values. We extract every distinct assignee email from Dart task records, cross-reference against the monday.com Workspace member list, and resolve each assignee to the corresponding monday.com User ID. Any Dart assignee with no matching monday.com user is held in a placeholder queue; the customer's admin provisions missing users before the assignee phase of migration runs.

Dart attachments are stored as linked resources separate from task records. We make one API call per attachment to retrieve the file URL and metadata, download the file to temporary storage, upload it to monday.com file storage, and then create the file attachment linked to the target Item. For migrations with thousands of attachments, this adds a dedicated file-transfer phase after the main record load.

Dart custom field definitions (defined at Workspace level and assigned to tasks) map to monday.com Board Columns. We extract all custom field definitions first, create the corresponding columns in monday.com with type matching (text, number, date, dropdown, checkbox, person, etc.), then load task records with their custom field values mapped to the new column IDs. Skipping the definition-before-values sequencing results in silent drops of custom field data.

Dart time entries linked to tasks migrate as numeric duration values in a monday.com Numbers or Duration column. We preserve the duration value in minutes or hours, the billable flag as a checkbox column, and the user association by resolving the assignee via the same user lookup pass used for the Assignees object. Time entry notes migrate to a text column on the same Item.

Dart workspace membership and permission roles map to monday.com Workspace members. We extract member email addresses and roles from the Dart workspace membership endpoint, cross-reference against monday.com user directory, and add resolved members to the target Workspace. Role mapping (Admin, Member, Viewer) requires a role-equivalence decision during scoping because the permission models differ between platforms.

Dart project-level settings (notification preferences, default task visibility, project color coding) map to monday.com Board settings. Not all settings transfer directly; we document the source settings in a settings gap analysis and recommend manual configuration for any settings without a direct monday.com equivalent. Board privacy (shared, private) maps from Dart project visibility.

Dart's task hierarchy with parent-child relationships across projects and subtasks requires tree reconstruction in monday.com. We extract the full task tree from Dart, identify root-level tasks (no parent), identify subtasks (has parent), and load in two passes: root Items first, then Sub-items with parent_id references resolved to monday.com Item IDs. The tree depth is preserved in the Item name or a Sub-items count column for visual validation.

Dart task status values (e.g., To Do, In Progress, Done) map to monday.com Status column labels. We extract all distinct status values from the Dart task dataset during scoping, map each to an equivalent monday.com Status label, and create the Status column with those labels before task loading. If Dart uses custom status names, we preserve them as-is in monday.com Status labels for continuity.