ERP migration

Migrate from metasfresh to Dolibarr ERP

Field-level mapping, validation, and rollback between metasfresh and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.

metasfresh logo

metasfresh

Source

Dolibarr ERP

Destination

Dolibarr ERP logo

Compatibility

92%

12 of 13

objects map 1:1 between metasfresh and Dolibarr ERP.

Complexity

BStandard

Timeline

4-6 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

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

metasfresh logo

metasfresh

What's pushing teams away

  • Steep learning curve when configuring the system for industries outside its default food and beverage workflows, requiring significant consultant time.
  • Installation and build times can be slow, with users reporting the application sometimes hanging during Docker image builds.
  • Not a turnkey solution — companies without technical staff or ERP experience may struggle to configure and maintain metasfresh without external help.
  • Self-hosting responsibility means no vendor-managed updates, backups, or SLA, which some companies prefer to outsource to a SaaS provider.

Choosing

Dolibarr ERP logo

Dolibarr ERP

What's pulling them in

  • Free open-source core with no per-user license fee makes it the lowest-cost entry point for small teams needing ERP and CRM in one package.
  • Self-hosted deployment gives full data ownership and eliminates vendor lock-in, especially attractive to businesses with compliance requirements.
  • Modular architecture means teams enable only the features they use, keeping the interface uncluttered and reducing learning curve.
  • Fast installation with no technical knowledge required — one reviewer set up multiple businesses in minutes using their own hosting.
  • Active community forum and marketplace of third-party add-ons provide support and extension options without mandatory subscription costs.

Object mapping

How metasfresh objects map to Dolibarr ERP

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)

maps to

Dolibarr ERP

Third Party (type = Customer)

1:1
Fully supported

metasfresh 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)

maps to

Dolibarr ERP

Third Party (type = Supplier)

1:1
Fully supported

metasfresh 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

maps to

Dolibarr ERP

Product / Service

1:1
Fully supported

metasfresh 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

maps to

Dolibarr ERP

Price List

1:many
Fully supported

metasfresh 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

maps to

Dolibarr ERP

Customer Order (Commande client)

1:1
Fully supported

metasfresh 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

maps to

Dolibarr ERP

Supplier Order (Commande fournisseur)

1:1
Fully supported

metasfresh 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)

maps to

Dolibarr ERP

Invoice (Facture client / facture fournisseur)

1:1
Fully supported

metasfresh 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)

maps to

Dolibarr ERP

BOM (requires paid BOM module)

1:1
Fully supported

metasfresh 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

maps to

Dolibarr ERP

Project

1:1
Fully supported

metasfresh 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

maps to

Dolibarr ERP

Bank Account (llx_societe_bank)

1:1
Fully supported

metasfresh 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

maps to

Dolibarr ERP

Payment Term (llx_c_payment_term)

1:1
Fully supported

metasfresh 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

maps to

Dolibarr ERP

VAT/Tax (llx_c_tva)

1:1
Fully supported

metasfresh 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)

maps to

Dolibarr ERP

Extra fields (champs libres)

1:1
Mapping required

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

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.

metasfresh logo

metasfresh gotchas

High

No well-documented public REST API for data migration

High

Attachment and archived document extraction is unreliable

Medium

BOM and manufacturing data requires deep schema knowledge

Medium

Custom fields discovered at runtime, not import time

Dolibarr ERP logo

Dolibarr ERP gotchas

High

Foreign key constraint errors on cross-distribution database restore

High

SQL injection vulnerabilities in version 9.0.1

Medium

Custom fields stored as JSON in extraoptions require field-by-field deserialization

Medium

Decimal precision and rounding configuration affects price fields

Low

No native iOS/Android app forces reliance on browser

