Migrate from Exxas Cloud Business Platform to Odoo ERP

Discovery and Odoo module scoping

We audit the customer's Exxas account via API 2.0 credentials, enumerating all available objects across the eight modules, custom field definitions, and picklist values. We pair this with an Odoo module scoping session to confirm which Odoo apps are active or need activation: CRM, Helpdesk, Project, Inventory, Manufacturing, HR, Payroll, and Accounting are the primary candidates. The discovery output is a written migration scope document listing every object, field mapping, and the customer-confirmed Odoo app list.

German field translation and Exxas data audit

We build a field translation matrix mapping every German Exxas field label, picklist value, and option to its English Odoo equivalent or to a custom Odoo field we pre-create. We run a data quality audit on the Exxas export, identifying duplicate records, missing required fields, orphaned child records without parent references, and multi-currency amounts that require Odoo multi-currency configuration. Data cleansing recommendations are delivered to the customer before migration.

Schema design and Odoo configuration

We design the destination Odoo schema: creating custom fields via Settings > Technical, configuring the chart of accounts to match the Exxas finance structure, setting up warehouse locations, defining Odoo CRM pipeline stages mapped to Exxas deal stages, and configuring the HR module for employee record migration. For multi-company Odoo setups, we configure company_id scoping before any record import. Schema is validated in the customer's Odoo environment before production migration begins.

Sandbox migration and reconciliation

We run a full migration into an Odoo test database using production-like data volume. The customer's team spot-checks 25-50 records per module against the Exxas source for field-level accuracy, relationship integrity (contacts linked to correct companies, tasks linked to correct projects), and financial amounts. Any mapping corrections are documented and applied to the production migration script. Reconciliation sign-off from the customer's admin is required before the production migration window opens.

Owner reconciliation and user provisioning

We extract every distinct Exxas owner referenced on Deals, Service Tickets, Projects, and HR records and map them by email to Odoo user accounts. Owners without a matching Odoo user are held in a reconciliation queue. The customer's Odoo admin provisions any missing users before production migration proceeds. Inactive Odoo users can receive migrated records if the customer wants to preserve assignment history, with a flag noting the assignment is historical.

Production migration in dependency order

We run production migration in record-dependency order: account.account (chart of accounts), res.partner (companies with is_company), res.partner (contacts with parent_id resolved), product.template (with stock and pricing), crm.lead (deals with stage and user resolved), helpdesk.ticket or project.task (service tickets), project.project and project.task (project hierarchy), hr.employee and hr.contract (HR with effective dates), account.move (open AP/AR as draft), and ir.model.data (custom field values on their parent records). Each phase emits a row-count reconciliation report before the next phase begins.

Cutover, delta sync, and automation handoff

We freeze Exxas writes during cutover, run a final delta migration capturing any records modified during the migration window, then set the customer live in Odoo. We deliver a written inventory of every Exxas workflow, automation, and custom report with its trigger, conditions, and recommended Odoo counterpart (Studio automation, server action, or scheduled action). The customer's admin or an Odoo partner rebuilds these post-migration. We support a five-business-day hypercare window for reconciliation issues and do not include post-migration admin support, training, or workflow rebuild as standard scope.