Migrate your Dolibarr ERP data

Dolibarr's core contact entity stores contacts, companies, and suppliers in the same llx_societe and llx_socpeople tables. All standard fields (name, email, phone, address, country) are available and export cleanly via the predefined export profile.

Products and services are separate object types in llx_product with type=0 for products and type=1 for services. Pricing fields, stock levels, and VAT rates export correctly; custom fields on products are stored in extraoptions and require JSON deserialization.

Proposals live in llx_proposal and link to third parties and lines. Status codes (draft, validated, signed, refused) are integer values that must be mapped to the destination system's lifecycle states.

Orders are in llx_commande with a similar structure to proposals. Order lines reference product/service IDs that must be preserved or remapped if product catalog is not migrated in the same job.

Invoices (llx_facture) include complex relationships: lines, payments (llx_paiement), payment-to-invoice links (llx_paiement_facture), and bank transaction references. We preserve all relationships and flag any unreconciled open invoices for manual review.

Bank accounts and their transaction rows (llx_bank) are migratable but Dolibarr's reconciliation state depends on matching payment records. We export all transactions with their reconciliation flags and leave unmatched items visible for post-migration cleanup.

Projects (llx_projet) and tasks (llx_projet_task) export cleanly. Task assignees and time budgets are stored in separate tables and are included in the migration scope.

Calendar events in llx_actioncomm export with date, owner, and linked objects. Recurring event rules and third-party associations are preserved; fullcal integration metadata is not migrated.

Stock levels in llx_product_stock are migrated alongside product records. Warehouse locations (llx_entrepot) and stock movement history (llx_stock_mouvement) require separate export profiles and careful sequencing to avoid negative stock alerts.

User accounts (llx_user) and permission profiles (llx_rights_def) are available but password hashes are salted bcrypt — we migrate user metadata and leave passwords to be reset at destination. Active vs. disabled status is preserved.

Any custom fields added via Dolibarr's extrafields system are stored as JSON in an extraoptions column on the parent table. We deserialize each object's extraoptions and write them as native custom properties at the destination. We flag any field-type limitations (file attachments stored as paths, not data) upfront.

Dolibarr attachments are stored as files on the filesystem with references in llx_document. We do not migrate binary file attachments as part of the standard migration scope; we export the file path references and provide a file-copy script for post-migration synchronization.

HR modules including leave requests (llx_holiday) and expense reports (llx_deplacement) are available if enabled. These are migrated with effective-dated rows and approval status flags, but HR-specific permission sets require manual reconfiguration at destination.