Pair-specific challenges

  • metasfresh has no documented public REST API

    metasfresh does not publish a consumer-facing REST API for programmatic data extraction. All migration work requires direct PostgreSQL access with read-only credentials against the metasfresh database instance. We connect to the PostgreSQL host, construct queries against the underlying tables (C_BPartner, M_Product, C_Order, C_Invoice, C_Project, pp_product_bom), and bypass the lack of a documented API layer entirely. If the customer does not have PostgreSQL access credentials or direct database access is contractually restricted, migration scope must be renegotiated before work begins.

  • Dolibarr BOM module requires separate purchase

    Dolibarr's Bill of Materials and manufacturing functionality is not part of the free core ERP. It requires purchasing the BOM module from the Dolibarr store or a partner. If metasfresh's MRP module is active and pp_product_bom data exists, we include BOM migration only if the customer confirms the Dolibarr BOM module has been purchased or will be purchased before cutover. Without this module, BOM records cannot land in Dolibarr's standard data model and must be excluded from the migration deliverable with a written note for the customer.

  • Business Partner consolidation requires a split rule

    metasfresh stores customers and vendors as separate partner records even when they represent the same company. Dolibarr consolidates them into a single Third Party record with a type flag (Customer and/or Supplier). We require the customer to define the consolidation rule during scoping: which metasfresh vendor records should be merged with which customer records (typically by company name match or tax ID). Without this rule, the migration produces duplicate Third Parties in Dolibarr and creates reconciliation work post-migration.

  • Attachment and document extraction is unreliable from metasfresh

    metasfresh stores archived invoice PDFs and file attachments as byte arrays in the database or as file system references whose paths are not consistently tracked in metadata tables. There is no supported export path for these objects. We flag this explicitly during scoping and exclude attachments from the migration deliverable unless the customer has direct database access to retrieve them manually. Dolibarr's document storage (dolibarr_documents directory) accepts uploaded files post-migration, but the migration process itself does not move historical PDFs.

  • Dolibarr database migration errors can occur during version upgrades

    Dolibarr's upgrade process occasionally produces database migration errors when keys accumulate beyond MySQL table limits or when migration scripts conflict with existing customizations. We recommend migrating into a freshly installed Dolibarr instance at the target version rather than upgrading an existing Dolibarr instance during migration. If the customer already runs Dolibarr and wants to keep the existing instance, we validate the MySQL key count and test the migration scripts in a staging copy before production cutover.

Migration approach

Six steps for a successful metasfresh to Dolibarr ERP data migration

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

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

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

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

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

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

Context on both ends of the pair

metasfresh logo

metasfresh

Source

Strengths

  • Completely free and open-source under GPLv2/GPLv3 with no per-user or per-company license fees.
  • Docker and Kubernetes deployment flexibility gives full infrastructure control and data sovereignty.
  • DATEV accounting export built in serves the DACH region's tax advisor workflow natively.
  • 60,000+ commits and active development since 2004 indicate long-term project stability.
  • Source code access enables deep customization that commercial ERPs charge premium tiers for.

Weaknesses

  • No vendor-managed cloud hosting option with SLA — self-hosting and maintenance are entirely the customer's responsibility.
  • Public REST API is not well-documented; migrations rely on flat-file exports, SQL access, or metasfresh's internal migration tooling.
  • Installation and build processes can be slow and unreliable, especially in Docker environments without pre-configured resources.
  • Default workflows favor food and beverage industry, requiring significant reconfiguration for other verticals.
Dolibarr ERP logo

Dolibarr ERP

Destination

Strengths

  • Free core software with AGPL license and no per-user mandatory fee for self-hosted deployments.
  • Modular architecture lets teams activate only needed features, keeping the interface focused and the database lean.
  • Self-hosted option provides full data sovereignty and avoids recurring SaaS subscription costs.
  • Built-in CSV/Excel import and export wizard with saved profiles simplifies recurring data operations.
  • Low-code Module Builder allows functional extensions without writing PHP code.

Weaknesses

  • No native documented REST API for programmatic bulk operations — all migrations depend on the import/export wizard or direct database access.
  • Reporting and analytics are weak without paid add-ons, and built-in charts are limited compared to modern SaaS platforms.
  • UI design is described as dated by multiple reviewers, with infrequent visual updates to the default theme.
  • Community-only support for self-hosted deployments means no SLA or guaranteed response time for issues.
  • Security vulnerabilities (CVE-2024-5314, CVE-2024-5315) in version 9.0.1 with no immediate patch reported.

Complexity grading

How hard is this migration?

Standard ERP migration. All 8 core objects map 1:1 between metasfresh and Dolibarr ERP.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across metasfresh and Dolibarr ERP.

  • Object compatibility

    A

    All 8 core objects map 1:1 between metasfresh and Dolibarr ERP.

  • 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

    metasfresh: Not publicly documented.

  • Data volume sensitivity

    B

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

Estimator

Estimate your metasfresh to Dolibarr 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 metasfresh to Dolibarr ERP data migrations

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

Can't find your answer?

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 consultation

Migrations under 15,000 Business Partners and 5,000 Products with no active BOM data complete in four to six weeks. Migrations with active manufacturing BOMs, multi-level product structures, or large historical order volumes (over 10,000 invoices) extend to eight to twelve weeks because of the PostgreSQL extraction complexity, BOM dependency validation, and third-party consolidation reconciliation. The lack of a metasfresh REST API means each migration run requires direct database access and custom query construction, which adds discovery time compared to platforms with documented APIs.

Adjacent paths

Related migrations to explore

Ready when you are

Move from metasfresh.
Land in Dolibarr 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