ERP migration
Field-level mapping, validation, and rollback between metasfresh and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.
metasfresh
Source
Dolibarr ERP
Destination
Compatibility
12 of 13
objects map 1:1 between metasfresh and Dolibarr ERP.
Complexity
BStandard
Timeline
4-6 weeks
Overview
Moving from metasfresh to Dolibarr is a migration between two open-source ERPs that take different architectural approaches. metasfresh runs on Java and PostgreSQL with an ADempiere-based data model and no consumer-facing REST API, requiring us to extract data through direct database queries against its PostgreSQL instance. Dolibarr uses PHP and MySQL or PostgreSQL with a modular architecture where core modules (Third Parties, Products, Orders, Invoices, Projects) are free and advanced accounting, BOM, and manufacturing modules carry per-module licensing. The migration requires resolving the Business Partner split (metasfresh stores customers and vendors separately; Dolibarr consolidates them as Third Parties), mapping pricing systems to Dolibarr's price list structure, and extracting manufacturing BOM data from metasfresh's pp_product_bom tables only when the MRP module is active. We do not migrate workflows, automations, or report definitions; we deliver a written inventory of these for your admin to rebuild in Dolibarr's module configuration.
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 metasfresh object lands in Dolibarr ERP, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
metasfresh
Business Partner (Customer)
Dolibarr ERP
Third Party (type = Customer)
1:1metasfresh Business Partners with partner_type=CUSTOMER map to Dolibarr Third Parties with the Tiers: Customer module enabled and a client checkbox flag. Address data (C_BPartner_Location) maps to Dolibarr's address and contact tables (llx_societe_address). Financial relationship data (payment terms, bank accounts) transfers as reference data into llx_societe_account and llx_societe_remise. The metasfresh is-vendor flag is preserved as a separate Third Party record when the same partner is both a customer and supplier.
metasfresh
Business Partner (Vendor)
Dolibarr ERP
Third Party (type = Supplier)
1:1metasfresh Business Partners with partner_type=VENDOR map to Dolibarr Third Parties with the Tiers: Supplier module enabled and a fornecedor flag. Vendor-specific fields including purchase payment terms and default warehouse assignment transfer to llx_societe_fournisseur.
metasfresh
Product
Dolibarr ERP
Product / Service
1:1metasfresh M_Product records map to Dolibarr llx_product. Products marked as is-stocked map to Dolibarr Product type=1 (storable), while non-stocked items map to type=0 (service). Product categories from M_Product_Category map to Dolibarr llx_product_category. The metasfresh product cost and sales price fields map to llx_product_price for the default price list.
metasfresh
Pricing System
Dolibarr ERP
Price List
1:manymetasfresh M_PricingSystem with M_PriceList and M_PriceList_Version entities map to multiple Dolibarr llx_product_price rows per product. Effective dates from M_PriceList_Version become validity dates on Dolibarr price entries. If metasfresh has customer-specific pricing overrides, these become Dolibarr llx_societe_remise entries linked to the Third Party.
metasfresh
Sales Order
Dolibarr ERP
Customer Order (Commande client)
1:1metasfresh C_Order records with doctype=SALES_ORDER map to Dolibarr llx_commande_fournisseur (or llx_commande if using the order-to-invoice workflow). Order lines from C_OrderLine map to llx_commandedet with the product reference and quantity resolved. Document status (draft, in progress, completed, cancelled) transfers directly. The metasfresh C_DocType determines whether this is a sales or purchase order.
metasfresh
Purchase Order
Dolibarr ERP
Supplier Order (Commande fournisseur)
1:1metasfresh C_Order records with doctype=PURCHASE_ORDER map to Dolibarr llx_commande_fournisseur. Header-to-line relationships are preserved via the order_id reference. Purchase order totals and currency transfer from the metasfresh C_Currency reference.
metasfresh
Invoice (AR and AP)
Dolibarr ERP
Invoice (Facture client / facture fournisseur)
1:1metasfresh C_Invoice records (both C_Invoice and C_InvoiceLine tables) map to Dolibarr llx_facture and llx_facturedet. AR invoices link to the Third Party customer record; AP invoices link to the supplier record. The invoice header status and payment terms transfer, and line item totals recompute against the migrated price list to catch any rounding drift.
metasfresh
BOM (pp_product_bom and pp_product_bomline)
Dolibarr ERP
BOM (requires paid BOM module)
1:1metasfresh pp_product_bom and pp_product_bomline records map to Dolibarr's BOM module (llx_bom and llx_bom_bomline) if the customer has purchased this module. We inspect the pp_product_bom tables during discovery and include BOM data only when the MRP module is confirmed active and the BOM records are populated. Without the Dolibarr BOM module purchased, we flag this as an excluded deliverable and note the module purchase requirement.
metasfresh
Project
Dolibarr ERP
Project
1:1metasfresh C_Project records with C_ProjectLine child rows map to Dolibarr llx_projet and llx_projet_task. Phase and milestone data from metasfresh becomes task hierarchy in Dolibarr. The owning Business Partner reference links the project to the corresponding Third Party in Dolibarr. Time and cost tracking fields map to llx_projet_task_time.
metasfresh
Bank Account
Dolibarr ERP
Bank Account (llx_societe_bank)
1:1metasfresh C_BP_BankAccount records map to Dolibarr llx_societe_bank linked to the Third Party. IBAN, BIC, and bank name fields transfer directly. Bank accounts are imported after Third Parties so the foreign key reference is satisfied.
metasfresh
Payment Terms
Dolibarr ERP
Payment Term (llx_c_payment_term)
1:1metasfresh C_PaymentTerm records (net 30, 2/10 net 30, etc.) map to Dolibarr llx_c_payment_term. Effective date ranges and discount percentages transfer. Payment terms are imported as reference data before any Invoice or Order import so that the foreign key is available on line items.
metasfresh
Tax Category and Tax Code
Dolibarr ERP
VAT/Tax (llx_c_tva)
1:1metasfresh C_TaxCategory and C_Tax records map to Dolibarr llx_c_tva and llx_c_tva. Tax rates tied to geographic zones transfer with effective date ranges preserved. The metasfresh tax rate percentage and tax type (sales vs purchase) determine the Dolibarr taux and applicable type flags.
metasfresh
Custom Fields (AD_Column extensions)
Dolibarr ERP
Extra fields (champs libres)
1:1metasfresh custom fields discovered in AD_Column (custom=Y flag) map to Dolibarr Extra fields per object. We query AD_Column during the discovery phase to enumerate all custom columns per table and include them as additional fields in the export. In Dolibarr, the receiving object must have the extra fields module enabled for the custom data to land.
| metasfresh | Dolibarr ERP | Compatibility | |
|---|---|---|---|
| Business Partner (Customer) | Third Party (type = Customer)1:1 | Fully supported | |
| Business Partner (Vendor) | Third Party (type = Supplier)1:1 | Fully supported | |
| Product | Product / Service1:1 | Fully supported | |
| Pricing System | Price List1:many | Fully supported | |
| Sales Order | Customer Order (Commande client)1:1 | Fully supported | |
| Purchase Order | Supplier Order (Commande fournisseur)1:1 | Fully supported | |
| Invoice (AR and AP) | Invoice (Facture client / facture fournisseur)1:1 | Fully supported | |
| BOM (pp_product_bom and pp_product_bomline) | BOM (requires paid BOM module)1:1 | Fully supported | |
| Project | Project1:1 | Fully supported | |
| Bank Account | Bank Account (llx_societe_bank)1:1 | Fully supported | |
| Payment Terms | Payment Term (llx_c_payment_term)1:1 | Fully supported | |
| Tax Category and Tax Code | VAT/Tax (llx_c_tva)1:1 | Fully supported | |
| Custom Fields (AD_Column extensions) | Extra fields (champs libres)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.
metasfresh gotchas
No well-documented public REST API for data migration
Attachment and archived document extraction is unreliable
BOM and manufacturing data requires deep schema knowledge
Custom fields discovered at runtime, not import time
Dolibarr ERP gotchas
Foreign key constraint errors on cross-distribution database restore
SQL injection vulnerabilities in version 9.0.1
Custom fields stored as JSON in extraoptions require field-by-field deserialization
Decimal precision and rounding configuration affects price fields
No native iOS/Android app forces reliance on browser
Pair-specific challenges
Migration approach
Discovery and infrastructure assessment
We audit the source metasfresh PostgreSQL database to enumerate Business Partners, Products, Orders, Invoices, Projects, BOM tables (pp_product_bom, pp_product_bomline), pricing systems, and custom fields from AD_Column. We also confirm the MRP module activation status and inspect the pp_product_bom records for BOM migration eligibility. On the Dolibarr side, we identify the target version, installed modules, and whether the BOM module is licensed. The discovery output is a written scope with record counts, a custom field inventory, and a BOM eligibility determination.
Third-party consolidation rule design
We design the Business Partner consolidation rule based on the customer's input. For each metasfresh vendor record, we match it against customer records by company name, tax ID, or explicit mapping provided by the customer. We produce a consolidation matrix showing which metasfresh partner IDs merge into which Dolibarr Third Party records. This rule is validated by the customer before PostgreSQL extraction begins, because correcting the consolidation after data is in Dolibarr requires manual deduplication work.
PostgreSQL extraction and transform
We connect to the metasfresh PostgreSQL instance with read-only credentials and extract data in dependency order: reference data first (payment terms, tax categories, currencies, units), then Business Partners, then Products, then pricing systems, then Orders and Invoices, then Projects, then BOMs last (conditional on MRP module active and customer confirming BOM module purchase). Custom fields from AD_Column are appended as additional columns during extraction. Each table is exported as CSV for validation before Dolibarr import.
Dolibarr schema validation and sandbox import
We validate that Dolibarr's target instance has the required modules enabled (Third Parties, Products, Orders, Invoices, Projects, and BOM if applicable) before any data loads. We run a sandbox migration using production-equivalent record counts, reconcile the row counts between metasfresh source and Dolibarr destination, and spot-check 20-30 records per object type against the source data. Any mapping corrections are applied to the transform scripts before the production migration begins.
Production migration in dependency order
We run the production migration in record-dependency order: reference data (payment terms, tax codes), Third Parties (with consolidation applied), Products and price lists, Orders (sales and purchase), Invoices (AR and AP), Projects and tasks, then BOM if eligible. Each phase emits a row-count reconciliation report. The metasfresh instance remains writable during migration, with a final delta catch-up in the cutover window.
Cutover, validation, and handoff
We freeze writes to metasfresh during cutover, run a final delta import of any records modified during the migration window, then enable Dolibarr as the system of record. We deliver a written inventory of any metasfresh workflows, automations, or report definitions that require rebuild in Dolibarr's module configuration. We do not rebuild metasfresh automations as Dolibarr cron jobs or module configurations inside the migration scope; that is a separate engagement or an internal admin task. We support a three-day hypercare window to resolve reconciliation issues raised during initial Dolibarr use.
Platform deep dives
metasfresh
Source
Strengths
Weaknesses
Dolibarr ERP
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. All 8 core objects map 1:1 between metasfresh and Dolibarr ERP.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across metasfresh and Dolibarr ERP.
Object compatibility
All 8 core objects map 1:1 between metasfresh and Dolibarr ERP.
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
metasfresh: Not publicly documented.
Data volume sensitivity
metasfresh 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 metasfresh to Dolibarr ERP migration scoping. Not seeing yours? Book a call.
Walk through your metasfresh to Dolibarr 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 metasfresh
Other ways to arrive at Dolibarr 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.