Migrate from Evatic to Odoo CRM

Evatic API exports in paginated JSON batches that must be assembled before transformation

Evatic Connect (ESH) returns data via paginated JSON payloads, sometimes splitting one logical object type across multiple API pages depending on the export configuration. FlitStack paginates through all available pages and assembles complete record sets before transformation begins. A separate risk: API token scope must include read access for every target object — contacts, contracts, units, and activities. If token scope is too narrow, those object types silently return zero records. We validate token permissions against all required objects before any data is pulled, flagging any scope gaps immediately so you can update the token configuration before the migration begins.

Odoo Community Edition has no native recurring billing model without the Subscription app

Evatic service contracts with recurring billing lines — monthly maintenance fees, annual support charges, or per-visit billing — have no direct equivalent in Odoo CRM's base model. The Odoo base CRM treats all line items as one-time entries on a sale.order. Recurring contract lines require the Odoo Subscription app, which is a separate installation beyond the CRM module. We identify every Evatic contract that contains recurring line items during the audit phase and surface this as a pre-migration decision point: either install Odoo Subscription before migration or map recurring lines as one-time sale.order.line entries and build renewal workflows manually in Odoo.

Odoo's lead/contact split means contract status determines migration record type at migration time

In Evatic, contacts and contracts are flat records with no distinction between a prospect and a customer. In Odoo CRM, every record entering the pipeline is a crm.lead — it is either type='lead' (unqualified prospect) or type='opportunity' (qualified deal with a linked partner). We determine the record type from the Evatic contract status at migration time: active or won contracts map as type='opportunity' with partner_id populated from the linked Evatic account; contracts with status='New' or no contract at all map as type='lead'. This means the same Evatic contact can appear as a Lead or an Opportunity depending on whether it has a linked signed contract — your sales ops team reviews the type assignment logic before the full run.

Odoo custom fields require manual UI placement after migration — they exist but are hidden

When FlitStack creates x_name custom fields on Odoo models via the XML-RPC API, the field definition is stored in Odoo's ir.model.fields table and the data migrates correctly. However, Odoo does not automatically display new custom fields on form views — an admin must open the Form Editor for each model (crm.lead, product.product, res.partner), drag the field from the Custom Fields section onto the view, and save. We deliver a custom field placement checklist listing every migrated field, its target model, and suggested view position so your Odoo admin can place them without hunting through field lists.

Odoo self-hosted deployments require filestore path configuration before attachment re-upload

Evatic file attachments — service reports, equipment photos, contract scans — are downloaded and re-uploaded to Odoo's ir.attachment filestore during migration. Odoo enforces a 100MB per-file limit (configurable in system parameters). Files exceeding this limit are flagged pre-migration for manual handling. For self-hosted Odoo deployments, the filestore path (ir_attachment.location) must be configured before migration runs — if it points to a local directory that does not exist or lacks write permissions, the attachment re-upload fails silently for some records. We check filestore write access during the pre-migration validation step.