ERP migration
Field-level mapping, validation, and rollback between ERPNext and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.
ERPNext
Source
Dolibarr ERP
Destination
Compatibility
12 of 14
objects map 1:1 between ERPNext and Dolibarr ERP.
Complexity
BStandard
Timeline
3-5 weeks
Overview
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.
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 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
Dolibarr ERP
Third-Party (Type: Customer)
1:1ERPNext 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
Dolibarr ERP
Third-Party (Type: Supplier)
1:1ERPNext 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
Dolibarr ERP
Product or Service
1:1ERPNext 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)
Dolibarr ERP
Product (BOM tab) + Custom Configuration Record
lossyERPNext'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
Dolibarr ERP
Order
1:1ERPNext 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
Dolibarr ERP
Supplier Order
1:1ERPNext 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
Dolibarr ERP
Invoice (Customer)
1:1ERPNext 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
Dolibarr ERP
Invoice (Supplier)
1:1ERPNext 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
Dolibarr ERP
Payment
1:1ERPNext 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
Dolibarr ERP
Project
1:1ERPNext 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
Dolibarr ERP
User (with HR module)
1:1ERPNext 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
Dolibarr ERP
Stock Movement
1:1ERPNext 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
Dolibarr ERP
CustomFields
lossyERPNext 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
Dolibarr ERP
Document
1:1ERPNext 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.
| ERPNext | Dolibarr ERP | Compatibility | |
|---|---|---|---|
| Customer | Third-Party (Type: Customer)1:1 | Fully supported | |
| Supplier | Third-Party (Type: Supplier)1:1 | Fully supported | |
| Item | Product or Service1:1 | Fully supported | |
| BOM (Bill of Materials) | Product (BOM tab) + Custom Configuration Recordlossy | Fully supported | |
| Sales Order | Order1:1 | Fully supported | |
| Purchase Order | Supplier Order1:1 | Fully supported | |
| Sales Invoice | Invoice (Customer)1:1 | Fully supported | |
| Purchase Invoice | Invoice (Supplier)1:1 | Fully supported | |
| Payment Entry | Payment1:1 | Fully supported | |
| Project | Project1:1 | Fully supported | |
| Employee | User (with HR module)1:1 | Fully supported | |
| Stock Entry | Stock Movement1:1 | Fully supported | |
| Custom Fields | CustomFieldslossy | Mapping required | |
| File / Attachment | Document1:1 | Fully supported |
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.
ERPNext gotchas
CSV import does not detect or prevent duplicate records
Custom server scripts break silently on version upgrades
BOM routing and workstation data requires manual reconstruction
Payment ledger entries in v14+ are decoupled from invoices
Frappe rate limiting is configurable per-site and undocumented
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 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).
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.
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.
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.
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.
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
ERPNext
Source
Strengths
Weaknesses
Dolibarr ERP
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. All 8 core objects map 1:1 between ERPNext and Dolibarr ERP.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across ERPNext and Dolibarr ERP.
Object compatibility
All 8 core objects map 1:1 between ERPNext 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
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
ERPNext 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 ERPNext to Dolibarr ERP migration scoping. Not seeing yours? Book a call.
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 consultationAdjacent paths
Other ways to leave ERPNext
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.