ERP migration
Field-level mapping, validation, and rollback between FACT ERP.NG and Odoo ERP. We move data and schema; workflows are rebuilt natively in Odoo ERP.
FACT ERP.NG
Source
Odoo ERP
Destination
Compatibility
10 of 12
objects map 1:1 between FACT ERP.NG and Odoo ERP.
Complexity
BStandard
Timeline
5-8 weeks
Overview
Moving from FACT ERP.NG to Odoo ERP requires handling a platform whose tightly integrated modules share a single transactional state and whose configuration-only model stores business rules as platform parameters rather than user-defined fields. FACT ERP.NG posts payroll transactions directly to the General Ledger as journal entries, creating a mandatory load-order dependency we must resolve before any data reaches Odoo. We extract configuration parameters as first-class migration objects, replay them into Odoo's system parameters, and map every inter-module reference so that COA, inventory, payroll, and financials land with their original relationships intact. Workflows, automations, CXO Control Tower dashboards, and e-invoice compliance configurations do not migrate as code; we deliver a written inventory for the customer's admin to rebuild in Odoo Studio or the equivalent compliance 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 FACT ERP.NG 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.
FACT ERP.NG
Customers
Odoo ERP
ResPartner (Contacts)
1:1FACT ERP.NG Customer records carry addresses, contact details, GST/Tax IDs, credit limits, and payment terms. We map them 1:1 to Odoo res.partner records with address fields preserved and the customer flag set. We resolve Customer-to-Sales-Order references during load so that the parent relationship is satisfied at the moment of insert. Tax registration numbers map to Odoo's vat field.
FACT ERP.NG
Suppliers
Odoo ERP
ResPartner (Contacts)
1:1Supplier master records include bank details, tax registration, and payment terms. We map them to Odoo res.partner with the supplier flag set. Supplier-to-Purchase-Order and Supplier-to-AP-invoice references are resolved during load. Bank details migrate to res.partner.bank records attached to the vendor partner.
FACT ERP.NG
Items / Products
Odoo ERP
Product Template + Product Variant
1:1FACT ERP.NG Items carry pricing, BOM links, serial number flags, and barcode data. We map items to Odoo product.template with product.product variants where attribute-based variants exist. Pricing migrates to Odoo's list_price, standard_price, and pricelist items. Barcode maps to barcode field. Serial and lot tracking flags transfer to the tracking field on product.template.
FACT ERP.NG
Bill of Materials (multi-level)
Odoo ERP
mrp.bom
1:1FACT ERP.NG multi-level BOM structures migrate to Odoo mrp.bom records with nested bom.line children representing sub-assemblies. We chunk BOM rows individually and resolve component product references before each bom insert. Routing and work centre data from FACT's manufacturing module map to Odoo mrp.routing and mrp.workcenter.
FACT ERP.NG
Sales Orders
Odoo ERP
sale.order
1:1FACT ERP.NG Sales Orders carry customer references, line items, pricing, taxes, and fulfillment status. We map each order header and its lines as a single transactional unit so that partial fulfillments are preserved. Order state maps to Odoo sale.order state (draft, sale, done, cancel). Tax lines migrate to order_tax records with the relevant account.tax reference resolved.
FACT ERP.NG
Purchase Orders
Odoo ERP
purchase.order
1:1Purchase Orders carry supplier references, line items, expected delivery dates, and GRN (Goods Received Note) linkages. We preserve header-to-line structure and flag any open versus closed PO status. GRN linkages are noted as Odoo move_ids on the purchase.order.line after the incoming shipment is received.
FACT ERP.NG
GL Accounts / Chart of Accounts
Odoo ERP
account.account
1:1FACT ERP.NG uses a standard COA with account codes, descriptions, and account types. We map account codes directly to Odoo account.account records with the relevant user_type_id set per Odoo's account.account.type selection. Accounts that carry a balance are flagged so that opening balances are posted correctly via Odoo's opening balance journal. We also map FACT's account type classification to Odoo's account type (receivable, payable, liquidity, etc.).
FACT ERP.NG
Journal Entries / Transactions
Odoo ERP
account.move
1:manyFACT ERP.NG posts payroll, AR, and AP directly to the GL via journal entries. These are date-stamped, source-referenced records. We extract them in date-range batches and map them to Odoo account.move (header) and account.move.line (lines). Journal references are resolved to Odoo account.journal records. We preserve the debit/credit pairs and the original posting dates to maintain audit trails.
FACT ERP.NG
Payroll (employee records)
Odoo ERP
hr.employee + hr.contract
1:1Employee records include salary components, tax deductions, EPF/CPF contributions, and leave balances. We map employees to Odoo hr.employee and hr.contract. Salary rules from FACT map to Odoo hr.contract structure_type_id and associated salary rule categories. Leave balances migrate to hr.leave records. Payroll must load before GL journal entries in a separate migration phase.
FACT ERP.NG
Inventory / Warehouse
Odoo ERP
stock.quant + stock.location
1:1FACT ERP.NG inventory balances are maintained per warehouse per item. We migrate current stock positions to Odoo stock.quant records, reorder levels to product.putaway rules, and warehouse assignments to Odoo stock.location hierarchy. Serial and batch tracking fields require value-level mapping where lot/serial numbers are stored on the stock.quant or linked stock.move records.
FACT ERP.NG
Fixed Assets
Odoo ERP
account.asset.asset
1:1Fixed Asset records include acquisition cost, depreciation method, accumulated depreciation, and asset location. Depreciation schedules are generated per accounting period. We map asset registers to Odoo account.asset.asset with the depreciation method, account.depreciation.confirmation fields, and analytic account resolved from the COA mapping.
FACT ERP.NG
Configuration Parameters
Odoo ERP
ir.config_parameter + res.config.settings
lossyFACT ERP.NG's Configuration Only model stores business rules, workflow states, inventory matrix settings, and tax configurations as platform parameters. We extract every non-default parameter value during discovery and replay them into Odoo ir.config_parameter records or res.config.settings fields. Tax rates, approval thresholds, pricing tier flags, and workflow state defaults are mapped to their Odoo equivalents. A configuration-replay script is delivered as part of the migration package.
| FACT ERP.NG | Odoo ERP | Compatibility | |
|---|---|---|---|
| Customers | ResPartner (Contacts)1:1 | Fully supported | |
| Suppliers | ResPartner (Contacts)1:1 | Fully supported | |
| Items / Products | Product Template + Product Variant1:1 | Fully supported | |
| Bill of Materials (multi-level) | mrp.bom1:1 | Fully supported | |
| Sales Orders | sale.order1:1 | Fully supported | |
| Purchase Orders | purchase.order1:1 | Fully supported | |
| GL Accounts / Chart of Accounts | account.account1:1 | Fully supported | |
| Journal Entries / Transactions | account.move1:many | Mapping required | |
| Payroll (employee records) | hr.employee + hr.contract1:1 | Fully supported | |
| Inventory / Warehouse | stock.quant + stock.location1:1 | Mapping required | |
| Fixed Assets | account.asset.asset1:1 | Mapping required | |
| Configuration Parameters | ir.config_parameter + res.config.settingslossy | 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.
FACT ERP.NG gotchas
Configuration parameters must be mapped as first-class migration objects
Payroll journal entries create a mandatory sequencing dependency with the GL
Slow report rendering can extend migration validation cycles
No publicly documented API for direct programmatic extraction
Dashboard configurations are not exportable data objects
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 FACT ERP.NG across all active modules, configuration parameters, active inter-module dependencies (payroll-to-GL chains, BOM hierarchies, multi-entity structures), and data volumes per table. We confirm whether direct database read access is available or whether extraction relies on FACT export utilities. We inventory every non-default parameter setting and map each to an Odoo equivalent (ir.config_parameter, res.config.settings, or a custom field). The discovery output is a written migration scope, an extraction method confirmation, and a configuration parameter catalogue.
Configuration parameter replay design
We design the configuration replay plan in Odoo. This includes setting up Odoo ir.config_parameter records for global parameters, configuring account.tax records to match FACT's tax tiers and rates, replaying inventory reorder levels as stock.putaway rules or min-quantity rules on product.template, and documenting which FACT workflow states map to Odoo approval workflows or pipeline stage defaults. Every configuration record is written to a staging YAML or SQL script validated in a staging Odoo database before production deployment.
Sandbox migration and payroll-GL sequencing validation
We run a full migration into a staging Odoo environment using production-like data volume. The customer's finance lead reconciles GL totals (account balances, trial balance), inventory quantities (per warehouse per item), and payroll totals (employee headcount, salary journals). The payroll-to-GL sequencing dependency is validated in sandbox: we confirm that journal entries posted after payroll load match the original FACT GL postings exactly. Any mapping corrections happen here before production cutover begins.
Master data migration (accounts, partners, products)
We migrate master data in dependency order: account.chart.template (COA from FACT) deployed first, then res.partner records (customers and suppliers with banking details), then product.template and product.product with variants, then stock.location warehouse hierarchy. Each phase emits a row-count reconciliation report and a sample-record validation (25 random records checked against FACT source) before the next phase begins. BOM structures are migrated after product templates using the mrp.bom model with nested component resolution.
Transactional data migration in sequenced passes
We run transactional migration in strict order: (1) hr.employee and hr.contract records, (2) account.move records for GL journal entries derived from payroll (reconciled against FACT payroll output), (3) stock.quant for current inventory positions, (4) sale.order and purchase.order with line items and tax lines, (5) account.asset.asset for fixed asset register, (6) account.move records for AR and AP postings. Each pass is reconciled for record count and monetary total before the next begins. Open orders from FACT that are partially fulfilled carry their picking and move state as Odoo stock.picking records attached to the sale.order.
Cutover, final delta, and dashboard rebuild handoff
We freeze FACT ERP.NG writes during cutover, run a final delta migration of any records modified during the migration window, then enable Odoo as the system of record. We deliver the configuration parameter replay script, the workflow and automation inventory document (for the customer's admin to rebuild in Odoo Studio), and the dashboard rebuild guide referencing the Odoo reporting module and any installed Odoo BI add-on. We support a one-week hypercare window for reconciliation issues. Post-cutover admin rebuild of Odoo workflows and automations is outside standard scope.
Platform deep dives
FACT ERP.NG
Source
Strengths
Weaknesses
Odoo ERP
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. 1 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 FACT ERP.NG and Odoo ERP.
Object compatibility
1 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
FACT ERP.NG: Not publicly documented.
Data volume sensitivity
FACT ERP.NG 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 FACT ERP.NG to Odoo ERP migration scoping. Not seeing yours? Book a call.
Walk through your FACT ERP.NG 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 FACT ERP.NG
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.