Migrate from Followup CRM to Odoo CRM

Followup CRM Contact and Company objects collapse into Odoo res.partner — 'Is a Company' flag is the only differentiator

Followup CRM maintains Contacts and Companies as separate database objects with a one-to-many relationship (one Company, many Contacts). Odoo CRM consolidates both into a single res.partner table where the company_type field ('person' vs 'company') and the parent_id / child relationships determine hierarchy. During migration, every Followup CRM Company record must land as a res.partner with company_type = 'company', and every Contact must land with company_type = 'person' and a parent_id pointing to the migrated Company. If a Followup CRM Contact has multiple associated Companies, only the primary company becomes the parent_id — additional company associations require a custom partner relation model in Odoo or manual re-linking post-migration.

Followup CRM Goals have no Odoo native equivalent — bid volume targets and revenue quotas must be rebuilt as custom fields

Followup CRM's Goals dashboard tracks bid volume targets, team revenue quotas, and quota achievement percentages across the sales team. Odoo CRM has no built-in Goals or quota-tracking module — the functionality does not exist in the crm.lead model by default. FlitStack migrates the raw numeric values (bid volume, revenue target, quota achieved) as custom fields on crm.lead, but the visual Goals dashboard with progress bars, team comparisons, and quota-vs-actual reporting must be rebuilt in Odoo using the CRM reporting app or a custom dashboard module. This is not a data-loss issue but a functional gap that requires Odoo configuration work after migration to restore the same visibility.

Odoo stage probability lives on crm.stage records, not on crm.lead — stage mapping requires per-team configuration

In Followup CRM, each deal stage carries a probability percentage stored directly on the stage definition. In Odoo CRM, stage probability is a float field on the crm.stage record itself, and each sales team (crm.team) has its own set of stage records. This means that mapping Followup CRM pipeline stages to Odoo requires creating crm.stage records within the appropriate crm.team for each pipeline, setting the probability values on those stage records, and ensuring the stage sequence order matches Followup CRM's pipeline flow. Teams with multiple Followup CRM pipelines need multiple crm.team records with their own crm.stage chains. The migration plan must include a stage-definition map showing which Followup CRM pipeline stage maps to which Odoo crm.stage within which team.

Followup CRM custom fields must be pre-created in Odoo before data import — they don't migrate as records

Followup CRM stores custom field definitions in its System Custom Fields section and allows data import into those custom fields via CSV mapping. Odoo CRM handles custom fields differently: they must be defined as field records in Odoo Settings > Technical > Custom Fields (or as x_<fieldname> Python fields in custom modules) before any data can be loaded into them. There is no automatic import of custom field definitions from Followup CRM. FlitStack exports the complete list of Followup CRM custom field names, types, and pick-list values so Odoo admins can create matching fields in Odoo before the migration run. If custom fields are not pre-created, the migration loads data into the standard fields only and custom field values are lost.

Followup CRM activity history converts to Odoo chatter messages — activity type and owner resolve differently

Followup CRM stores Tasks, Follow-ups, Emails, and Calls as separate activity record types with owner, timestamp, and body content. Odoo CRM logs all these as mail.message records on the related crm.lead or res.partner chatter — the activity type distinction (call vs email vs note) is preserved as the message sub-type, but the record structure changes. The owner resolution process differs: Followup CRM owner IDs resolve to Odoo res.users by email match; if no match exists, the message author defaults to the Odoo admin user rather than remaining unassigned. This means activity attribution may shift for records owned by users who are not yet set up in Odoo at migration time.