Migrate from Odoo Project Management to monday Work Management

Odoo Project records map directly to monday.com Boards. Project name becomes the Board name, description migrates as the Board description, and active/archived status is preserved. We map the project stage (if using Odoo's single-stage mode) to a default Board column. If the Odoo Project uses multiple custom stages, we create a monday.com Board with those stage names as initial Columns for the first group.

Odoo Task records map to monday.com Items within the appropriate Board group. Task name becomes Item name, description migrates to the Item's text description column, planned/effective dates map to date columns, priority maps to a label or priority column, and stage maps to the Board column where the Item lands. Closed/won/lost state from Odoo task kanban maps to the relevant Board column.

Odoo's parent-child task hierarchy (parent_id field) maps to monday.com Subitems. Each Odoo task with a non-null parent_id becomes a Subitem under the mapped parent Item. Subitem content includes name, description, dates, and assignee. Note that monday.com Standard and Pro plans support one level of subitems; if Odoo has multi-level nesting (task > subtask > sub-subtask), we flatten the deepest level into the first-level subitem and flag for admin review.

Odoo's per-project stages map to monday.com Board columns. Stage name becomes column name; stage color maps to column color if the destination Board uses color-coded columns. Odoo stages are project-scoped, meaning the same stage name can exist in multiple projects. We create a column per unique stage name per Board, and where stage names duplicate across projects, we consolidate to a single column name per Board unless the customer requests separate boards per project.

Odoo Tags are a shared taxonomy across Projects and Tasks. We export tag names and apply them as monday.com Tags on the migrated Items. monday.com Tags are global to the workspace; if the customer uses project-specific tag taxonomies in Odoo, we document the scope during scoping and apply the full tag set to all migrated Items, with a note for the admin to reorganize into separate tag groups post-migration if needed.

Odoo task assignees (many2one to res.users) map to monday.com Person column values. We resolve by email match against the monday.com workspace members list. Any task with a deactivated Odoo user is flagged in the data audit; we either map to a designated placeholder person or suppress the assignee field depending on customer preference. If the destination monday.com workspace does not yet have members provisioned, we hold assignee mapping for the provisioning step.

Odoo's hierarchical project structure (child projects under a parent project) maps to monday.com Board Groups within a single Board if the hierarchy is flat (two levels), or to a separate Board linked by an Item reference if the hierarchy is deeper. We determine the strategy during scoping based on the customer's project tree depth. Each subproject becomes its own Board with a reference item in the parent Board to maintain the relationship.

Odoo Milestones (available in Odoo Project Enterprise) contain a name and a deadline date. We create a date column on the project Board for milestone tracking and populate it with the milestone deadline. If multiple milestones exist per project, we add a label column to identify milestone-linked items or create a dedicated milestone tracking group. Milestone completion state maps to a status label.

Odoo task dependencies stored in project.task.dependency (predecessor_id, successor_id, type) map to monday.com Dependency column values. We export the dependency table as a mapping of source_task_id to dest_task_id, resolve the target Item IDs during migration, and set the Dependency column values on the successor Item. Note that monday.com dependencies work within a board and across boards via cross-board linking; we configure the dependency column type during board setup.

Odoo Timesheet lines (from project_timesheet) contain employee, date, duration, and task reference. We map these to monday.com Time Tracking column entries on the corresponding Item. Important caveat: Odoo timesheets link to employee cost rates that feed project profitability analysis; monday.com Time Tracking records duration only with no cost rate or payroll integration. We flag this distinction and recommend the customer decide whether non-billable time tracking scope is appropriate for the migration.

Odoo Studio custom fields (x_studio_* prefix) and code-defined custom fields migrate as monday.com custom columns. We map Odoo field types to monday.com column types: char/text to text, integer/float to numbers, date/datetime to date, many2one relations to person or board relation columns, selection fields to label or dropdown columns. We inspect the ir.model.fields table during discovery to capture all custom field names and types, and pre-create the destination columns before Items are imported.

Odoo ir.attachment records contain filenames, related record IDs, and creation timestamps but not the binary blob by default. We export attachment metadata and create monday.com file upload entries linked to the corresponding Item. The actual file blob does not migrate unless the customer scopes a separate file transfer step; we document the attachment filenames and related Item IDs so the customer can manually relocate files post-migration if needed.