Migrate from InTouch to Odoo CRM

InTouch contact-company model diverges from Odoo res.partner architecture

InTouch maintains separate Contact and Company objects with a many-to-one relationship from contacts to companies. Odoo uses a single res.partner table where contact_type='company' represents organizations and contact_type='contact' represents people, with parent_id linking child contacts to the company partner. Migrations must establish the company partner first, then link contacts via parent_id. Contacts in InTouch without a company assignment migrate as standalone res.partner records without a parent, which is valid in Odoo but may affect reporting if your Odoo dashboard assumes company hierarchy. FlitStack generates the partner linkage plan before data loads so your admin can resolve any ambiguous assignments.

Odoo custom field creation must precede data migration

InTouch custom fields per matter template have no direct Odoo equivalents and cannot be created during the API data load. Odoo requires custom fields to be registered in ir.model.fields before records using those fields can be inserted. FlitStack delivers a custom field manifest that maps each InTouch field name to an Odoo Studio field (x_ prefixed, type-matched) on the target model (res.partner or crm.lead). Your Odoo admin must create these fields in the target environment before FlitStack runs the migration. The manifest includes the field label, technical name, type (char, selection, date, float, boolean), and whether the field should be required or searchable. Fields not created in time are skipped in the initial pass and flagged for a post-creation supplemental load.

Pipeline-to-team mapping requires Odoo team pre-configuration

InTouch pipelines have no native Odoo equivalent at the object level. Each InTouch pipeline must map to an Odoo crm.team record, and each pipeline stage must have a corresponding crm.stage record within that team. Odoo stage IDs are scoped by team_id, meaning the same stage name can exist independently in different teams. FlitStack cannot create Odoo teams and stages via the API without the appropriate Odoo administrator credentials and module access. The migration plan requires your Odoo admin to create the team-stage structure matching your InTouch pipeline topology before migration runs. If you skip this step, deals map to the default Sales Team and default stage sequence, which may not reflect your InTouch funnel order.

InTouch owner email resolution depends on existing Odoo users

InTouch stores owner references as user IDs with associated email addresses. Odoo requires owner assignment via user_id on crm.lead and write_uid on res.partner. FlitStack matches InTouch owner emails to res.users records by email. If an InTouch owner has no corresponding Odoo user account, the record attaches to a designated fallback user and the unassigned owner is flagged in the migration report. Your team must create Odoo user accounts for all active InTouch owners before migration, or accept the fallback assignments. This is especially important for audit and compliance scenarios where opportunity ownership must match the original InTouch assignee.

Activity history volumes can exceed Odoo batch API limits

InTouch records every call, email, meeting, and note as a separate activity. High-activity accounts can accumulate hundreds of thousands of activity records. Odoo's XML-RPC API has per-request payload limits and enforces transaction timeouts on large writes. FlitStack chunks activity migrations into batches of 500 records, inserting mail.activity, mail.message, and calendar.event records sequentially. Records with missing parent IDs (e.g., a call logged against an InTouch contact whose Odoo ID is unknown) are deferred to a second pass after all contacts and companies are confirmed in Odoo. This two-pass approach adds a small amount of migration time but ensures referential integrity across all activity links.