ERP migration

Migrate from CREST ERP to Odoo ERP

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 logo

CREST ERP

Source

Odoo ERP

Destination

Odoo ERP logo

Compatibility

100%

12 of 12

objects map 1:1 between CREST ERP and Odoo ERP.

Complexity

BStandard

Timeline

3-5 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

CREST ERP logo

CREST ERP

What's pushing teams away

  • The manufacturing module is underdeveloped for complex production scenarios, requiring significant custom development work to handle advanced BOMs, multi-level routing, and sub-contracting workflows according to Capterra reviews.
  • Certain processes in CREST ERP are described as unnecessarily lengthy, with multi-level approval chains that feel excessive for simple workflows and cannot be easily disabled without reconfiguration.
  • Management Information reporting is a consistent pain point—users report difficulty generating the analytical reports needed for executive decision-making without additional customization or third-party tools.
  • Growing companies that scale beyond mid-market complexity find CREST ERP's feature depth insufficient, particularly for multi-entity financials, advanced EDI, and international operations that enterprise-tier ERPs handle natively.

Choosing

Odoo ERP logo

Odoo ERP

What's pulling them in

  • Modular pay-as-you-grow model with 80+ apps under one database — teams start with CRM and add Accounting, Inventory, or Manufacturing without switching platforms.
  • Free Community edition lets businesses validate Odoo fit before committing to Enterprise licensing costs that scale with user count.
  • Lowest per-user pricing among mid-market ERPs, with a published free tier for one app and Standard plans starting around $24.90 per user per month.
  • Native integration between modules — a confirmed Sales Order automatically updates inventory, invoicing, and accounting without manual re-entry.
  • Strong Odoo Gold Partner ecosystem provides local implementation support, reducing risk for companies without in-house developers.

Object mapping

How CREST ERP objects map to Odoo ERP

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

maps to

Odoo ERP

Partner (customer)

1:1
Fully supported

CREST 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

maps to

Odoo ERP

Partner (supplier)

1:1
Fully supported

CREST 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

maps to

Odoo ERP

Product / Product Template

1:1
Fully supported

CREST 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

maps to

Odoo ERP

Account

1:1
Fully supported

CREST 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

maps to

Odoo ERP

Account Move (Vendor Bill)

1:1
Fully supported

CREST 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

maps to

Odoo ERP

Account Move (Customer Invoice)

1:1
Fully supported

CREST 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

maps to

Odoo ERP

Sale Order

1:1
Fully supported

CREST 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

maps to

Odoo ERP

Purchase Order

1:1
Fully supported

CREST 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

maps to

Odoo ERP

Asset

1:1
Fully supported

CREST 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

maps to

Odoo ERP

Employee

1:1
Fully supported

CREST 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

maps to

Odoo ERP

Department

1:1
Fully supported

CREST 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

maps to

Odoo ERP

Project

1:1
Fully supported

CREST 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.

Gotchas + challenges

What specifically takes care here

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 logo

CREST ERP gotchas

High

Master data quality determines migration success

Medium

Custom fields lack systematic export mechanism

Medium

Workflow configurations not portable via export

Odoo ERP logo

Odoo ERP gotchas

High

No rollback for CSV imports

High

External ID conflicts on re-import

Medium

Many2many field encoding in CSV imports

Medium

Large export timeouts require batching

Medium

Version schema drift between Odoo releases

Pair-specific challenges

  • CREST ERP has no documented public API for export

    CREST ERP does not expose a documented REST or XML-RPC API for programmatic data retrieval. All migrations from CREST ERP require a combination of direct database-level inspection (with customer-supplied database credentials or export access) and customer-assisted screenshot documentation to build the migration dataset. We generate a data extraction manifest during discovery, and any records that cannot be extracted programmatically are flagged in a manual-extraction work order for the customer's CREST ERP administrator to provide as CSV before migration begins.

  • Odoo XML-RPC enforces a 1 request/second rate limit

    Odoo's external API enforces a hard rate limit of approximately 1 request per second per session. For migrations involving thousands of transactional records—Sales Orders, Purchase Orders, inventory moves, and multi-level BOM children—this rate limit significantly extends migration duration. We address this by batching records into Odoo's ORM create() method with lists of dictionaries (which creates multiple records in a single XML-RPC call), using session-level concurrency where the Odoo edition supports it, and implementing exponential backoff on 429 responses. BOM structures with three or more levels require at least four XML-RPC calls per item (create item, create BOM, create each BOM line, create vendor info), so we sequence BOM imports after simpler master-data records to keep throughput manageable.

  • Multi-level BOMs require decomposition and routing reconstruction

    CREST ERP's manufacturing module stores BOM structures with parent-child relationships and optionally routing data. Odoo uses separate mrp.bom (BOM definition), mrp.routing (work center sequence), and mrp.workcenter (capacity) objects. A CREST ERP BOM with four levels and routing must be decomposed into Odoo's three-object model with routing steps pointing to defined work centers. CREST ERP sub-contracting workflows have no Odoo analog without a subcontracting supplier configured as a vendor on the component parts. We extract all BOM data from CREST ERP during discovery, produce a BOM decomposition document, and configure Odoo's MRP module to match the production structure, with unresolvable routing dependencies flagged for the customer's production engineer to resolve.

  • Custom fields and workflow configurations are not portable

    CREST ERP custom field definitions are organization-specific and there is no documented export mechanism. We capture custom field definitions through a combination of database inspection and customer-assisted screenshots during the discovery phase, then generate a mapping manifest that documents each custom field's intended Odoo equivalent (either a standard Odoo field or an Odoo Studio custom field). Active step-through workflows and multi-level purchase approval chains cannot be migrated as automation logic because they are not exposed through any exportable format. We document all active workflows with screenshots and configuration notes during discovery and deliver a workflow recreation guide for the customer's Odoo administrator to implement in Odoo Studio and purchase approval rules post-migration.

