ERP migration

Migrate from ERPNext to Dolibarr ERP

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

ERPNext logo

ERPNext

Source

Dolibarr ERP

Destination

Dolibarr ERP logo

Compatibility

86%

12 of 14

objects map 1:1 between ERPNext and Dolibarr ERP.

Complexity

BStandard

Timeline

3-5 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

ERPNext and Dolibarr are both open-source ERPs, but they are architecturally different enough that migration requires careful schema mapping rather than a simple record copy. ERPNext stores every entity as a DocType document with nested child tables and an extensible Frappe Framework; Dolibarr uses a flat modular object model where each entity type is a standalone table and features are activated via a module toggle. We extract ERPNext data via direct MariaDB query or CSV export, resolve the child-table relationships (order lines, packed items, BOM operations) into flat relational files, and load them into Dolibarr through its import tool or REST API. BOM data and multi-level manufacturing routing cannot map natively to Dolibarr — we flatten operation trees into product configuration records or linked lookup tables and present the customer with a structural choice before import. Custom fields stored in ERPNext's Custom Field DocType are exported as a separate registry and reconstructed in Dolibarr's CustomFields module. We do not migrate Frappe server scripts, ERPNext Workflows, or third-party Frappe App modules as these depend on Frappe's Python runtime and cannot execute in a non-Frappe environment.

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

ERPNext logo

ERPNext

What's pushing teams away

  • Over-customisation without governance accumulates over time, making version upgrades between major releases painful and sometimes impossible without reverting customisations first.
  • The learning curve is steep for non-technical users — role-based permission setups, workflow automation, and report builder configuration require training investment that smaller teams underestimate.
  • Performance degrades on large transaction volumes unless the MariaDB backend is tuned, indexed properly, and running on adequate hardware, leading some to outgrow the stack.
  • Integration with best-of-breed point solutions (specialist payroll, e-commerce platforms, industry-specific tools) often requires custom API work rather than native connectors, increasing implementation cost.
  • Support is community-driven or partner-delivered; there is no vendor SLA for self-hosted deployments, which enterprises with compliance obligations find difficult to accept.

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 ERPNext objects map to Dolibarr ERP

Each row shows how a ERPNext 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.

ERPNext

Customer

maps to

Dolibarr ERP

Third-Party (Type: Customer)

1:1
Fully supported

ERPNext Customer DocType records map to Dolibarr Third-Party objects with the IsCustomer flag set to 1. Customer name, primary contact details, GST/HST number, territory, and default currency migrate directly. Customer group maps to Dolibarr's Category system or a custom customer-type field. We extract all customer address and contact child table rows as separate relational CSVs and re-link them through Dolibarr's Contact and Address modules using the external ID pattern for deduplication during import.

ERPNext

Supplier

maps to

Dolibarr ERP

Third-Party (Type: Supplier)

1:1
Fully supported

ERPNext Supplier DocType maps to Dolibarr Third-Party with IsSupplier flag set to 1. Supplier name, primary contact, PAN/GST number, and default currency transfer directly. ERPNext's supplier price list maps to Dolibarr's supplier catalog if the purchasing module is activated. Address and contact child rows follow the same external-ID linking pattern as Customer.

ERPNext

Item

maps to

Dolibarr ERP

Product or Service

1:1
Fully supported

ERPNext Item records map to Dolibarr Product (for stockable items) or Service (for non-stockable items) based on the Item's is_stock_item flag. Item code, item name, description, item group, brand, UOM, and barcodes migrate directly. Valuation method (FIFO, Moving Average, Standard Rate) stores as a custom field in Dolibarr since Dolibarr's stock valuation is simpler. ERPNext's item defaults per company map to Dolibarr's multi-entity price list configuration if the multi-company module is active.

ERPNext

BOM (Bill of Materials)

maps to

Dolibarr ERP

Product (BOM tab) + Custom Configuration Record

lossy
Fully supported

ERPNext's multi-level nested BOM structure with operation routing and workstation definitions has no native Dolibarr equivalent. We extract the full BOM operation tree (items, quantities, operations, workstation types, cycle times) and present the customer with two options: store the flattened BOM as a linked custom configuration record in Dolibarr's Product module, or collapse multi-level BOMs into a simplified product recipe stored as custom fields. Operation routing and workstation costing do not migrate to standard Dolibarr fields; these are documented in the custom configuration record for manual reference.

ERPNext

Sales Order

maps to

Dolibarr ERP

Order

1:1
Fully supported

ERPNext Sales Order maps to Dolibarr Order (with module Societe, Product, and Commande activated). Order header fields (customer, currency, payment terms, incoterms) migrate directly. Order items map as OrderLine records with product reference, qty, rate, and discount. Taxes and charges from ERPNext's taxes and charges child table migrate to Dolibarr's extra-fee line model. Packed items and product bundle components are extracted as separate relational rows and linked via the OrderLine relationship during import.

