ERP migration
Field-level mapping, validation, and rollback between Lead Commerce and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.
Lead Commerce
Source
Dolibarr ERP
Destination
Compatibility
10 of 12
objects map 1:1 between Lead Commerce and Dolibarr ERP.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Lead Commerce to Dolibarr is a migration from a closed-source cloud SaaS to a self-hosted open-source ERP. Lead Commerce consolidates order, inventory, and warehouse management for SMBs on a per-month flat-rate model, but its lack of a documented public export API and non-portable Custom Apps create specific extraction constraints that we navigate during scoping. Dolibarr uses a modular architecture where inventory, orders, and warehouse modules must be explicitly activated before data can be imported. We extract via Lead Commerce's available CSV export mechanism or, for large catalogs, through a customer-authorized database query, then stage the data for Dolibarr's built-in import wizard or direct SQL load. Open purchase orders and in-flight customer orders at the cutover date require a manual reconciliation step because Lead Commerce does not expose a real-time export during the migration window. Custom Apps built on Lead Commerce's framework carry no documented migration path and are flagged separately for manual rebuild at the destination. Workflows, saved reports, and analytics snapshots do not migrate; we deliver a written inventory for the customer's team to rebuild in Dolibarr.
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 Lead Commerce 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.
Lead Commerce
Order
Dolibarr ERP
Order (Commande client)
1:1Lead Commerce order records with fulfillment status (pending, processing, shipped, completed) map to Dolibarr's Order (Facture/Avoir) object depending on invoice status. We separate fulfilled orders (mapped to Dolibarr Invoice) from open orders (mapped to Dolibarr Order) during the pre-import transform. Order dates, customer reference, line items, and shipping address migrate as-is. We flag any orders with null or malformed line items for customer review before import.
Lead Commerce
Inventory Item
Dolibarr ERP
Product (Produit)
1:1Lead Commerce inventory items with SKU, stock levels, and unit cost map to Dolibarr Product2 records. We create Dolibarr Product entries with ref (from SKU), label, description, price, and cost price fields populated. Items with zero or negative quantities that may indicate data quality issues are flagged in the pre-import validation report. Stock levels per warehouse are migrated to Dolibarr's Warehouse Stock module after warehouse records are established.
Lead Commerce
Warehouse Location
Dolibarr ERP
Warehouse (Entrepôt)
1:1Lead Commerce warehouse records map directly to Dolibarr Warehouse. Each warehouse record carries a name, address, and description that migrates as-is. We validate that the destination Dolibarr instance has the Warehouse module activated before import, as this module is not enabled by default in a standard installation. Multi-warehouse configurations from Lead Commerce transfer as separate Dolibarr warehouse records with stock levels linked via product-warehouse associations.
Lead Commerce
Customer
Dolibarr ERP
Third Party (Tiers)
1:1Lead Commerce customer records (name, email, phone, address, company) map to Dolibarr Third Party records. We deduplicate by email during the import transform and preserve the customer-to-order linkage so that historical order context attaches to the correct Third Party in Dolibarr. Lead Commerce customers that include a company name are created as Dolibarr Organizations; sole-contact records are created as Dolibarr Contacts linked to the Third Party.
Lead Commerce
Purchase Order
Dolibarr ERP
Supplier Order (Commande fournisseur)
1:1Lead Commerce purchase order records map to Dolibarr Supplier Orders. We separate received lines from open lines during pre-import: received lines represent landed inventory that we map to stock entries against the relevant warehouse; open lines represent supply commitments that become open supplier order lines in Dolibarr. The supplier contact referenced on each PO must exist as a Dolibarr Third Party before PO import begins, so we sequence supplier data first.
Lead Commerce
User
Dolibarr ERP
User
1:1Lead Commerce user accounts and role assignments export as a flat list. We map role names from Lead Commerce to Dolibarr permission groups. The destination Dolibarr instance requires users to be created manually by the admin (Dolibarr does not have a programmatic user provisioning API at the Community edition level), so we provide a user import CSV with the correct Dolibarr field mapping that the customer's admin can import via the Tools > Users import wizard.
Lead Commerce
Custom App data
Dolibarr ERP
ExtraFields (Champs extras)
lossyIf Lead Commerce custom apps store structured data in the Lead Commerce database, we identify those data tables during discovery and map them to Dolibarr ExtraFields where the data fits within existing objects. The custom app logic itself (PHP code, workflows, UI extensions) has no migration path and is flagged in the non-migratable inventory. Any custom app data that does not fit the Dolibarr schema is documented as a separate data export for manual re-entry or a custom Dolibarr module build.
Lead Commerce
Order Line Item
Dolibarr ERP
Order Line
1:1Lead Commerce order line items (product reference, quantity, unit price, discount) map to Dolibarr Commandedet lines. We resolve the product reference against the migrated Product records before order import begins. If a Lead Commerce order line references a product that did not migrate (deleted or inactive at source), we create a placeholder product record in Dolibarr and flag it for the customer to resolve post-migration.
Lead Commerce
Reporting Data
Dolibarr ERP
Not migratable
1:1Lead Commerce does not expose a documented export for saved reports or historical analytics snapshots. We do not migrate reporting data. As part of the pre-migration checklist, we direct the customer's team to export key reports as PDF before the cutover date. In Dolibarr, the reporting module (if activated) and Dolistore analytics addons provide a fresh reporting environment. We deliver a written inventory of every saved Lead Commerce report with its parameters as a reference for rebuilding in Dolibarr.
Lead Commerce
Custom Apps (application code)
Dolibarr ERP
Not migratable
1:1Lead Commerce's Custom Apps framework produces application code that is non-portable by design. The application logic, UI extensions, and any custom business rules built in Lead Commerce cannot be extracted or transferred to Dolibarr. We document any custom app data that lives in Lead Commerce's database separately, flag the associated data export for customer review, and note that the application logic must be rebuilt as a Dolibarr module or Dolistore addon as a separate engagement.
Lead Commerce
Supplier (from Purchase Orders)
Dolibarr ERP
Third Party (type Fournisseur)
1:1Lead Commerce supplier records referenced on purchase orders map to Dolibarr Third Party records of type Supplier. We deduplicate by supplier email or name during the transform. Supplier contact details (name, email, phone, address) migrate to Dolibarr's supplier contact card. The Dolibarr CRM module must be active to create supplier records with contact associations.
Lead Commerce
Inventory stock per warehouse
Dolibarr ERP
Stock (Mouvement de stock)
lossyLead Commerce stores per-warehouse stock levels on inventory items. We migrate these as Dolibarr stock movements of type 'import' linked to the relevant warehouse and product. Each stock level entry records the product, warehouse, quantity, and a migration timestamp. We validate that Dolibarr's Warehouse module and Stock module are both active before this phase and that the warehouse records exist in Dolibarr to satisfy the foreign key relationship.
| Lead Commerce | Dolibarr ERP | Compatibility | |
|---|---|---|---|
| Order | Order (Commande client)1:1 | Fully supported | |
| Inventory Item | Product (Produit)1:1 | Fully supported | |
| Warehouse Location | Warehouse (Entrepôt)1:1 | Fully supported | |
| Customer | Third Party (Tiers)1:1 | Fully supported | |
| Purchase Order | Supplier Order (Commande fournisseur)1:1 | Fully supported | |
| User | User1:1 | Fully supported | |
| Custom App data | ExtraFields (Champs extras)lossy | Fully supported | |
| Order Line Item | Order Line1:1 | Fully supported | |
| Reporting Data | Not migratable1:1 | Not supported | |
| Custom Apps (application code) | Not migratable1:1 | Fully supported | |
| Supplier (from Purchase Orders) | Third Party (type Fournisseur)1:1 | Fully supported | |
| Inventory stock per warehouse | Stock (Mouvement de stock)lossy | 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.
Lead Commerce gotchas
No public API documentation for programmatic export
Custom Apps carry non-portable business logic
Open orders must be manually reconciled at cutover
Reporting snapshots are not exportable
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 export method confirmation
We audit the Lead Commerce account to establish record counts across Orders, Inventory Items, Warehouses, Customers, Purchase Orders, and user accounts. We assess which export methods are available (application CSV export, custom script, or database query). We confirm Dolibarr's target environment (self-hosted, DoliCloud, or VPS) and identify which modules need activation. The discovery output is a written migration scope with confirmed export method, record counts per object, and a module activation checklist for the Dolibarr instance.
Schema design and module activation plan
We design the Dolibarr target schema based on the export method confirmation. This includes activating the Warehouse, Stock, Products, Orders, Suppliers, and CRM modules in Dolibarr before any data arrives. We design the Third Party import order (suppliers first, then customers) to satisfy foreign key dependencies. We document the custom field mapping for Lead Commerce inventory items to Dolibarr Product fields, warehouse stock to Dolibarr stock movements, and order lifecycle status to Dolibarr Order status values. Custom app data is documented as a separate schema map for the rebuild team.
Data extraction and pre-import validation
We extract data from Lead Commerce using the confirmed export method. We validate the CSV output for completeness, check for duplicate records, missing required fields, and malformed values. We flag inventory items with zero or negative quantities, customers without email addresses, and orders without line items. We resolve Lead Commerce warehouse IDs against the warehouse name list. The validation output is a pre-import data quality report that the customer reviews and approves before we proceed to the import phase.
Sandbox migration and reconciliation
We run a full migration into a Dolibarr staging environment (a copy of the target instance or a fresh DoliCloud trial) using production-like data volume. The customer reconciles record counts and spot-checks 25-50 records per object against the Lead Commerce source. We test the Third Party-to-Order linkage, product stock entries per warehouse, and supplier order associations. The customer signs off the mapping and data quality before production migration begins. Any corrections to the import transform happen at this stage.
Production migration in dependency order
We run production migration in record-dependency order: Warehouse records first, then Third Parties (suppliers followed by customers), then Products with stock entries per warehouse, then Purchase Orders, then Customer Orders with line items resolved against products, and finally user accounts via the Dolibarr import wizard. Each phase emits a row-count reconciliation report before the next phase begins. Any records rejected during import (due to validation rules or missing dependencies) are logged to a fix queue for resolution before retry.
Cutover, delta sync, and non-migratable handoff
We freeze Lead Commerce writes during cutover and run a final delta migration of any records modified or created during the migration window. We enable Dolibarr as the system of record and confirm the customer can log in and view the migrated data. We deliver the non-migratable inventory: a written document listing saved reports requiring rebuild, Custom App data that requires manual re-entry, and Custom App logic that requires a separate Dolibarr module build. We support a one-week hypercare window for reconciliation issues. We do not rebuild Lead Commerce workflows, reports, or Custom Apps as part of the migration scope.
Platform deep dives
Lead Commerce
Source
Strengths
Weaknesses
Dolibarr 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 Lead Commerce and Dolibarr 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
Lead Commerce: Not publicly documented.
Data volume sensitivity
Lead Commerce 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 Lead Commerce to Dolibarr ERP migration scoping. Not seeing yours? Book a call.
Walk through your Lead Commerce 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 Lead Commerce
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.