ERP migration
Field-level mapping, validation, and rollback between ERPAG and Odoo ERP. We move data and schema; workflows are rebuilt natively in Odoo ERP.
ERPAG
Source
Odoo ERP
Destination
Compatibility
11 of 12
objects map 1:1 between ERPAG and Odoo ERP.
Complexity
BStandard
Timeline
4-6 weeks
Overview
Moving from ERPAG to Odoo ERP is a structural migration for manufacturing and distribution businesses that have outgrown ERPAG's feature-gated Advanced plan or its limited third-party integration ecosystem. Odoo offers a modular architecture spanning CRM, manufacturing, inventory, accounting, HR, and eCommerce under a single platform, with Community edition available as open-source and Enterprise covering higher-scale deployments. We map ERPAG's Items to Odoo Product variants, Sales Orders to Odoo Sale Orders, Work Orders to mrp.production, and BOMs to mrp.bom with multi-level nesting preserved. ERPAG's Advanced-plan-only Customization and Automation features, B2B portal configuration, and Blockly scripts do not migrate as code; we deliver a written inventory of these objects for the customer's Odoo administrator to rebuild post-migration. We flag the 2 req/sec API rate limit during scoping and schedule bulk export phases during off-peak hours to avoid blocking live operations.
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 ERPAG 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.
ERPAG
Items (Products)
Odoo ERP
Product.product
1:1ERPAG Items map to Odoo Product records. We preserve SKU, product description, standard cost, sale price, and stock levels. ERPAG's per-warehouse stock levels require multi-warehouse activation in Odoo and map to stock.quant records tied to the correct stock.location. ERPAG's barcode field maps to product.barcode. Stock-keeping unit type (stockable, consumable, service) carries over as product.type. Multi-warehouse item assignments require location-based lookups during import rather than a direct field-to-field transfer.
ERPAG
Customers
Odoo ERP
res.partner
1:1ERPAG Customer records map to Odoo res.partner with the customer flag set to True. We transfer contact name, billing address, shipping address, payment terms, and financial overview fields. ERPAG's B2B portal assignment (Advanced plan only) does not migrate because the portal configuration is ERPAG-specific; we document the customer portal access list as a reference for the customer's Odoo administrator to configure in Odoo Portal post-migration. ERPAG's financial overview balance fields map to receivable account fields in Odoo Partner accounting properties.
ERPAG
Suppliers
Odoo ERP
res.partner
1:1ERPAG Supplier records map to Odoo res.partner with the supplier flag set to True. We preserve contact data, purchasing terms, and the double-SKU cross-reference fields that map ERPAG's internal SKU to the supplier's own SKU. This supplier-SKU mapping is critical for Purchase Order automation in Odoo and is stored in Odoo's seller_ids on the Product record. ERPAG's payment terms on Supplier records map to Odoo's property_supplier_payment_term on res.partner.
ERPAG
Sales Orders
Odoo ERP
sale.order
1:1ERPAG Sales Orders map to Odoo sale.order with line items, pricing, order status, and payment status preserved. ERPAG's payment_status column from the XLS export maps to Odoo's order state (sale_order_state or invoice_status depending on the Odoo configuration). ERPAG linked documents and custom fields on Sales Orders require file export from ERPAG and re-upload to Odoo as ir.attachment records linked to the sale.order. Packing list associations migrate as delivery order references.
ERPAG
Invoices
Odoo ERP
account.move
1:1ERPAG Invoices map to Odoo account.move records of type out_invoice. ERPAG's invoice status (issued, paid, credit note) maps to Odoo's state and invoice_payment_state fields. ERPAG credit notes map to Odoo account.move of type out_refund. Tax amounts and currency codes from ERPAG carry over to Odoo's tax line structure and currency settings. Historical paid invoices retain their payment records in Odoo accounting. ERPAG e-invoice formats (Norway EHF is supported in ERPAG) require separate configuration in Odoo through a localization module.
ERPAG
Purchase Orders
Odoo ERP
purchase.order
1:1ERPAG Purchase Orders map to Odoo purchase.order with supplier reference, line items, and fulfillment status. Goods received state from ERPAG maps to Odoo's delivered quantity on purchase.order.line. ERPAG's double-SKU supplier entry maps to the seller_ids on the Odoo Product record during import. Purchase Order attachments migrate as ir.attachment records. If ERPAG's Advanced Automation triggers purchase orders automatically, that logic is documented separately for Odoo purchase procurement rules rebuild.
ERPAG
Quotations
Odoo ERP
sale.order (quotation state)
1:1ERPAG Quotations map to Odoo sale.order records in the draft (quotation) state. Validity dates, line item pricing, and custom fields carry over. ERPAG quotation-to-Sales-Order conversion references are noted in the migration inventory as Odoo sales team may want to create follow-up opportunities from these records. Odoo merges quotation and order into a single model; ERPAG separates them, so quotation history is preserved as Odoo sale.order records with state=draft.
ERPAG
Work Orders
Odoo ERP
mrp.production
1:1ERPAG Work Orders map to Odoo mrp.production (manufacturing orders). BOM references, production status, and cost data transfer including ERPAG's estimated versus actual cost fields. Production scheduling dates from ERPAG map to Odoo mrp.production date_planned_start and date_finished. ERPAG work order dependencies and routing sequences require mapping to Odoo mrp.workorder if the customer's ERPAG setup uses multi-step routing. Status values (pending, in progress, completed, cancelled) map to Odoo's confirmed, progress, done, cancel states.
ERPAG
Warehouses
Odoo ERP
stock.warehouse
lossyERPAG warehouses map to Odoo stock.warehouse records with independent tax, currency, and price list configurations. Multi-warehouse activation in Odoo must be enabled before import. ERPAG's per-warehouse price lists map to Odoo's product.pricelist records associated with each warehouse's location hierarchy. Geo-location data from ERPAG warehouses maps to Odoo stock.location records within the warehouse. Each warehouse must be configured in Odoo with corresponding incoming and outgoing picking types before stock quant import begins.
ERPAG
Bill of Materials (BOM)
Odoo ERP
mrp.bom
1:1ERPAG BOMs map to Odoo mrp.bom records. Multi-level BOM nesting (BOM referencing sub-assemblies that are themselves BOMs) preserves structure in Odoo's product.product and mrp.bom hierarchy. BOM type (kit versus manufacturing) maps from ERPAG's BOM type selection. ERPAG BOM cost data transfers to Odoo's Product standard cost field, with estimated versus actual cost preserved as metadata on the mrp.production record. ERPAG BOMs associated with Items export from the Items endpoint and require cross-reference resolution to establish the Odoo product-product BOM linkage.
ERPAG
Users and User Roles
Odoo ERP
res.users
1:1ERPAG user records and role-based permission assignments map to Odoo res.users with internal user type. We export all active and inactive users from ERPAG and map their role assignments to Odoo access rights groups (Inventory User, Manufacturing User, Sales User, etc.). ERPAG document restriction rules map partially to Odoo's record rules (ir.rule) but permission sets are destination-specific and require rebuild by the customer's Odoo administrator. Active versus inactive status carries over to user.active in Odoo.
ERPAG
Custom Fields
Odoo ERP
ir.model.fields (custom)
1:1ERPAG custom field definitions on Items, Sales Orders, Customers, Suppliers, and Work Orders are enumerated during scoping. ERPAG custom fields use Administration > Custom Fields for document-linked and arbitrary value types, with up to 15 custom fields per document. We map these to Odoo Properties (ir.property) for cross-model fields or create custom field columns (ir.model.fields) via Odoo Studio or direct SQL migration for object-specific fields. Document-linked ERPAG custom fields export as file attachments and re-attach in Odoo to the corresponding record.
| ERPAG | Odoo ERP | Compatibility | |
|---|---|---|---|
| Items (Products) | Product.product1:1 | Fully supported | |
| Customers | res.partner1:1 | Fully supported | |
| Suppliers | res.partner1:1 | Fully supported | |
| Sales Orders | sale.order1:1 | Fully supported | |
| Invoices | account.move1:1 | Fully supported | |
| Purchase Orders | purchase.order1:1 | Fully supported | |
| Quotations | sale.order (quotation state)1:1 | Fully supported | |
| Work Orders | mrp.production1:1 | Fully supported | |
| Warehouses | stock.warehouselossy | Mapping required | |
| Bill of Materials (BOM) | mrp.bom1:1 | Fully supported | |
| Users and User Roles | res.users1:1 | Mapping required | |
| Custom Fields | ir.model.fields (custom)1:1 | Mapping required |
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.
ERPAG gotchas
API rate limit of 2 requests per second throttles bulk migration speed
Localization settings do not retroactively rewrite existing documents
Plan tier gates Customization, Portal, and Automation features
No native negative inventory support; phantom negatives require repair step
Delete-all-transactions preserves inventory and contacts, requiring separate scoping
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 scoping
We audit the ERPAG account across plan tier (Basic/Professional/Advanced), data volume by object (Items, Customers, Suppliers, Sales Orders, Invoices, Purchase Orders, Work Orders, BOMs), custom field count and type, multi-warehouse configuration, and BOM nesting depth. We also identify any Advanced-plan features in use (Automation, B2B portal, custom document types) and flag them as non-migratable. The discovery output is a written migration scope with record counts per object, a data quality assessment, and a recommended Odoo edition (Community for open-source, Enterprise for HR, Studio, and support SLAs).
Odoo staging schema design
We design the destination Odoo configuration: install required apps (Sales, Purchase, Inventory, Manufacturing, Accounting), activate multi-warehouse if applicable, configure UoM categories and units matching ERPAG product types, set up taxes and fiscal positions from ERPAG tax codes, configure pricelists, and design the BOM hierarchy. We create custom fields on Odoo objects matching ERPAG custom field definitions and deploy everything to an Odoo sandbox or test database for validation before production migration begins.
Sandbox migration and reconciliation
We run a full migration into the Odoo test environment using production-like data volumes. The customer reconciles record counts (Items in, Customers in, Suppliers in, Sales Orders in, Invoices in, Work Orders in, BOMs in), spot-checks 25-50 records against the ERPAG source for field-level accuracy, and reviews the BOM structure and multi-warehouse stock assignments. Any field mapping corrections, BOM nesting adjustments, or pricing rule modifications happen in the staging environment before production migration begins.
Data preparation and cleanup
We apply ERPAG database repairs for any phantom negative quantities detected during export, remove exact duplicate Items and Suppliers, resolve the double-SKU cross-reference to populate Odoo seller_ids correctly, and map ERPAG currency codes to Odoo res.currency records. If the customer changed localization settings after creating historical documents, we document the affected record ranges and flag the reporting impact rather than attempting retroactive rewrite.
Production migration in dependency order
We run production migration in the correct dependency sequence: currencies and UoMs first, then Warehouses and Locations, then Products and Products with BOMs (second pass after BOMs exist), then Partners (Customers and Suppliers), then Sales Orders, Purchase Orders, Invoices, Work Orders, and finally Activity history including Notes and attachments. Each phase emits a row-count reconciliation report before the next phase begins. The ERPAG Smart API rate limit of 2 req/sec is managed through request pacing and off-peak scheduling throughout.
Go-live, validation, and automation handoff
We freeze ERPAG writes during the cutover window, run a final delta migration of any records modified during the migration window, then enable Odoo as the system of record. We validate stock levels across warehouses, confirm Work Order statuses, and verify BOM structure in the live environment. We deliver a written inventory of all ERPAG Automation scripts, B2B portal configurations, and Blockly customizations with Odoo equivalents for the customer's administrator to rebuild. We provide a one-week hypercare window for reconciliation issues. Workflow rebuild, sequence rebuild, and training are outside standard scope and require a separate engagement.
Platform deep dives
ERPAG
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 ERPAG 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
ERPAG: 2 requests per second.
Data volume sensitivity
ERPAG 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 ERPAG to Odoo ERP migration scoping. Not seeing yours? Book a call.
Walk through your ERPAG 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 ERPAG
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.