Migrate from Affinity Fieldreach to Odoo CRM

Affinity Persons map directly to Odoo res.partner records. The partner_type field is set to 'contact' for all migrated Persons. Primary email from Affinity populates email on res.partner, and phone populates phone. Affinity Person IDs are stored in a custom source_id field for traceability.

Affinity Organizations map to res.partner with partner_type set to 'company'. Company names populate the name field. Domain URLs map to website. Additional fields such as industry, employee count, and annual revenue are mapped to their corresponding Odoo partner fields. Parent-child organization hierarchies in Affinity map to parent_id on res.partner, resolved in dependency order during migration.

Affinity's N:N Person-to-Organization relationships collapse into Odoo's res.partner model where each Person's primary Organization becomes the commercial_partner_id. Secondary affiliations are preserved as a custom relation table until your team decides on a consolidation rule. The migration includes a detailed report of all secondary links, storing source_affinity_id for each affiliation so you can later merge or tag them in Odoo without re-importing data.

Affinity Deals migrate to Odoo crm.lead as opportunities. The deal name maps to name, amount maps to expected_revenue, and close date maps to date_deadline. Owner resolves by email match to Odoo res.users records. Deal stage translates via a value_map to the appropriate crm.stage, and probability weights are re-applied according to Odoo's stage configuration. Custom fields on deals are created in ir.model.fields before the deal batch loads.

Affinity deal stages map to Odoo crm.stage records via a value-mapping table. Each Affinity stage name gets a corresponding Odoo stage_id within the target team's stage_ids. Stage sequence order and probability weights are preserved from Affinity's stage configuration. After migration, you can adjust stage names, add new stages, or reassign probability weights directly in Odoo's pipeline view without affecting the underlying data.

Affinity activity records (calls, emails, meetings) migrate as Odoo mail.activity entries linked to the corresponding crm.lead or res.partner via res_model and res_id. Activity type, summary, and date are preserved; owner maps by email to res.users. If an activity has an associated note or attachment, those are migrated separately as mail.message or ir.attachment records linked to the same res_model and res_id, ensuring a complete activity history in Odoo.

Affinity notes attached to Persons, Organizations, or Deals become Odoo mail.message records with message_type='comment'. Body content preserves plain text; rich-text notes are converted to HTML for Odoo's message rendering. The note author is resolved by email to a res.partner, and any file attachments are stored as ir.attachment records linked to the same message, keeping the full note context intact.

Affinity custom fields on Persons require Odoo custom field creation via ir.model.fields before data loads. Char fields map directly; selection fields require value_mapping; multi-select fields need dedicated relation tables or serialized storage. We preserve the original Affinity field label as the Odoo field name and generate a unique technical name (e.g., x_affinity_cf_<id>) to avoid conflicts. Field visibility can be restricted to specific user groups if needed.

Organization custom fields migrate similarly to Person custom fields. Odoo custom fields are created with the same label as the Affinity fields, and a technical name (e.g., x_affinity_org_<id>) is generated to avoid conflicts. Field type determines the transformation — char fields map directly, selection fields use value_mapping, and multi-select fields are stored via dedicated relation tables or serialized fields. Definitions are created in ir.model.fields before the organization batch loads.

Deal-level custom fields in Affinity map to custom columns on crm.lead in Odoo. The field type from Affinity (text, number, date, picklist) determines the Odoo field type (char, float, date, selection) and any required value_mapping. Multi-select fields are stored via dedicated many2many tables or serialized JSON in a char field. Custom columns are created in ir.model.fields before the deal batch is imported, and field help text is copied from Affinity.

Affinity file attachments download from Affinity's storage URLs and re-upload to Odoo via ir.attachment create() calls. The original filename, mimetype, and create date are preserved. Attachments link to res.partner or crm.lead via res_model and res_id. A backup of the original Affinity URL is stored in a custom field for reference, and large files are saved as bytea in PostgreSQL or on the filesystem depending on your Odoo configuration.

Affinity owner IDs resolve by email match against Odoo res.users. Unmatched owners are flagged before migration — your Odoo admin either creates the user or assigns records to a fallback owner before the migration commits. For traceability, the original Affinity owner identifier is stored in a custom source_owner_id field on each record. If many owners are missing, a user-provisioning script can be run before the migration to reduce fallback assignments.