Migrate from Unim to Odoo CRM

Unim Contact records map to Odoo CRM res.partner. The customer's name, email, phone, and address fields migrate directly. We resolve the country and state references via ir.model.data lookups so that partner addresses validate correctly. Owner assignment from Unim maps to res.partner.user_id via email-matched res.users. Custom fields on the Contact model migrate as custom fields on res.partner via Odoo Studio or a custom module created before the partner import phase begins.

Unim Company records map to Odoo CRM res.partner with is_company=True. The company name becomes partner name, and the domain or website migrates to website. We create res.partner records for companies before the Contact import phase so that individual Contact records can reference a parent partner_id for the company association. This satisfies Odoo CRM's hierarchical partner model and enables the Contact-to-Company linkage that drives the pipeline view.

Unim Activity records—calls, emails, notes, meetings—map to Odoo CRM mail.message entries linked to the target res.partner record via res_id and model=res.partner. Activity type, body content, timestamp, and owner reference migrate directly. We set message_type appropriately (email, call, note) and preserve the original timestamp so that the Odoo CRM chatter timeline reflects the true engagement chronology. Odoo CRM's mail.message does not require a separate Activity model; all interactions flow through the chatter thread on res.partner.

Unim exposes custom fields via a dedicated custom-fields API route. Each custom field has a Name, ModelID, DataType, and Nullable flag. DataTypes require a separate valuelists API call to resolve the reference ID before field creation. We introspect all custom fields during discovery, resolve their DataType IDs, and create matching fields in Odoo CRM via Studio (for simple types) or a custom module (for relational types). Field creation in Odoo must complete before the corresponding data import phase runs, so custom field definitions deploy first in every migration plan.

Bespoke entity types beyond standard Contacts, Companies, and Activities are defined at the application level in Unim and vary per deployment. We discover these via schema introspection during the discovery phase and create matching custom models in Odoo CRM by adding records to ir.model and ir.model.fields via XML-RPC. Each custom model's API name uses the Odoo naming convention (x_customentity), and lookup relationships to res.partner or crm.lead are established as relational fields. Admin configuration of the custom model's menu and view access is outside migration scope and is documented for the customer's Odoo admin post-migration.

Owner assignment on Unim records uses user-reference fields scoped to that specific Unim deployment. Owner IDs cannot be used directly in Odoo CRM. We extract every distinct owner ID referenced on contacts, companies, activities, and custom objects, then match by email address against the Odoo CRM res.users table. Any owner without a matching Odoo user goes into a reconciliation queue for the customer's admin to provision the corresponding user account before the record import phases run. Owner resolution must complete before any res.partner or crm.lead import because user_id is a required lookup on most CRM objects.

Unim attachments are served via the Files dimension, not inline with the record. Each attachment requires a separate API call to fetch the binary blob. For large migrations with many attachments, we paginate file extraction and apply retry logic on 429 responses. In Odoo CRM, attachments migrate to ir.attachment records linked via res_model=res.partner and res_id pointing to the target partner. Original filenames and MIME types are preserved. This mapping requires the res.partner import phase to complete before file association, so attachments run as the final phase after the record graph is stable.

Unim tag associations are stored as array fields or linked records depending on the specific deployment. We preserve tag-to-record linkages as a join table that maps to Odoo CRM res.partner.category records. The category.name migrates as the tag label. If the customer's Unim instance uses a large taxonomy of custom tags, we deduplicate and normalize before import to avoid Odoo CRM's tag explosion on the partner form. The customer chooses during scoping whether to migrate all historical tags or restrict to active-tagged records.

If the Unim deployment includes deal or opportunity entities, their stage values map to Odoo CRM crm.stage records. We create stage records in sequence order, set is_won and sequence fields to match the Unim stage properties, and configure fold=False for active stages so they appear in the Odoo CRM pipeline kanban view. The crm.stage configuration deploys before any crm.lead or crm.opportunity import so that stage lookups resolve at insert time.

Unim entities serving as sales prospects (leads) map to Odoo CRM crm.lead. The lead's name, email, phone, source, and description migrate directly. The stage field maps to crm.stage via the stage configuration phase. Priority and tag_ids migrate to crm.lead priority and category_ids respectively. Owner assignment uses the resolved res.users lookup. In Odoo CRM, crm.lead serves as the initial pipeline entry; conversion to res.partner (for new contacts) and crm.opportunity (for pipeline tracking) happens post-migration in the Odoo CRM UI or via the crm.lead convert wizard.

Unim opportunity records map to Odoo CRM crm.opportunity. The opportunity name, expected revenue, priority, probability, and partner_id (linked company) migrate directly. Stage maps to crm.stage via the stage configuration. Date_deadline migrates to crm.lead date_deadline. The user_id maps to res.users via the owner reconciliation phase. Odoo CRM's crm.opportunity kanban view and forecasting features become the primary pipeline management interface post-migration.

Webhook configurations in Unim are environment-level settings tied to that deployment's API and event model. They cannot be meaningfully exported and re-imported into Odoo CRM's webhook system, which uses different event types and payload schemas. We document active webhooks in the Unim instance as a written inventory for the customer's awareness and include Odoo CRM's webhooks documentation as a reference for the admin to rebuild post-migration.