Migrate from Data Team DDS to Odoo CRM

Data Team DDS contacts and leads map to Odoo's crm.lead model. We read the source entity type field and set Odoo's type='lead' for raw leads and type='opportunity' for qualified records. The partner_id field links each lead to a res.partner record created from the source company entity. This keeps lead and opportunity data in one Odoo model rather than split across separate objects.

Source company records map to res.partner with partner_type='company'. Odoo stores companies and contacts in the same table using a type discriminator — companies use type=False (default) while contacts set type='contact' and carry a parent_id link to the company partner. We extract the company name, domain, industry, and address fields and write them to the partner record.

Individual person records from Data Team DDS migrate as res.partner with type='contact' and parent_id pointing to the corresponding company partner. This mirrors Odoo's address-book model where contacts are subordinate to companies. Email, phone, job title, and address fields map directly. For contacts without a company in the source, we create a placeholder company partner and link the contact to it.

Deals in Data Team DDS set crm.lead type to 'opportunity' and populate stage_id from the mapped pipeline stage. The expected_value field carries the deal amount; Odoo's currency_id defaults from the company setting unless the source carries explicit currency data. We preserve the original close date as a custom field since Odoo's date_closed is set when the stage reaches a closed-won or closed-lost state.

Each Data Team DDS pipeline stage maps to a crm.stage record scoped to the target crm.team (sales team). We create stages in Odoo first, then reference them by name during lead and opportunity import. Stage sequence order and probability values transfer value-by-value. Stage-entered timestamps from the source are stored as custom datetime fields on crm.lead since Odoo's native stage-change log starts at migration time.

Calls, emails, and meeting records in Data Team DDS become crm.activity lines on the related crm.lead. Odoo's activity model uses activity_type_id to classify the action (call, email, meeting, upload), with user_id for the assigned sales rep and date_deadline for scheduling. Completed activities log a mail.message on the lead record with the original timestamp and body content preserved.

Data Team DDS owner groups or team assignments map to crm.team in Odoo. Each team owns a set of crm.stage records. We resolve team membership by matching group names to Odoo team names or creating new teams as needed. Team members (sales reps) link via crm.team member records pointing to res.users.

Owner resolution runs by email match — each Data Team DDS owner identifier is matched against Odoo's res.users email field. Unmatched owners are flagged before migration commits. You either invite them to Odoo first or assign their records to a fallback user. No crm.lead lands without a valid user_id in Odoo, which is required for activity assignment and pipeline visibility.

Non-standard properties from Data Team DDS require custom fields in Odoo. Simple fields use Odoo Studio (x_studio_ prefix, immediate view inclusion, no restart needed). Fields needing computed logic, domain filters, or relational behavior require a Python module with state='manual' in ir.model.fields. We inspect each custom property's data type and recommend the appropriate creation method in the migration plan.

File attachments associated with leads, contacts, or opportunities in Data Team DDS re-upload to Odoo's ir.attachment model linked via res_model='crm.lead' and res_id pointing to the target record. Odoo stores files in its filestore directory; we re-upload the binary content directly via XML-RPC so attachments appear on the record's Documents tab.

The original Data Team DDS record identifier is stored as a Char field (x_source_id) on crm.lead and res.partner. This serves two purposes: it enables delta-run de-duplication when the migration re-runs and it gives your team a cross-reference to look up the original record during reconciliation.

Odoo's create_date is set when records land in the database — it cannot be backdated. We preserve the original Data Team DDS creation timestamp in a custom Char field (x_original_create_date) so reporting tools can show historical record age and so date-based segmentation in Odoo reflects the actual customer lifecycle rather than the migration date.