Migrate from myCRMS.com to Odoo CRM

myCRMS.com Contact records map to Odoo res.partner with is_company=False. The contact's primary email becomes email, phone becomes phone, and address fields map to street, city, state_id, country_id, and zip. Custom fields discovered during the pre-migration audit create corresponding ir.model.fields on res.partner. We load res.partner records before any child contact records to satisfy the parent_id lookup if myCRMS stores hierarchical contact relationships.

myCRMS.com Company records map to Odoo res.partner with is_company=True and is_company flag set. Company domain becomes website field. The company name maps to name, and any industry, employee count, or revenue fields migrate as custom fields on res.partner. Company records are loaded first so that Contact records can reference them via parent_id during insertion.

myCRMS.com Deal records map to Odoo crm.lead with type='opportunity'. The deal name becomes name, stage data maps to stage_id through Odoo's stage configuration, and amount maps to expected_revenue. Owner assignments from myCRMS map to user_id on crm.lead by email matching against Odoo res.users.

Each distinct myCRMS.com pipeline stage value becomes an Odoo crm.stage record within the relevant crm.team. Stage sequence order migrates to sequence, and probability percentages map to Odoo's probability field on crm.lead. We configure stage names to match myCRMS labels for user recognition post-migration.

myCRMS.com deal pipelines map to Odoo crm.team records. Each team gets its own Kanban view with stages scoped to that team. If myCRMS uses multiple pipelines to segment lines of business, each becomes a separate crm.team with its own team leader and member assignments resolved from owner data.

myCRMS.com owner assignments on Contact, Company, and Deal records resolve to Odoo res.users by email match. Any myCRMS owner without a matching Odoo user is held in a reconciliation queue for the customer's admin to provision before record import resumes. We cannot insert records with user_id references that do not exist in the destination.

myCRMS.com call activity records map to Odoo mail.activity with activity_type_id set to the built-in Call type. Call duration and disposition migrate to custom activity fields. ActivityDate from myCRMS sets the deadline and activity_date on mail.activity. The activity.res_model and res_id link to the migrated res.partner or crm.lead record.

myCRMS.com meeting activity records map to Odoo calendar.event. Start datetime, end datetime, and location migrate to start, stop, and location. Attendees link via calendar.attendee records pointing to the migrated res.partner contacts and res.users team members.

myCRMS.com task activity records map to Odoo mail.activity with activity_type_id set to the built-in To-Do type. Task subject becomes mail.activity.title, status maps to activity_date or deadline depending on myCRMS field semantics, and owner assignment resolves to user_id via the res.users mapping.

myCRMS.com note activity records map to Odoo mail.message linked to the parent res.partner or crm.lead via res_id and model. Note body migrates as HTML content preserved in body_html. Message creation date and author (mapped to res.users) are set from myCRMS timestamp and owner data.

myCRMS.com Smart List filter logic migrates to Odoo ir.filters records scoped to the relevant model (res.partner or crm.lead). We translate myCRMS filter conditions into Odoo domain expression syntax during the pre-migration audit. Each Smart List becomes a named saved view that the customer's admin assigns to specific users post-migration. This translation is documented as a written handoff, not an automated recreation, because Odoo domain syntax differs from myCRMS filter builder semantics.

Any custom field schemas discovered on myCRMS.com Contact, Company, and Deal records during pre-migration audit are pre-created in Odoo as ir.model.fields on res.partner and crm.lead before data import begins. Field types are mapped: text fields to char or text, numeric fields to float or integer, date fields to date, dropdown fields to selection. Many2one and many2many custom fields require corresponding Odoo models to exist first, which we coordinate during the schema design phase.