Migration approach

Six steps for a successful CREST ERP to Odoo ERP data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Context on both ends of the pair

CREST ERP logo

CREST ERP

Source

Strengths

  • Fully modular adoption — CRM, Financials, Inventory, Production and HRMS can be turned on selectively rather than as a single upfront commitment
  • Bundled CRM and BI modules avoid the integration cost of separate sales/reporting systems
  • Cloud SaaS subscription pricing makes mid-market adoption viable without capex (Standard tier from $89.99/user/month)
  • Workflow-driven approvals across purchase, sales and HR reduce manual follow-up on routine transactions
  • Named implementation consultants and responsive support cited across multiple verified reviews

Weaknesses

  • Manufacturing module lacks depth for complex production scenarios, requiring significant custom development for multi-level BOMs, routing, and sub-contracting workflows.
  • Management Information reporting is a known friction point—generating analytical and executive reports requires additional customization beyond out-of-box capabilities.
  • Limited documented API access and integration ecosystem makes automated data migration and third-party system connectivity harder to execute reliably.
  • Multi-level approval workflows cannot be easily simplified for straightforward processes, creating unnecessary friction for low-value transactions.
  • Scalability ceiling for multi-entity financials and international operations means growing companies may need to migrate to enterprise-tier ERP platforms.
Odoo ERP logo

Odoo ERP

Destination

Strengths

  • Modular architecture with 80+ apps sharing one database — add Sales, Accounting, Inventory, and Manufacturing incrementally.
  • Free Community edition for self-hosting with no per-user license cost, backed by an active open-source community.
  • Per-user pricing starting around $24.90/month on Standard, significantly lower than comparable ERPs like NetSuite or SAP.
  • Automatic workflow propagation across modules — a confirmed sales order updates inventory, triggers invoicing, and posts accounting entries without manual steps.
  • Odoo.sh provides a managed cloud hosting environment with CI/CD for custom module deployment and staging databases.

Weaknesses

  • Performance suffers under heavy customization — large implementations with many active modules require dedicated optimization.
  • No single-click migration between Odoo major versions; each release introduces ORM changes, deprecated API calls, and schema revisions requiring manual adaptation.
  • Per-user and per-module licensing costs can escalate unpredictably for growing teams adding multiple apps.
  • Steep learning curve with hundreds of configuration options across dozens of modules creates adoption friction and training requirements.
  • Support tiers on Enterprise have inconsistent response times, pushing some customers toward alternatives with more reliable SLAs.

Complexity grading

How hard is this migration?

Standard ERP migration. 3 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across CREST ERP and Odoo ERP.

  • Object compatibility

    B

    3 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    CREST ERP: Not publicly documented.

  • Data volume sensitivity

    B

    CREST ERP doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your CREST ERP to Odoo ERP migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about CREST ERP to Odoo ERP data migrations

Answers to the questions buyers ask most during CREST ERP to Odoo ERP migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most CREST ERP to Odoo migrations land between three and five weeks for straightforward scopes with current-state master data (Customers, Vendors, Items, AP/AR, Sales Orders, Purchase Orders, Fixed Assets, Employees) and no multi-year historical transactions. Migrations that include multi-level BOM decomposition, historical GL journal entries spanning multiple years, HR compensation effective-dated records, or open project time-entry history extend to eight to fourteen weeks because of data extraction complexity, BOM restructuring work, and Odoo XML-RPC batch sequencing time.

Adjacent paths

Related migrations to explore

Ready when you are

Move from CREST ERP.
Land in Odoo ERP, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day