ERPNext

Purchase Order

maps to

Dolibarr ERP

Supplier Order

1:1
Fully supported

ERPNext Purchase Order maps to Dolibarr SupplierOrder (supplier order). Supplier reference, order date, currency, and payment terms migrate directly. PO line items map to Dolibarr SupplierOrderLine records with the supplier's product reference, ordered qty, and rate. Taxes and charges migrate as extra-fee lines following the same pattern as Sales Order.

ERPNext

Sales Invoice

maps to

Dolibarr ERP

Invoice (Customer)

1:1
Fully supported

ERPNext Sales Invoice maps to Dolibarr Facture (customer invoice). We resolve each invoice's payment status from ERPNext v14+'s split Payment Ledger before migration — an invoice appears open in ERPNext's invoice table even when settled, and the actual payment state is stored in Payment Entry and Payment Ledger records. We query the payment ledger, compute the resolved status (paid, partial, unpaid), and set the Dolibarr invoice status accordingly so open invoices do not appear overdue on day one.

ERPNext

Purchase Invoice

maps to

Dolibarr ERP

Invoice (Supplier)

1:1
Fully supported

ERPNext Purchase Invoice maps to Dolibarr Facture (supplier invoice). The same payment ledger resolution applies for ERPNext v14+ instances: we join Purchase Invoice with Payment Entry and Payment Ledger to compute the actual settled status before setting the Dolibarr invoice status. ERPNext's taxes withheld field maps to a custom field in Dolibarr since Dolibarr's standard tax model does not include withholding at the invoice line level.

ERPNext

Payment Entry

maps to

Dolibarr ERP

Payment

1:1
Fully supported

ERPNext Payment Entry records map to Dolibarr Payment records linked to the resolved invoice via the invoice reference we compute during payment ledger resolution. For v13 and earlier, the paid/unpaid state is directly on the invoice; for v14+, we join Payment Entry to Payment Ledger to determine the settlement amount per invoice and create Dolibarr Payment records accordingly. Payment method (cash, bank, journal) maps to Dolibarr's PaymentMode field.

ERPNext

Project

maps to

Dolibarr ERP

Project

1:1
Fully supported

ERPNext Project DocType maps to Dolibarr Project with Task sub-objects. We extract the full project hierarchy: project name, customer (via Third-Party external ID), status, planned start and end dates, and billing type. Tasks nested under the project are exported as separate rows and inserted as Dolibarr Task records linked to the parent Project. ERPNext time logs and milestone dates are stored as Task fields or custom fields in Dolibarr depending on the customer's reporting needs.

ERPNext

Employee

maps to

Dolibarr ERP

User (with HR module)

1:1
Fully supported

ERPNext Employee DocType records map to Dolibarr User records when Dolibarr's HR module (RH) is activated. Employee name, date of joining, department, designation, and employment type migrate directly. Salary structure and bank details store as custom fields on the User object since Dolibarr's standard HR module stores these in separate child tables that require module activation. ERPNext attendance and leave records migrate as Dolibarr Holiday and Attendance records if the corresponding Dolibarr modules are activated.

ERPNext

Stock Entry

maps to

Dolibarr ERP

Stock Movement

1:1
Fully supported

ERPNext Stock Entry records map to Dolibarr StockMovement records (with Stock module activated). We flag whether ERPNext uses perpetual or periodic inventory because Dolibarr's default stock module assumes perpetual. Open stock ledger entries with future effective dates are exported and inserted with their original posting dates to preserve the financial period in which they should have been recorded.

ERPNext

Custom Fields

maps to

Dolibarr ERP

CustomFields

lossy
Mapping required

ERPNext Custom Field DocType registry is exported as a separate catalog of field definitions (fieldname, fieldtype, label, options, mandatory flag, depends_on condition). We provide a written guide for reconstructing each custom field in Dolibarr's CustomFields module, which uses PHP hook injection rather than a UI-based custom field builder. The customer or a Dolibarr partner recreates these in Dolibarr before the data import phase so that fields exist on the destination schema before records are loaded.

ERPNext

File / Attachment

maps to

Dolibarr ERP

Document

1:1
Fully supported

ERPNext File records reference blob storage (Frappe private files or S3-compatible). We export file metadata (filename, URL, doctype reference, creation date) and copy binary files to the Dolibarr documents directory. The file's parent reference is reconstructed in Dolibarr by matching the source doctype and document name against the migrated record IDs. Large binary attachments may require FTP or direct file copy into the Dolibarr documents directory rather than API upload.

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.

