ERP migration
Field-level mapping, validation, and rollback between eCommerce Pro and Odoo ERP. We move data and schema; workflows are rebuilt natively in Odoo ERP.
eCommerce Pro
Source
Odoo ERP
Destination
Compatibility
8 of 11
objects map 1:1 between eCommerce Pro and Odoo ERP.
Complexity
BStandard
Timeline
4-8 weeks
Overview
Moving from eCommerce Pro to Odoo ERP is a replatforming from a commerce-first system to a full business management suite. eCommerce Pro organises products, customers, and orders in a unified storefront model; Odoo separates these into distinct apps (Website/eCommerce, Contacts, Sales, Inventory, Accounting) with interlinked schemas. We extract products with variants, images, and pricing rules from eCommerce Pro and map them to Odoo's product.template and product.product model. Customer records deduplicate by email match and land in Odoo's res.partner. Historical orders transfer as sale.order with their line items, payment states, and shipment records. We do not migrate eCommerce Pro automations, coupon rules, or storefront customisations as code; we deliver a written inventory of these for Odoo Studio rebuild. Multi-warehouse inventory requires pre-migration planning because Odoo's stock.quant model structures locations differently from flat eCommerce inventory pools.
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 eCommerce Pro 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.
eCommerce Pro
Product
Odoo ERP
product.template + product.product
1:manyeCommerce Pro products with variants map to Odoo product.template (the shared product record) and one product.product per variant combination. Attribute names (colour, size) and values map to Odoo attribute lines on the template. Pricing at the variant level (price per SKU) maps to Odoo seller_ids and pricelist items with the product.product as the scope. We resolve the split during the audit phase because variant-heavy catalogs (100+ attributes, thousands of combinations) require the import to run in variant-first order to avoid template reference failures.
eCommerce Pro
Customer
Odoo ERP
res.partner
1:1eCommerce Pro customer records map to Odoo res.partner. We use email as the dedupe key during import. Customer addresses migrate as partner addresses (street, city, state, zip, country) with address type flags (type=contact, invoice, delivery). The acceptsmarketing flag from eCommerce Pro maps to a custom boolean field opt_in_email__c on partner for reactivation post-migration. Customers with no email address are flagged for manual review because Odoo requires email for B2B and some eCommerce flows.
eCommerce Pro
Order
Odoo ERP
sale.order
1:1eCommerce Pro orders map to Odoo sale.order with order lines, payment state, and shipment tracking preserved. Order status (pending, processing, shipped, delivered, cancelled) maps to Odoo picking state (waiting, confirmed, assigned, done, cancelled) and invoice state (draft, posted, cancelled). Historical orders import with a backdate matching the original order timestamp so reporting periods reflect the correct fiscal month.
eCommerce Pro
Fulfilment
Odoo ERP
stock.picking
1:1eCommerce Pro fulfilment records map to Odoo stock.picking linked to the corresponding sale.order. Tracking numbers and carrier names transfer to the picking's carrier_id and move_lines' result_package_id. Partial shipments create separate picking records under the same sale.order. Completed fulfilment status maps to done on the picking; cancelled fulfilment maps to cancelled.
eCommerce Pro
Inventory
Odoo ERP
stock.quant
1:1eCommerce Pro inventory levels per SKU map to Odoo stock.quant records. Single-warehouse setups map directly to one stock.location (stock_location_stock). Multi-warehouse setups require us to either consolidate into one location or split the eCommerce inventory pool into separate Odoo warehouse locations (WH/Main, WH/Secondary). We validate that stock.quant quantities per product and location satisfy sale.order move lines after import.
eCommerce Pro
Coupon / Discount
Odoo ERP
coupon.program or product.pricelist.item
1:1eCommerce Pro discount codes (percentage, fixed amount, buy-X-get-Y) map to Odoo coupon.program records if the Odoo Loyalty app is installed. Percentage discounts that apply at checkout without a code map to product.pricelist.item rules scoped to the customer or product category. We flag complex stacking rules (discount-on-discount, time-gated tiers) as requiring Odoo Studio rebuild because Odoo coupon logic handles these differently from eCommerce Pro.
eCommerce Pro
Payment Transaction
Odoo ERP
account.payment
1:1eCommerce Pro payment transactions map to Odoo account.payment linked to the corresponding sale.order invoice. Payment method (credit card, PayPal, bank transfer) maps to Odoo's payment journal and method configuration. Captured, pending, refunded, and failed states map to account.payment state values. We do not re-process payments; we record the historical transaction as a reconciled payment against the customer invoice.
eCommerce Pro
Product Image
Odoo ERP
ir.attachment
1:1eCommerce Pro product images migrate as ir.attachment records linked to product.product via the product.image_ids relation. We validate image URLs and optionally re-host assets to Odoo's filestore during import. Variant-level images attach to the specific product.product; template-level images attach to product.template.
eCommerce Pro
Product Category
Odoo ERP
product.category
1:1eCommerce Pro product categories map to Odoo product.category hierarchy. The parent_id chain (if multi-level) preserves in Odoo. We run a topological sort to import parent categories before children to avoid foreign key constraint violations.
eCommerce Pro
Tax Configuration
Odoo ERP
account.tax
lossyeCommerce Pro tax codes map to Odoo account.tax records configured manually in the Odoo Accounting app before migration. We preserve the source tax code name and rate in a custom field source_tax_code__c on account.tax so that the customer's accountant can map to the correct tax jurisdictions post-import. This is a manual step because tax configuration depends on the customer's nexus, jurisdiction, and filing regime.
eCommerce Pro
B2B Pricing Rules
Odoo ERP
product.pricelist
lossyeCommerce Pro B2B pricing lists, volume tiers, and company-specific catalogs map to Odoo product.pricelist records with pricelist.item rules scoped by product, category, or partner. Company-specific pricing requires the Odoo Contacts app with partner properties enabled so that the correct pricelist applies automatically at sale order creation. We flag any pricing logic that uses formula-based calculations (e.g., cost-plus markup) as requiring manual configuration in Odoo pricelist rules.
| eCommerce Pro | Odoo ERP | Compatibility | |
|---|---|---|---|
| Product | product.template + product.product1:many | Fully supported | |
| Customer | res.partner1:1 | Fully supported | |
| Order | sale.order1:1 | Fully supported | |
| Fulfilment | stock.picking1:1 | Fully supported | |
| Inventory | stock.quant1:1 | Mapping required | |
| Coupon / Discount | coupon.program or product.pricelist.item1:1 | Fully supported | |
| Payment Transaction | account.payment1:1 | Fully supported | |
| Product Image | ir.attachment1:1 | Fully supported | |
| Product Category | product.category1:1 | Fully supported | |
| Tax Configuration | account.taxlossy | Fully supported | |
| B2B Pricing Rules | product.pricelistlossy | 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.
eCommerce Pro gotchas
URL structure changes destroy SEO value without redirect mapping
Dirty product data causes import failures and post-launch cleanup
Third-party integrations break after replatforming
Rushed testing misses checkout edge cases
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 Odoo app selection
We audit the eCommerce Pro catalog across products (with variant count), customers, order history (with date range and status distribution), inventory records, coupon and discount codes, and any B2B pricing lists. We pair this with an Odoo apps assessment: which Odoo modules the customer needs (Sales, Inventory, Accounting, Website/eCommerce, Loyalty, CRM), which are already active, and whether the Odoo edition (Community with paid apps or Odoo Online/Enterprise) matches the destination architecture. The discovery output is a written migration scope and an Odoo app activation plan.
Data audit and cleansing
We extract and validate eCommerce Pro data against Odoo schema requirements. This includes deduplicating customer records by email, resolving the product variant matrix into template-plus-variant pairs, normalizing variant attribute names, stripping malformed HTML from product descriptions, mapping tax codes to placeholder account.tax records, and auditing inventory quantities for multi-warehouse split requirements. Any record failing Odoo validation is flagged in a cleansing report with the specific failure reason and a recommended fix. Migration cannot proceed to production until the cleansing report shows fewer than 0.1 percent validation errors.
Odoo environment provisioning and schema pre-creation
We set up the Odoo destination environment (Odoo Online database or self-hosted Odoo.sh instance) and pre-create all schema elements before any data moves: product.category hierarchy, product.template and product.product records, res.partner records, product.pricelist rules, account.tax records, warehouse locations (stock.location), and inventory valuation configuration. Schema is validated in a staging environment before production migration begins. If the Odoo Loyalty app is needed for coupon programs, we install and configure it during this phase.
Sandbox migration and reconciliation
We run a full migration into the Odoo staging environment using production-equivalent data volume. The customer's operations lead reconciles record counts (products in, templates vs variants, customers in, orders in, stock.quants per location), spot-checks 25-50 records against the eCommerce Pro source, and validates that sale.order lines resolve to the correct product.product and that invoice states match source payment states. Any mapping corrections happen in staging. The customer signs off the staging reconciliation before production migration is scheduled.
Production migration in dependency order
We run production migration in record-dependency order: product.categories (leaf-first for hierarchy), product.templates, product.products (with template_id resolved), res.partner records (with dedupe applied), stock.quant records (with location_id resolved per warehouse), sale.orders (with partner_id and order lines resolved), stock.pickings (linked to sale.order), and account.payment records (linked to sale.order invoice). Each phase emits a row-count and validation-error report before the next phase begins. The eCommerce Pro storefront remains writeable during migration; we capture a delta of any orders placed during the migration window for a final sync before cutover.
Cutover, validation, and automation rebuild handoff
We freeze eCommerce Pro writes during cutover, run the final delta migration, then switch the system of record to Odoo. We deliver the eCommerce automation inventory document (discount rules, abandoned cart logic, shipping triggers) for Odoo Studio rebuild or external email tool configuration. We support a one-week hypercare window where we resolve any record-level reconciliation issues. We do not rebuild eCommerce Pro storefront customisations as Odoo Website modules inside the migration scope; that work is handled separately by an Odoo web development partner.
Platform deep dives
eCommerce Pro
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 eCommerce Pro 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
eCommerce Pro: Varies by tier; Enterprise tier increases limits via negotiated SLAs.
Data volume sensitivity
eCommerce Pro exposes a bulk API — large-volume migrations stream efficiently.
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 eCommerce Pro to Odoo ERP migration scoping. Not seeing yours? Book a call.
Walk through your eCommerce Pro 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 eCommerce Pro
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.