Migrate from Sage CRM to Odoo CRM

Sage CRM Companies map directly to Odoo res.partner records with is_company=True. The Sage PrimaryCompanyLink field is replaced by Odoo's partner relationship model (contacts are res.partner with is_company=False linked via parent_id). Company address, industry, and classification fields map to street/city/state/country, industry_id, and custom tag fields. We use company name as the dedupe key and create the Company record before any linked Contact or Opportunity imports so that parent_id references resolve correctly.

Sage CRM Contacts map to Odoo res.partner with is_company=False. The PrimaryCompanyLink foreign key resolves to the parent_id field on the Odoo res.partner record. Custom Contact fields and Sage communication preferences map to Odoo custom fields on res.partner. Sage match-rule deduplication settings are reviewed during scoping; Odoo's duplicate detection uses name and email matching which may identify different record pairs, so we flag potential duplicates before import rather than assuming identical deduplication outcomes.

Sage CRM Leads (a separate entity from Contacts with their own lifecycle stages, qualification fields, and source tracking) map to Odoo crm.lead records. The Sage Lead status and source fields map to Odoo's stage_id and source_id. Sage custom lead fields migrate to Odoo crm.lead custom fields. Note that Odoo's crm.lead serves both as a Lead before qualification and as a Pipeline Opportunity after stage progression; we preserve the original Sage Lead entity designation in a custom field sage_lead_entity__c for audit.

Sage CRM Opportunities map to Odoo crm.lead records at an advanced pipeline stage. The Sage pipeline stage, revenue amount, expected close date, and owner assignment map directly to Odoo's stage_id, planned_revenue, date_closed, and user_id. Custom opportunity fields and multi-currency amounts migrate to Odoo custom fields. We resolve the primary Company link to the Odoo res.partner parent_id at migration time.

Sage CRM Cases (service/ticket object) map to Odoo helpdesk.ticket. Sage severity, status, and assignment fields map to Odoo's priority, stage_id, and user_id. Case-threaded communications stored in the Sage Communication table link to cases by entity ID; we migrate these as Odoo message_ids attached to the helpdesk.ticket, preserving the thread structure and timestamps. If the destination Odoo instance does not include the helpdesk module, we map Cases to crm.lead with a custom case_type tag as an alternative.

Sage CRM Communication records (emails, call logs, meeting notes linked entity-type agnostically to Company, Contact, Lead, Opportunity, or Case) map to Odoo mail.message for email and meeting content, and note.note for standalone notes. We resolve the entity type and record ID at migration time to set the correct res_model and res_id on the Odoo message. Call disposition and duration from Sage Communication records migrate to custom fields on the Odoo note.

Sage CRM Custom Entities have both a display name and an internal database table name (e.g., CustomEntityname) that the REST and SOAP APIs reference. We inspect the entity schema via the API model service during scoping, cross-reference the internal name with the UI display name, and then either map the Custom Entity to an Odoo custom model (if it has lookup relationships to standard entities) or to res.partner tags and notes (if it functions as a related-records container). Odoo custom models require a module installation step before field creation; we coordinate this during the schema design phase.

Sage CRM workflow rules are stored as database records with embedded ASP-script logic, escalation triggers, and action definitions. These cannot be extracted as portable configuration and do not migrate to Odoo. We produce a written workflow inventory during discovery that documents every active Sage CRM workflow rule with its trigger conditions, stage-transition logic, escalation timing, and assigned actions. The customer's Odoo admin or an Odoo implementation partner uses this inventory to rebuild equivalent automation logic in Odoo Studio. This is manual rebuild work and is scoped separately from data migration.

Sage CRM reports store definitions in the report schema with entity field references by internal IDs. We export report definitions and underlying data, but report formatting, formula logic, scheduling, and distribution settings cannot be transferred as configuration. We deliver a written report inventory listing every Sage CRM report with its data source, filters, and chart type so the customer's admin can recreate the reports in Odoo's reporting module. Sage CRM reports that reference Custom Entities require those entities to be migrated first before report recreation can begin.

Sage CRM Users with role-based security profiles map to Odoo res.users. We resolve users by email match and map Sage security profile permissions to Odoo access groups and record rules. Sage CRM access-control structures (object-level and field-level restrictions) differ structurally from Odoo's permission model (groups via xmlid references, record rules for row-level access). We flag permission gaps where a Sage CRM security profile has no direct Odoo equivalent and document the recommended Odoo group configuration.

Sage CRM custom ASP pages, COM components, and server-side scripts are server-side code that has no equivalent in Odoo's Python-module architecture. These cannot be exported or migrated. We document every active custom ASP component identified during the discovery audit, describe its functional purpose and data dependencies, and deliver this as a technical reference for the customer's development team to evaluate for Odoo Python module equivalents. This is out-of-scope for data migration.

If the customer uses the Sage CRM Self-Service Portal for customer-facing case submission or lead capture, we document the portal configuration (portal pages, exposed entities, access rules) as a reference for Odoo Portal recreation. Odoo Portal is included in paid Odoo tiers and uses the same access group model as internal Odoo users. Portal configuration migration is out-of-scope as it requires access-control design decisions by the customer's admin.