ERP migration
Field-level mapping, validation, and rollback between CREST ERP and Odoo ERP. We move data and schema; workflows are rebuilt natively in Odoo ERP.
CREST ERP
Source
Odoo ERP
Destination
Compatibility
12 of 12
objects map 1:1 between CREST ERP and Odoo ERP.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from CREST ERP to Odoo ERP is a migration across fundamentally different API architectures and manufacturing data models. CREST ERP has no documented public API for programmatic data export, so we combine database-level inspection with customer-assisted record retrieval to build a complete migration dataset. Odoo receives data via XML-RPC at a hard rate limit of one request per second per session, requiring batch chunking and exponential backoff for transactional objects. Multi-level BOMs from CREST's manufacturing module require decomposition before Odoo can use them as MRP routed structures with work center definitions. We sequence the migration in dependency order—GL accounts, chart of sections, and item masters first, then transactional records—resolving foreign-key lookups as each parent object lands. Approval workflows, custom field definitions, and step-through status chains do not migrate as code; we deliver a written inventory for Odoo administrators to rebuild in Odoo's studio and automation tools.
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 CREST 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.
CREST ERP
Customer
Odoo ERP
Partner (customer)
1:1CREST ERP Customer master records map to Odoo res.partner with partner_type set to 'customer'. Contact details, addresses, credit limits, and payment terms migrate directly. We use the customer code from CREST ERP as the partner's ref field and set the customer_rank to flag them as a customer-facing record. Custom properties attached to customers in CREST ERP are captured via database inspection during discovery and mapped to custom partner fields in Odoo or documented for Odoo Studio recreation.
CREST ERP
Vendor
Odoo ERP
Partner (supplier)
1:1CREST ERP Vendor master records map to Odoo res.partner with partner_type set to 'supplier'. Supplier details, bank information, and performance ratings migrate to the vendor's Odoo partner record. Purchase terms are preserved as purchase_cutoff and property_supplier_payment_term days on the partner. The vendor-supplied catalogue of items maps to Odoo's product.supplierinfo table linked to the vendor partner.
CREST ERP
Item
Odoo ERP
Product / Product Template
1:1CREST ERP Items map to Odoo product.product (stockable, consumable, or service variants). SKU, description, pricing, and UOM migrate to product_template fields with the associated product_variant records. Multi-level BOM structures in CREST ERP require decomposition: we extract the parent-item relationship and component quantities, then create Odoo mrp.bom records with type 'normal' or 'kit' depending on the BOM type, plus the mrp.bom.line children. Odoo requires work center definitions for routed manufacturing; we document the routing requirements for the customer's Odoo administrator to configure before production orders run.
CREST ERP
General Ledger
Odoo ERP
Account
1:1CREST ERP's chart of accounts maps directly to Odoo's account.account records. Account codes, names, account types (asset, liability, equity, income, expense), and cost center assignments migrate. We preserve the CREST ERP account code as the Odoo code field for reconciliation continuity. Intercompany account mappings and bank account structures are reviewed during the GL phase to ensure that CREST's bank-ledger-to-GL-account assignments translate correctly to Odoo's bank reconciliation configuration.
CREST ERP
Open AP
Odoo ERP
Account Move (Vendor Bill)
1:1CREST ERP open AP records migrate as Odoo account.move records of type 'in_invoice', linked to the vendor res.partner. Invoice number, amount, due date, and payment state migrate with the vendor_invoice_id reference preserved. We identify which CREST ERP AP records remain open at cutover to avoid importing satisfied invoices. Odoo's account_payment register handles post-migration payment recording against these migrated bills.
CREST ERP
Open AR
Odoo ERP
Account Move (Customer Invoice)
1:1CREST ERP open AR records migrate as Odoo account.move records of type 'out_invoice', linked to the customer res.partner. Invoice number, outstanding amount, and aging bucket migrate. We flag credit memos and partial payments for correct offset handling using Odoo's credit note pattern. The AR aging report is validated post-migration against the CREST ERP source to confirm totals match before go-live.
CREST ERP
Sales Order
Odoo ERP
Sale Order
1:1CREST ERP Sales Orders migrate as Odoo sale.order records with sale.order.line children. Customer linkage, line items, quantities, pricing, delivery dates, and order status migrate. CREST ERP SFA pipeline stages map to Odoo sale.order state (draft, sent, sale_order, done) with any custom stage status preserved as a custom field on the sale order for audit. Odoo's delivery integration (stock.picking) is triggered from confirmed sale orders after migration; existing fulfilled orders are migrated with delivery moves completed.
CREST ERP
Purchase Order
Odoo ERP
Purchase Order
1:1CREST ERP Purchase Orders map to Odoo purchase.order with purchase.order.line children. Vendor linkage, line items, quantities, pricing, expected delivery dates, and receipt status migrate. CREST ERP approval workflows on purchase orders are documented for Odoo purchase approval rules to be configured post-migration by the customer's admin. Incoming shipments linked to received POs migrate as stock.picking records with state set to done.
CREST ERP
Fixed Asset
Odoo ERP
Asset
1:1CREST ERP Fixed Asset records migrate to Odoo's account.asset records with acquisition cost, depreciation schedule, asset category, location, and maintenance history. Depreciation method and schedule from CREST ERP map to Odoo's fiscal depreciation entries. We generate asset.depreciation.confirmation.lines aligned with the original schedule so that the depreciation timeline is continuous from go-live.
CREST ERP
Employee
Odoo ERP
Employee
1:1CREST ERP Employee records migrate to Odoo hr.employee with personal details, job role, department, and bank details. Effective-dated compensation history requires sequencing: we migrate the most recent compensation record as the employee's current contract (hr.contract), and historical pay period entries migrate as payroll journal entries if Odoo Payroll is in scope, or as a compensation history note if not. Leave balances from CREST ERP map to Odoo's hr.leave.allocation records.
CREST ERP
Department
Odoo ERP
Department
1:1CREST ERP Department structure maps to Odoo's hr.department with department codes, names, and parent-child relationships preserved. We validate that cost center assignments on GL accounts align with the migrated department hierarchy during the GL migration phase. The organizational chart in Odoo is validated post-migration against the source.
CREST ERP
Project
Odoo ERP
Project
1:1CREST ERP Project records migrate to Odoo project.project with budget, resource assignments, tasks, milestones, and time entries. CREST ERP project templates require manual re-creation in Odoo as project templates because template portability between systems is not supported by the APIs of either platform. Time entries from CREST ERP map to Odoo account.analytic.line records linked to the project.
| CREST ERP | Odoo ERP | Compatibility | |
|---|---|---|---|
| Customer | Partner (customer)1:1 | Fully supported | |
| Vendor | Partner (supplier)1:1 | Fully supported | |
| Item | Product / Product Template1:1 | Fully supported | |
| General Ledger | Account1:1 | Fully supported | |
| Open AP | Account Move (Vendor Bill)1:1 | Fully supported | |
| Open AR | Account Move (Customer Invoice)1:1 | Fully supported | |
| Sales Order | Sale Order1:1 | Fully supported | |
| Purchase Order | Purchase Order1:1 | Fully supported | |
| Fixed Asset | Asset1:1 | Fully supported | |
| Employee | Employee1:1 | Fully supported | |
| Department | Department1:1 | Fully supported | |
| Project | Project1: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.
CREST ERP gotchas
Master data quality determines migration success
Custom fields lack systematic export mechanism
Workflow configurations not portable via export
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 data extraction
We conduct a structured discovery engagement with the customer's CREST ERP administrator to identify all active modules, record counts, custom field definitions, active workflow configurations, and the BOM structure if the manufacturing module is in use. Because CREST ERP has no documented API, we work with the customer to extract data via direct database access or application-level exports. We produce a data extraction manifest listing every object to be migrated, its record count, its extraction method (automated via DB query or manual via CSV export), and any records that cannot be extracted programmatically and require manual handling. This phase also includes the mandatory master-data audit: we run duplicate detection on Customers and Vendors, validate Items for inconsistent UOM and naming, and score the completeness of the extracted dataset. The customer must resolve dedup and completeness issues before we proceed to migration.
Odoo instance provisioning and schema preparation
We provision the Odoo destination instance (Online or on-premise depending on the customer's chosen deployment) and design the Odoo schema to receive the migrated data. This includes configuring the chart of accounts to match CREST ERP's GL structure, setting up the warehouse and locations for inventory, configuring product categories and product variants to match the CREST ERP item hierarchy, defining work centers for the manufacturing module if BOM data is migrating, and configuring the HR structure including departments and employment categories. Custom fields identified during discovery are pre-created in Odoo via the settings interface or directly in the database to ensure the destination schema is ready before any data loads begin.
Sandbox migration and reconciliation
We run a full migration into an Odoo sandbox environment using production-like data volume. The customer's operations lead and finance lead reconcile record counts (partner records, product records, account moves, sale and purchase orders, assets, employees, projects) against the CREST ERP source. Spot-checks of 25-50 records per object validate field-level accuracy. The BOM decomposition is tested by creating a sample production order in Odoo from a migrated BOM to confirm that component explosions and work center routing resolve correctly. Any mapping corrections and data-quality issues surface here before production migration begins.
Owner and vendor resolution
We extract every distinct owner and vendor referenced on transactional records in CREST ERP and match them against the corresponding Odoo partner and employee records. Users (sales owners, purchase approvers) are provisioned in Odoo with matching email addresses before record migration continues. Vendors resolved from CREST ERP's vendor master populate the Odoo res.partner records with supplier_rank set, and any vendor records missing from the vendor master are held in a reconciliation queue for the customer's admin to supplement before final import.
Production migration in dependency order
We run production migration in the correct record-dependency sequence: GL accounts first, then chart of sections and account tags; partners (Customers and Vendors) next with the customer/supplier rank set; products and product variants with BOM decomposition applied; account moves (AP and AR) with vendor and customer links resolved; sale orders and purchase orders with line items and status; fixed assets with depreciation schedules; employees with HR data and leave allocations; and projects with tasks and time entries. Each phase emits a row-count reconciliation report validated against the source before the next phase begins. Odoo XML-RPC batching and rate-limit handling are applied throughout; multi-level BOM creation uses the four-call sequence (product create, BOM create, BOM lines, vendor info) with exponential backoff on rate-limit responses.
Cutover, validation, and workflow handoff
We freeze CREST ERP writes during a defined cutover window, run a final delta migration of any records modified during the window, then set Odoo as the system of record. We validate the AR aging report against the CREST ERP source, reconcile GL trial balances, and confirm inventory quantities on hand match at cutover date. We deliver the custom field mapping manifest, the BOM decomposition document, the workflow recreation guide for Odoo Studio, and the purchase approval configuration guide. We support a one-week hypercare window to resolve post-go-live reconciliation issues. We do not rebuild CREST ERP workflows, approval chains, or custom reports as Odoo automations inside the migration scope; those are separate engagements.
Platform deep dives
CREST ERP
Source
Strengths
Weaknesses
Odoo ERP
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. 3 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 CREST ERP and Odoo ERP.
Object compatibility
3 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
CREST ERP: Not publicly documented.
Data volume sensitivity
CREST 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 CREST ERP to Odoo ERP migration scoping. Not seeing yours? Book a call.
Walk through your CREST 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 CREST 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.