Migrate from Redbooth to monday Work Management

Redbooth's Organization is the top-level tenant container holding all Workspaces, users, and billing. monday.com's Workspace is the equivalent top-level container. We map the Organization name to the Workspace name, preserve the admin-assigned member list as Workspace members, and flag the billing owner. If the customer runs multiple Redbooth Organizations (possible on Enterprise), each becomes a separate monday.com Workspace and we preserve cross-workspace memberships as separate monday.com Workspace invitations.

Redbooth Workspaces map directly to monday.com Boards. The Workspace name, description, and member access list translate to Board name, description, and board subscribers. Workspace-level Templates map to monday.com Board Templates. We preserve the sort order of Boards within the Workspace and recreate any Workspace-level pinned boards as pinned Items or board-level widgets at the destination.

Redbooth Task Lists sit inside a Workspace and group related Tasks. monday.com Groups serve the same grouping function within a Board. We map the Task List name to the Group name and preserve the sort-order weight field so Groups appear in the same sequence. Task List-level access permissions (if the list was shared selectively) map to Group-level subscriber settings in monday.com.

Tasks are the core record in Redbooth and map to Items in monday.com. We map title, description (as rich-text body), status (Open/Completed) to monday.com Status column, due date and start date to Date column, priority (Low/Medium/High) to monday.com Priority or Label column, assignee to Person column, and tags to Tags column. Custom fields on tasks extract as key-value pairs mapped to the closest monday.com column type (text, number, date, dropdown, or checkbox).

Advanced Subtasks (Redbooth Business plan only) map to monday.com Subitems. We extract subtasks as a flat list linked to their parent task ID and nest them under the migrated Item. If the source account is on Pro (subtasks unavailable), we flatten subtask records into linked Items in a separate Subtasks group within the same Board, preserving the parent link in a Linked Items column for audit clarity. Subitem titles, descriptions, assignees, and due dates transfer directly.

Redbooth task-level Comments map to monday.com Updates on the Item. We preserve author name, timestamp, and comment body text. Redbooth Conversations (workspace-level threaded discussions not tied to a task) map to Updates on the Board-level general Group if a suitable container exists, or are delivered as a separate importable CSV attached to the Board for the admin to manually distribute to relevant Items post-migration.

Redbooth workspace-level Conversations are standalone threaded discussions not linked to a specific task. monday.com has no native equivalent at the Board level (Updates exist on Items, not Boards). We deliver workspace Conversations as a CSV with author, timestamp, thread body, and the originating conversation context, then the customer decides whether to post manually to relevant Items or retain as an offline reference document.

Redbooth Notes are standalone rich-text objects inside a Workspace, not attached to a specific Task. We create a dedicated Board named 'Imported Notes' and populate each Note as an Item with the Note title as Item name and Note body as the Item description. Alternatively, if the customer uses monday.com Docs, we deliver Notes as a structured CSV ready for import into the Docs workspace.

Redbooth member profiles (name, email, avatar URL, role: Admin/External/Participant) map to monday.com Workspace members. We match by email address. External members (workspace-scoped collaborators with limited access) map to monday.com Guests on boards where they are specifically invited. Redbooth's multi-workspace member roles are reconciled so a user who is Admin in one workspace and Participant in another gets the appropriate per-board permission at monday.com.

Redbooth tags are workspace-scoped labels applied to tasks. We preserve the tag name and the task-to-tag association as a separate mapping table. At monday.com, we create a Tags column on the relevant Board and populate tag values as the imported tag names. If tag collisions occur (same name in different workspaces), we prefix with the workspace name during import and the customer deduplicates post-migration.

Redbooth exports file metadata and URLs (links) only — the actual files are not bundled in the export. We extract the full list of attachment references (file name, URL, linked task, linked user, timestamp) as a detailed CSV during scoping and flag every attachment reference for the customer. The customer's team re-uploads source files to the relevant Items post-migration. This is a known data-loss risk if not addressed before cutover; we make it explicit in the migration plan rather than discovering empty attachments at go-live.

Redbooth time tracking entries (Pro+ feature) include duration, user, task, and date. We export these as a structured CSV with task ID (mapped to monday.com Item ID post-migration), user, date, and duration in minutes. If the destination monday.com account has the Time Tracking app enabled, we map entries to native time tracking records linked to the matching Items. If the app is not available, the CSV is delivered for import via monday.com's CSV importer or for use in the customer's reporting tool of choice.

Redbooth's Timeline View stores task start/end dates and dependency links. We extract task date ranges and create a Timeline column in monday.com for each migrated Item. Dependency links (Task A must complete before Task B starts) map to monday.com's Dependency column, which renders arrows between Items. Complex multi-chain dependencies may require manual review at monday.com if the dependency graph is circular or exceeds the three-level depth visible in monday.com's dependency view.