Migrate from Opera 3 to Odoo CRM

Opera 3 Sales Ledger contacts export via CSV with full address fields, payment terms, credit limits, and multi-currency settings. We map the contact record to Odoo Contact, preserving the account reference code as the Odoo internal reference. Multi-currency settings from Opera 3 become currency_id on the Contact if the destination uses the multi-company or multi-currency configuration.

Opera 3 Purchase Ledger suppliers export as a separate CSV from Sales Ledger contacts. We map them to Odoo Contacts with the Supplier checkbox enabled, preserving the supplier account code as the internal reference. Bank details, payment terms, and tax numbers carry across as custom fields or notes depending on the Odoo configuration.

Opera 3 Sales Order headers and line items export via CSV with pricing, discounts, delivery addresses, and status flags. We map order headers to Odoo Sale Order and line items to Sale Order Lines with product code resolved to Odoo Product2 records. The order-to-invoice linkage chain is preserved by mapping the Opera 3 order reference to the Odoo client_order_ref field.

Opera 3 Purchase Order headers and line items export similarly to Sales Orders. We map Purchase Order headers to Odoo Purchase Order and line items to Purchase Order Lines. Vendor product codes from Opera 3 map to Odoo product supplierinfo records to preserve the vendor-specific part number on purchase orders.

Opera 3 Sales Invoices export with header totals and detail lines. The system enforces that invoice totals equal the sum of line items, so we validate this relationship before loading. We map invoice headers to Odoo Account Move (type=out_invoice) and line items to move lines with account_id resolved from the Opera 3 nominal code mapping. PDF invoice attachments migrate as Odoo IrAttachment linked to the move.

Opera 3's built-in CRM module stores contacts and companies with text-based activity logs. We map active CRM contacts to Odoo Leads first, then convert unqualified records to Leads and records with active deals to Contacts with a related Opportunity. The activity note log is parsed and reclassified into Odoo activity types (call, email, meeting, task) during the transformation step.

Opera 3 stores CRM activities as plain text notes with timestamps rather than structured events. We parse each note for type indicators (call, meeting, email reference, task) and map the content to Odoo Mail Activity records with the appropriate activity_type_id, user_id resolved from the Opera 3 owner reference, and activity_date set to the original timestamp. Activity records without a clear type default to a generic note activity type in Odoo.

Opera 3 stock codes, descriptions, bin locations, reorder levels, and BOM structures export cleanly via CSV. We map stock codes to Odoo Product records, preserving the stock code as the product's default_code. Bin location maps to the Odoo warehouse location field. BOM structures from Opera 3 map to Odoo bom_type=bom_kit on the related product.

The OPUS add-on for Opera 3 stores customer-specific stock codes and descriptions as a separate CSV with a different schema from the standard stock file. We join OPUS records to the main product export using the base stock code and the customer account reference, then create Odoo Product Variants (attribute: Customer) with customer-specific prices on the corresponding customer pricelist. This is one of the most complex object transformations in the migration because the source schema is denormalised.

Opera 3 Nominal Ledger accounts with cost-centre tagging export as a chart of accounts CSV. We map each account code directly to an Odoo Accounting Account record, preserving the account code hierarchy and cost-centre assignments as analytic account tags. The account type (asset, liability, expense, revenue) is derived from the Opera 3 account group code.

Opera 3 stores multiple legal entities within one database with inter-company transactions flagged by a counterparty company code. We extract each company code as a separate entity and present the customer with two destination options: a separate Odoo database per legal entity (standard Odoo deployment, separate subscription per database), or a single Odoo database with multi-company enabled (shared contacts, restricted data access per company). This decision affects licensing cost and is made during scoping.

Opera 3 employee records export via CSV including bank details, start/end dates, and P45 data. RTI FPS XML files contain tax submission records; EPS files hold employer payment summaries. We map employees to Odoo Employees with the P45 data stored as an attachment on the employee record. RTI FPS records are joined to the employee CSV by National Insurance number to resolve any orphaned RTI entries. Note that Odoo Payroll is a separate paid app and must be configured separately for RTI filing.

Opera 3 fixed asset registers with acquisition dates, cost, depreciation method, NBV, and disposal history export as structured records. We map to Odoo Asset records with the acquisition date, original value, depreciation method, and accumulated depreciation carried across. Disposal history is preserved as asset line entries.

Opera 3 project cost codes and phase-level tracking export with labour, purchase, and expense allocations linked to the Nominal Ledger. We map project headers to Odoo Project and cost code phases to Project Tasks with tracked hours and expenses. The nominal code mapping for labour and purchase lines is preserved in the task description or as analytic account tags.

Opera 3 stores PDF invoices, statements, and remittance advices as binary files in document folders. We extract the file using the account reference and transaction date from the filename, then attach each PDF to the corresponding Odoo account move, contact, or purchase order record. File naming conventions vary by Opera 3 installation and are resolved during the export scoping phase.

Opera 3 exports currency codes, exchange rates, and transaction amounts in foreign currencies. We preserve the rate used at transaction time in a custom field on the Odoo move line and configure Odoo's multi-currency setting to accept the historical rate. If the destination Odoo instance does not have multi-currency enabled, we flag this during scoping as a configuration prerequisite.