ERP migration
Field-level mapping, validation, and rollback between Unit4 ERP and Odoo ERP. We move data and schema; workflows are rebuilt natively in Odoo ERP.
Unit4 ERP
Source
Odoo ERP
Destination
Compatibility
11 of 12
objects map 1:1 between Unit4 ERP and Odoo ERP.
Complexity
BStandard
Timeline
4–8 weeks
Overview
Moving from Unit4 ERP to Odoo ERP is a schema redesign, not a straight record copy. Unit4 stores cost centres, departments, and projects as natural dimensions on its general ledger; Odoo represents these as separate analytic account tags that attach to journal items rather than existing as account-structure nodes. We resolve that dimensional flattening during scoping, discuss whether to preserve Unit4's multi-fund ledger hierarchy or collapse it to a flat chart in Odoo, and sequence migration loads in dependency order—Customers and Suppliers first, then the Chart of Accounts, then AP/AR open items, then Projects and Employees, then historical journal entries last. Unit4's Object API is read-only by default, so we extract via GCON4 MFL or direct SQL, build Odoo-compatible CSV packages, and load through Odoo's native data import framework. We do not migrate workflows, automated processes, or Unit4's Process Automation; we deliver a written inventory of every active rule requiring rebuild in Odoo Studio or a custom Python module.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Unit4 ERP object lands in Odoo ERP, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Unit4 ERP
Customer
Odoo ERP
Contact / Company
1:1Unit4 Customer records map to Odoo Contact with the Company flag set to True, which creates the corresponding Company record automatically. We map billing address to Odoo's partner address fields, payment terms to Odoo's property_payment_term_id, and credit limit to credit_limit on the partner. Tax registration numbers map to Odoo's vat field for VAT reporting. Any custom Unit4 Customer fields require an Odoo custom field or a Python pre-import hook to resolve.
Unit4 ERP
Supplier
Odoo ERP
Contact / Company
1:1Unit4 Supplier records map to Odoo Contact with supplier_rank set to 1 (and customer_rank to 0), creating a Supplier-type Company in Odoo. W-9/W-8 status and bank details map to Odoo's res.partner.bank records attached to the partner. Multi-address support migrates as additional partner address records with sequence ordering preserved. Purchase-specific fields like supplier taxes and lead times map to Odoo's property_supplierinfo records.
Unit4 ERP
Chart of Accounts
Odoo ERP
Account
lossyUnit4's multidimensional account structure with cost centres, departments, and projects as natural axes requires flattening before Odoo import. We extract account codes and descriptions, then create Odoo account.account records. The customer's cost-centre hierarchy becomes a set of Odoo account.analytic.account records (analytic dimensions) that the customer configures as one, two, or three analytic tags per the Odoo analytic plan. We discuss whether to preserve the Unit4 natural-account hierarchy in full or collapse it to a simplified Odoo chart during scoping.
Unit4 ERP
GL Account
Odoo ERP
Account
1:1General Ledger account codes, account types (asset, liability, equity, income, expense), and posting controls migrate directly to Odoo account.account. Currency settings and consolidation flags require mapping to Odoo's account.account properties. Any Unit4 account that is a posting-control account for automatic tax or rounding requires a manual review to ensure the equivalent configuration exists in Odoo's tax settings.
Unit4 ERP
Item (Product)
Odoo ERP
Product
1:1Unit4 Item records map to Odoo product.product with type set to product (stockable), consumable, or service based on Unit4's stock-control flags. GL mapping for COGS and inventory accounts becomes Odoo's property_account_income_id and property_account_expense_id on the product. Pricing matrices in Unit4 require either a product.pricelist item or a product.template attribute line in Odoo, depending on complexity. We discuss whether to migrate full pricing history or just the current active price list during scoping.
Unit4 ERP
Open AP/AR
Odoo ERP
Account Move (Invoice/Bill)
1:1Outstanding Unit4 AP and AR documents migrate as Odoo account.move records with move_type set to out_invoice (AR) or in_invoice (AP). Document headers (invoice number, date, due date, currency, amount) map directly; line items require product or account resolution against the migrated product and account data. Open amounts and payment states preserve so that Odoo's reconciliation process can match payments post-go-live. We do not re-print or re-email these documents; they are imported in a state that allows Odoo to reconcile them against new payments.
Unit4 ERP
Historical Transactions
Odoo ERP
Account Move (Journal Entry)
1:1Unit4 journal history migrates as Odoo account.move records with move_type set to entry. We scope the date range during discovery (full history vs a configurable window) because bulk import of hundreds of thousands of historical lines requires Odoo's direct PostgreSQL insertion or a chunked CSV approach to avoid timeouts. Locked journal entries from Unit4 become posted moves in Odoo. We preserve posting dates, source references, and user stamps as Odoo move line name fields and move metadata. Account and analytic line structure must be resolved against the migrated chart of accounts and analytic plan.
Unit4 ERP
Journal Entry
Odoo ERP
Account Move (Entry)
1:1Posted Unit4 journal entries migrate as Odoo account.move with move_type entry. The Unit4 journal code maps to Odoo's journal_id; account code maps to account_id; amount, debit, and credit map to balance. Multi-line entries with tax lines require tax code resolution against the migrated tax matrix. We flag any Unit4 journal entries that reference accounts or tax codes not yet migrated; those records are held in a reconciliation queue until the prerequisite data is loaded.
Unit4 ERP
Tax Code
Odoo ERP
Account Tax
1:1Unit4 country-specific tax matrices with rates, jurisdictions, and posting rules map to Odoo account.tax records. Unit4's tax type (VAT, sales tax, withholding) maps to Odoo's tax_scope; the tax rate maps to amount. Complex compound taxes and reverse-charge mechanisms require manual Odoo configuration review. Jurisdiction combinations that do not have an Odoo standard tax template are flagged for the customer's admin to configure post-migration. Country-specific Odoo tax templates (l10n modules) are pre-installed in the destination Odoo instance before migration begins.
Unit4 ERP
Fixed Asset
Odoo ERP
Asset
1:1Unit4 asset master records with depreciation schedules, cost centres, and insurance values map to Odoo account.asset records. Depreciation method (straight-line, declining balance, sum-of-years) requires alignment with Odoo's asset profile settings. Depreciation board entries (already-posted depreciation lines) migrate as Odoo posted account.move records linked to the asset. We align on a per-asset-category conversion approach during scoping because Unit4 and Odoo may use different depreciation conventions. Insurance value and cost-centre assignments become custom fields on the Odoo asset record.
Unit4 ERP
Bank/Cash Account
Odoo ERP
Account Journal (Bank/Cash)
1:1Unit4 bank account masters with currency, account type, and reconciliation settings migrate as Odoo account.journal records of type bank or cash. Opening balances reconcile as a first Odoo bank statement or a manual opening entry. Bank reconciliation settings map to Odoo's journal's allow_date_setting and to account.journal's receivable/payable account references.
Unit4 ERP
Employee
Odoo ERP
Employee
1:1Unit4 HCM employee records with employment history, compensation, job titles, and department assignments migrate to Odoo hr.employee. Effective-dated employment changes (multiple assignments or role changes) require careful sequencing: we import the most recent active assignment as the primary Odoo record and hold prior assignments as a historical note in a custom field or an Odoo hr.contract record. Department and cost-centre assignments resolve against the migrated analytic account plan. We flag any Unit4 payroll-specific fields that do not have an Odoo equivalent; these require review by the customer's HR admin post-migration.
| Unit4 ERP | Odoo ERP | Compatibility | |
|---|---|---|---|
| Customer | Contact / Company1:1 | Fully supported | |
| Supplier | Contact / Company1:1 | Fully supported | |
| Chart of Accounts | Accountlossy | Mapping required | |
| GL Account | Account1:1 | Fully supported | |
| Item (Product) | Product1:1 | Fully supported | |
| Open AP/AR | Account Move (Invoice/Bill)1:1 | Fully supported | |
| Historical Transactions | Account Move (Journal Entry)1:1 | Mapping required | |
| Journal Entry | Account Move (Entry)1:1 | Fully supported | |
| Tax Code | Account Tax1:1 | Fully supported | |
| Fixed Asset | Asset1:1 | Fully supported | |
| Bank/Cash Account | Account Journal (Bank/Cash)1:1 | Fully supported | |
| Employee | Employee1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Unit4 ERP gotchas
Forced Agresso-to-Cloud migration creates migration pressure
Object API is read-only by default
ERPx is cloud-only—on-premise deployments unavailable
Odoo ERP gotchas
No rollback for CSV imports
External ID conflicts on re-import
Many2many field encoding in CSV imports
Large export timeouts require batching
Version schema drift between Odoo releases
Pair-specific challenges
Migration approach
Discovery and extraction method confirmation
We audit the Unit4 environment across product line (ERP Continuous Release or ERPx), extraction method availability (GCON4 MFL, BIF, SQL), master data volumes, project count, historical transaction date range, and any active grant or fund structures. We confirm with the customer's IT team which API and file formats are accessible and whether a hybrid cloud transition is in progress. The discovery output is a written migration scope, an extraction method recommendation, and a target Odoo analytic plan design. If the customer is mid-transition from Agresso to ERPx, we agree on which system's data is the authoritative source for each domain.
Odoo schema preparation and analytic plan design
We install and configure the Odoo database before any data moves. This includes installing the required Odoo Apps (Accounting, Project, HR, Inventory if applicable), designing the analytic account plan (number of dimensions and naming aligned with Unit4's cost-centre and department hierarchy), importing the country-specific l10n tax template (for correct tax jurisdiction setup), creating account.journal records, and defining the account.account chart of accounts aligned with the Unit4 chart. We deploy into an Odoo test database first for validation. We also create any custom fields required for grant codes, fund tags, or Unit4-specific data that does not map to a standard Odoo field.
Master data extraction, transformation, and test import
We extract Customers, Suppliers, Chart of Accounts, GL Accounts, Tax Codes, Products/Items, Fixed Assets, Bank/Cash Accounts, and Employees from Unit4 in CSV or SQL format. Each dataset undergoes transformation: account codes are validated against the Odoo chart, tax codes are matched to the installed l10n template, product types are resolved to Odoo product.type values, and cost-centre dimensions are mapped to the analytic account plan. We run a test import into the Odoo test database and reconcile record counts, spot-checking 25–50 records against the Unit4 source. The customer's finance and operations leads sign off on the test import before production migration begins.
Open AP/AR and historical journal extraction
Outstanding AP and AR documents extract as separate files from master data. We resolve supplier and customer references against the migrated contact records, resolve account codes against the migrated chart, and resolve product or account references on line items. Historical journal entries (posted ledger lines) extract in date-range chunks aligned to the agreed scope window. Each chunk is validated for account balance integrity (debits equal credits) before import. Locked journal entries from Unit4 import as posted account.move records in Odoo. We flag any entries that reference accounts or tax codes not yet migrated and hold them in a queue until prerequisites are resolved.
Production migration in dependency order
We run production migration in record-dependency sequence: Company/Contact records first (master data for all other objects), then Chart of Accounts and GL Accounts, then Tax Codes, then Products/Items, then Bank/Cash Accounts, then Fixed Assets, then Employees, then Projects with cost tracking and grant mappings, then Open AP/AR documents, then historical journal entries last. Each phase emits a row-count reconciliation report before the next phase begins. Any failures or mismatches are isolated to a log file and resolved before continuing. We freeze Unit4 writes during the final delta migration window to capture any records modified during the migration run.
Cutover, validation, and workflow rebuild handoff
We freeze Unit4, run a final delta migration of records modified during the migration window, then enable Odoo as the system of record. We run a post-migration reconciliation: account balances match the Unit4 trial balance, open AP/AR counts match, project cost totals match, and employee headcount matches. We deliver a written inventory of every active Unit4 workflow, automated process, and Process Automation rule with a recommended Odoo equivalent (Odoo Studio automation, ir.actions.server, or a custom Python module). We do not rebuild Unit4 workflows as Odoo automations inside the migration scope; that work is handled by the customer's admin or a separate Odoo partner engagement. We support a one-week hypercare window for reconciliation issues raised by the customer's team.
Platform deep dives
Unit4 ERP
Source
Strengths
Weaknesses
Odoo ERP
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Unit4 ERP and Odoo ERP.
Object compatibility
2 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Unit4 ERP: Not publicly documented.
Data volume sensitivity
Unit4 ERP doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Unit4 ERP to Odoo ERP migration scoping. Not seeing yours? Book a call.
Walk through your Unit4 ERP to Odoo ERP migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Unit4 ERP
Other ways to arrive at Odoo ERP
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.