ERPNext logo

ERPNext gotchas

High

CSV import does not detect or prevent duplicate records

High

Custom server scripts break silently on version upgrades

Medium

BOM routing and workstation data requires manual reconstruction

Medium

Payment ledger entries in v14+ are decoupled from invoices

Low

Frappe rate limiting is configurable per-site and undocumented

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

  • BOM routing and workstation data has no Dolibarr native home

    ERPNext's Manufacturing module supports multi-level BOMs with operation routing, workstation types, piece-rate or hour-rate costing, and operation-level descriptions. Dolibarr has no equivalent routing or workstation scheduling module. We extract the full operation tree during discovery and present the customer with two options before migration: maintain BOM detail in a linked custom configuration record (a separate Dolibarr Product attribute table) or collapse multi-level BOMs into a simplified flat recipe stored as custom fields on the Product record. Neither approach preserves the operation schedule as a native Dolibarr object. If the customer's manufacturing workflow depends on ERPNext's operation routing for scheduling, this structural limitation must be acknowledged before migration scope is signed off.

  • ERPNext v14+ payment ledger requires join to resolve invoice status

    ERPNext v14 introduced a split Payment Ledger where payments are stored as independent Payment Entry documents rather than child rows on Invoices. An invoice can appear open in ERPNext's invoice table even when it has been fully settled via a separate Payment Entry. We run a pre-extraction payment resolution query that joins the Payment Ledger to each invoice and computes the actual settled amount and status before setting the Dolibarr invoice status. Migrations that skip this step result in every open invoice appearing unpaid in Dolibarr on day one, triggering unnecessary collection follow-ups.

  • Dolibarr CustomFields requires PHP hook code, not a UI builder

    Dolibarr's CustomFields module (dolibarr_module_customfields) is a community extension that allows custom fields, but it requires writing PHP hook code or using the module's JSON-based field definition format. There is no UI-based custom field builder comparable to ERPNext's DocType Custom Field form. We export the full ERPNext custom field registry and provide a written reconstruction guide, but the customer or a Dolibarr partner must implement the PHP hook or JSON definition to recreate each field in Dolibarr. This is a manual step that runs before data import, not a direct automated migration.

  • ERPNext's nested child tables require flattening for Dolibarr's flat import format

    ERPNext stores order lines, packed items, product bundle components, and BOM item rows as nested child tables within a parent document. Dolibarr's import tool accepts flat CSV rows per object type (one row per OrderLine, one per SupplierOrderLine, one per StockMovement). We extract every child table as a separate relational CSV with a foreign key reference to the parent document, then re-link them during Dolibarr import by matching the parent document's external ID. Packed items and bundle components require a separate transform pass to either flatten into the main order line or create as separate linked rows.

  • Frappe server scripts and third-party Frappe App modules cannot migrate

    ERPNext allows Python server scripts that hook into document save, validate, and submit events. These are stored in the database and reference Frappe's Python runtime environment. Third-party Frappe Apps extend ERPNext with domain-specific DocTypes and server scripts. Neither can execute in a non-Frappe environment. We audit the full script registry during discovery and provide a compatibility report for each script, but we do not migrate them. The customer receives a written inventory of every active server script and third-party Frappe App with its purpose and replacement recommendation for Dolibarr or a separate system.

Migration approach

