Migrate from Link app to Odoo CRM

Custom field migration is schema-first in Odoo — custom fields must exist before data lands

Odoo does not accept arbitrary key-value custom fields during import the way a JSON document store would. In Odoo Community, custom fields are defined in a Python module that adds them as column definitions to the target table. In Odoo Enterprise, they can be added via Studio or the technical menu before import. If custom fields are created after data is loaded, the existing records will not have values in those fields until a retroactive write-back is run. FlitStack AI audits all Link App custom fields during the discovery phase and generates the Odoo field definitions that must be installed before the migration run — this is delivered as part of the pre-migration schema checklist.

Activity data splits across three Odoo models — call, meeting, and note each use different tables

Link App stores calls, meetings, and notes as three variants of a single activity object differentiated by a type field. Odoo splits these into three distinct models: crm.phonecall (calls), calendar.event (meetings), and mail.message (notes). The activity type value in Link App determines which Odoo model receives the record, and each model has its own field schema — call records use a duration integer, event records use start and stop datetime fields, and note records use a body HTML field. This means the activity migration is not a single pass; each activity type runs as a separate load against its target model. Activity records that fail type resolution are flagged for manual review rather than silently dropped.

Partner foreign-key sequence must load companies before contacts before opportunities

Odoo enforces referential integrity at the ORM level — res.partner.parent_id requires the parent partner to already exist, and crm.lead.partner_id requires a valid res.partner record. Link App does not enforce this load order. FlitStack AI sequences the migration as a three-pass process: companies (type=company) load first and become Odoo res.partner records with IDs assigned; contacts load second with their parent_id resolved to the already-existing company partner; deals load last with partner_id resolved to the already-existing contact. If a Link App contact references a non-existent company, the contact is loaded with parent_id null and flagged for a post-migration cleanup step where the company is backfilled.

Odoo stores attachments in its filestore — URL-based files require a re-upload pass

Link App attachments are served from the Link App CDN as download URLs and do not live in the target Odoo database by default. Odoo's ir.attachment model stores files in its own filestore directory, referenced by a name field and a store filename computed from the file's SHA1 hash. When migrating files from Link App, FlitStack AI downloads each attachment binary, computes its hash, writes it to the Odoo filestore path, and creates an ir.attachment record with the correct res_model, res_id, name, and store_fname. Large files may exceed Odoo's default attachment file size limit — this is configurable in Odoo's system settings before migration.

Odoo pick-list fields require explicit value creation — unmapped values silently fail

When a Link App custom field has a pick-list type with specific allowed values, those values must exist as selection options in the corresponding Odoo field definition before the migration runs. If a Link App pick-list value does not have a matching Odoo selection option, the Odoo import will silently skip that value or raise a validation error depending on the Odoo version and import method. FlitStack AI generates a pick-list value map during the audit phase — for each Link App pick-list value, the migration plan specifies whether to map it to an existing Odoo selection value, create a new selection option in the Odoo field definition, or store it as a custom char field if no mapping is desired. This plan is reviewed with the team before any field definitions are modified.