Migrate from ELMA365 to Odoo CRM

ELMA365 stores contact records as participants or assignees on Tasks and Projects rather than in a dedicated contact directory. We extract unique contact records across all Tasks and Projects, deduplicate by email, and map to Odoo res.partner. Name, email, phone, and address fields map to standard res.partner fields. The is_company flag is inferred from whether the ELMA365 record represents an organization or individual.

ELMA365 organizations stored as company references within Tasks or custom Applications map to Odoo res.partner with is_company=True. We extract the organization's name, domain, industry, and address fields. The res.partner record is created before any linked contact records so that the contact's parent_id lookup is satisfied at insert time.

ELMA365 Tasks with business context (linked to a company or contact, carrying deal value or deal stage) map to Odoo crm.lead. Task title becomes crm.lead name; Task description maps to crm.lead description; due_date maps to crm.lead date_deadline. If the Task carries a monetary value or pipeline stage assignment, we map it to crm.lead expected_revenue and a configured stage in the destination crm.lead.stage model.

ELMA365 Projects may contain both CRM-relevant data (client name, deal value, pipeline stage) and project management data (milestones, resource assignments). We split on discovery: CRM-relevant fields migrate to Odoo crm.lead as the deal record, and project management fields migrate to Odoo Project (if the customer licenses the Project app) with a link to the crm.lead via a Many2one. Tasks within the Project migrate to Project Task records linked to the Odoo Project.

ELMA365 Process Instances carry workflow state, current step, and business data. We extract the instance fields and map the process name to Odoo crm.opportunity name, the current step to a mapped stage in crm.opportunity.stage_id, and any deal value or date fields to expected_revenue and planned_revenue_close_date. Historical process steps are not migratable as workflow history; we document the final state and a process step summary as notes on the Odoo opportunity.

ELMA365 custom Applications store data in user-defined tables. We reverse-engineer the schema from ELMA365's configuration export and map each custom Application to an Odoo custom model with a matching field structure. Custom fields use Odoo's ir.model.fields with appropriate field types. Lookup relationships between custom Applications map to Odoo Many2one or Many2many depending on the original cardinality.

ELMA365 users, their display names, email addresses, and active status map to Odoo res.users. We match by email as the dedupe key. ELMA365 roles (configured in the BPM designer) map to Odoo access rights groups during scoping; the customer chooses which role-to-group mapping to apply since Odoo and ELMA365 permission models differ structurally.

Documents attached to ELMA365 Tasks, Projects, or Process Instances are downloaded from ELMA365's file store and re-uploaded to Odoo's ir.attachment table, linked to the corresponding crm.lead, res.partner, or Project record via res_model and res_id. Folder hierarchy from ELMA365 is preserved as a directory path in the attachment's name field for manual reorganization in Odoo Documents or Knowledge.

Electronic HR documents (employment contracts, e-signatures) from ELMA365's КЭДО module migrate as ir.attachment records linked to hr.employee in Odoo if the HR app is licensed. E-signature metadata is preserved as attachment description; the legal validity of signatures must be re-established in the destination jurisdiction per the customer's legal team.

ELMA365 BPM workflow definitions store as proprietary JSON configuration and cannot be exported or re-imported into Odoo. We flag every active BPM workflow during discovery and deliver a written inventory listing the workflow name, trigger, steps, conditions, and assignees. The customer rebuilds these as Odoo Automated Actions or Studio workflows post-migration.

ELMA365 RPA robot definitions are proprietary to the ELMA365 RPA engine and do not transfer to any external platform. We flag every RPA configuration during discovery and document the automation purpose (data entry, screen scraping, form fill). The customer rebuilds these in Odoo RPA (a separate paid app) or accepts manual process re-entry.

ELMA365 Reports and BI dashboards use the platform's native reporting engine and cannot be exported. We extract the underlying data for all reports during migration so the same dataset is available in Odoo Reporting or a connected BI tool. The customer rebuilds reports as Odoo Pivot Views, Graph Views, or exports to a BI platform such as Metabase or Power BI.