Six steps for a successful ERPNext to Dolibarr ERP data migration

  1. Discovery and migration scope definition

    We audit the source ERPNext instance across DocType inventory, custom field registry, custom server scripts, third-party Frappe App modules, and BOM complexity. We identify the target Dolibarr modules to activate based on the customer's active ERPNext modules (CRM, Sales, Purchasing, Stock, Projects, HR). We document the ERPNext version and check for v14+ Payment Ledger split, which requires the payment resolution query during extraction. The discovery output is a written migration scope covering record volumes, BOM handling approach, custom field reconstruction plan, and a list of items that cannot migrate (server scripts, Frappe App modules, ERPNext Workflows).

  2. Data extraction and child-table flattening

    We extract ERPNext data via direct MariaDB query or CSV export from the Data Export tool. Every DocType with child tables (Sales Order with Order Items and Packed Items, BOM with BOM Items and Operations, Invoice with taxes and payment schedule) is decomposed into separate relational CSV files linked by a shared external ID. The extraction script runs against the production database with read-only access and produces an audit log of record counts per DocType. We run the payment ledger resolution query for ERPNext v14+ instances at this stage to compute the final invoice payment status before export files are finalized.

  3. BOM analysis and routing reconstruction plan

    We analyze the full BOM registry for nesting depth, operation routing entries, and workstation definitions. For each BOM, we compute the flatten option (simplified recipe stored as custom fields on the Product record) versus the linked configuration record option (a separate table linked to Product). We present the customer with a BOM handling decision document and wait for their sign-off before proceeding to transform. Any BOM that references Frappe App-specific fields is flagged and excluded from the automated transform.

  4. Custom field registry export and Dolibarr reconstruction guide

    We export the full ERPNext Custom Field DocType registry as a structured JSON file covering every custom field's parent DocType, fieldname, fieldtype, label, options, mandatory flag, and depends_on condition. We generate a written Dolibarr CustomFields reconstruction guide that maps each ERPNext field type to the equivalent Dolibarr CustomFields PHP hook definition or JSON format. The customer or a Dolibarr partner implements these definitions in a staging Dolibarr instance before the migration import phase begins. We validate that the destination fields exist before each import phase starts.

  5. Sandbox migration and reconciliation

    We run a full migration into a fresh Dolibarr instance (staging) using the extracted CSV files transformed to Dolibarr's import format. The customer's team reconciles record counts (Customers in, Suppliers in, Items in, Orders in, Invoices in), spot-checks 25-50 records against the ERPNext source for field accuracy, and reviews the BOM handling output and custom field reconstruction. Any mapping corrections are applied to the transform scripts and the sandbox migration is re-run until the customer signs off. This step also validates that Dolibarr modules are correctly activated and that the CustomFields reconstruction matches the ERPNext custom field registry.

  6. Production migration, cutover, and handoff

    We run production migration in dependency order: Third-Party records (Customers and Suppliers), Products and Services, Projects and Tasks, Stock data, then transactional documents (Orders, Invoices, Payments). Each phase emits a row-count reconciliation report and the customer's team validates the phase before the next begins. For ERPNext v14+, the payment ledger resolution query runs as part of the invoice extraction phase before Orders are inserted. We freeze ERPNext writes during cutover, run a delta migration of any records modified during the migration window, then set Dolibarr as the system of record. We deliver the server script and Frappe App inventory document for the customer's admin to review. We do not rebuild ERPNext Workflows or custom server scripts in Dolibarr; those require a separate Dolibarr partner engagement.

Platform deep dives

Context on both ends of the pair

ERPNext logo

ERPNext

Source

Strengths

  • 100% open-source under GPL-3.0 — no per-user license fees, full source code access, and no vendor lock-in for hosting decisions.
  • All core ERP modules (accounting, CRM, inventory, manufacturing, HR) are included in the base product without feature-gating behind paid tiers.
  • Frappe Framework enables deep customisation through custom fields, client scripts, server scripts, and a full REST API for programmatic access.
  • Active community of 30,000+ businesses with certified implementation partners globally reduces reliance on a single vendor for support.
  • Version 16 as of 2026 includes 600+ developer contributions and 50+ new features across finance, manufacturing, and HR modules.

Weaknesses

  • Major version upgrades are complex and frequently break custom scripts and third-party Frappe Apps, requiring a regression-testing window before going live on the new version.
  • Community support lacks SLA-backed guarantees; enterprise organisations requiring 24/7 vendor support with contractually defined response times need to engage a certified partner or managed hosting provider.
  • Performance on large transaction volumes requires MariaDB backend tuning and adequate server resources — the default configuration is not optimised for high-throughput manufacturing or distribution operations.
  • Learning curve is steep for non-technical users; configuration of roles, permissions, workflows, and report builder demands dedicated training or partner consulting.
  • No native built-in data migration tooling — CSV import is the standard path but lacks conflict detection, deduplication logic, or rollback capability.
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 ERPNext and Dolibarr ERP.

B

Overall complexity

Standard migration

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

  • Object compatibility

    A

    All 8 core objects map 1:1 between ERPNext 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

    C

    ERPNext: Configurable per-site; default limits are not publicly documented and are set in site_config.json by the hosting provider. We probe the rate limit headers on discovery and throttle accordingly..

  • Data volume sensitivity

    B

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

Estimator

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

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

Can't find your answer?

Walk through your ERPNext to Dolibarr ERP migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most migrations land between three and five weeks for accounts with fewer than 10,000 customer records, 5,000 items, and no multi-level BOMs. Migrations with multi-level BOMs requiring flattening and routing reconstruction, a large custom field registry, or open payment ledger entries from ERPNext v14+ requiring payment-state resolution move to seven to eleven weeks because of the BOM analysis phase, custom field reconstruction guide production, and payment ledger join resolution. The custom field reconstruction step requires the customer's Dolibarr partner to implement PHP hooks in Dolibarr, which runs in parallel with the data migration preparation.

Adjacent paths

Related migrations to explore

Ready when you are

Move from ERPNext.
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