Migrate from Odoo Project Management to Jira

Odoo Projects map directly to Jira Projects. We map project name, description, active/archived status, and user assignment (project manager). Archived Odoo projects require explicit inclusion during scoping; Jira archived projects are preserved via the Jira archive feature on Premium and Enterprise tiers. Jira project type (team-managed or company-managed) is chosen during scoping based on the customer's governance model.

Odoo Tasks map to Jira Issues (standard Issue type). We map task name, description, planned/hours/effective dates, priority (Odoo priority 0-1 maps to Jira Highest/High), and tags. Subtasks inherit the parent project's Jira project key and map to Jira Subtask issue type with the parent issue reference set via the parent field. Tasks that exist without a project in Odoo require a default Jira project to be designated during scoping.

Odoo parent-child subtask hierarchies map to Jira Subtask issue type. The parent Odoo task becomes the Jira parent Issue; the child Odoo task becomes a Jira Subtask linked via the parent field. Nested subtasks beyond one level in Odoo are flattened to a single Jira subtask level, with multi-level hierarchy notes preserved in the subtask description for the customer's admin to reorganize post-migration.

Odoo uses project-scoped stages (configurable names, colors, and sequence per project) while Jira uses global statuses per workflow shared across projects. We map Odoo stage names to Jira status values in a new Jira workflow, applying the stage sequence as the status category order (To Do, In Progress, Done). When multiple Odoo projects have different stage names, we either flatten them to a common status set per workflow or create separate Jira workflows per project.

Odoo Tags are a shared taxonomy across Projects and Tasks stored as a separate ir.model.data record set. We export tag names and apply them to Jira issues as Labels. Jira Labels are case-sensitive and comma-separated; we preserve Odoo tag names exactly and flag any that contain characters unsupported by Jira Labels (brackets, pipes, colons) for manual review.

Odoo task assignees link to internal Users via a many2one field on res.users. We export user IDs and email addresses, then resolve by email against the Jira destination's user base. Deactivated Odoo users whose task assignments would break on import are flagged in the data audit; we map them to a designated placeholder user or suppress the assignee field per customer preference. Jira Cloud requires Atlassian accounts, which must be provisioned before migration if Odoo users lack corresponding Jira accounts.

Odoo Studio custom fields (x_studio_* prefix, Enterprise-only) and code-defined custom fields (x_name_* prefix) are stored in the same table as standard fields. We detect all custom field names and types from ir.model.fields during discovery, then pre-create corresponding Jira custom fields (customfield_*) via the Jira REST API before any data import. Field types are mapped: Odoo char/text to Jira Text Field, Odoo float/integer to Jira Number Field, Odoo date to Jira Date Picker, Odoo many2one to Jira User Picker or Project Picker.

Odoo Milestones (Enterprise plan) represent deadline checkpoints within a project. We map milestone name and deadline date to Jira Fix Version (released or unreleased version associated with the project). If the milestone has a state (reached/not reached), we map it to Fix Version status (released, unreleased, or archived). Odoo milestones without a deadline are created as unreleased Fix Versions.

Odoo Gantt predecessor/successor links stored as a dependency table (source_task_id, dest_task_id, type) map to Jira issue links. We reconstruct Odoo dependency chains as Jira Blocks/Is blocked by links between issues. Circular dependency chains detected in Odoo are flagged and resolved by removing the smallest-impact link to break the cycle before import. If the destination uses the Jira Structure app for hierarchical work breakdown, we can optionally output the dependency table as Structure rows.

Odoo Timesheet entries (project_timesheet app) record employee, date, duration, and task reference. We export these as Jira Worklog entries linked to the corresponding migrated issue. Note that native Jira time tracking must be enabled in the destination project settings. If Jira time tracking is disabled or the customer uses a third-party app (Tempo, Clockify), we deliver a CSV of worklogs with issue key, author, date, duration, and description for post-migration ingestion.

Odoo attachments stored as ir.attachment records with binary blobs are not migrated by default. We export attachment metadata (filename, related record ID, creation date) as a CSV inventory for manual re-upload. Jira Cloud attachment import via REST API requires files to be re-uploaded individually, which is scoped as a separate manual step outside standard migration.

Odoo chatter stores message threads (internal notes, emails, activity logs) in mail.message linked to mail.thread. These are tightly coupled to Odoo's mail module and cannot be reliably reconstructed in Jira. We do not migrate chatter history. We deliver a written inventory of all Odoo project and task threads (record ID, thread type, message count, date range) so the customer's admin can assess whether any critical notes require manual transcription.