Migrate from Dolibarr ERP to Microsoft Dynamics 365 Business Central

Dolibarr's llx_societe table holds customers, prospects, and suppliers in one entity with a client/prospect/supplier type flag. We split this into Dynamics 365 Account records (the company and commercial entity) and Contact records (the individuals). The type flag maps to Account.accounttype or a custom field, and individual contact details from llx_socpeople link to the Account via a Contact relationship. Deduplication uses the siret/siren code if populated, falling back to email domain or company name match.

Dolibarr contacts stored in llx_socpeople map to Dynamics 365 Contact records. The fk_soc foreign key links each contact to the parent Account. We preserve email, phone, job title, address fields, and country, and map the active/inactive status from Dolibarr's statut field to the Contact statecode in Dataverse.

Dolibarr products (type=0) and services (type=1) both map to Dynamics 365 Product records. The product's sell price, buy price, VAT rate, unit, and stock quantity migrate as product attributes. We create product records as Inactive initially, then activate after pricing is confirmed against the destination price book. Product stock levels in llx_product_stock map to warehouse inventory in Dynamics 365.

Dolibarr proposals map to Microsoft Dynamics 365 Sales Quote. The proposal status (draft, open, signed, refused, closed) maps to the Quote statuscode field. Quote lines reference product IDs resolved against the migrated product catalog. The validity date and total amounts migrate as typed currency fields, and the commercial terms or notes become the Quote description field.

Dolibarr customer orders map to Microsoft Dynamics 365 Sales Order or a Business Central Sales Document depending on the destination module. The order status (draft, validated, shipped, delivered, cancelled) maps to the destination status lifecycle. Order lines reference migrated products with quantity, unit price, and discount preserved. If Dolibarr's warehouse module is active, we map the source warehouse to the destination location on the order line.

Invoice migration is the most complex object in this pair. Open Dolibarr invoices (not paid) migrate as open Sales Invoice records in Dynamics 365, preserving the original invoice number, date, due date, and line items with product, quantity, and price. Closed invoices (paid) generate General Journal Entry records for the posted amounts, with the payment records (llx_paiement and llx_paiement_facture) migrated as customer payments applied to the corresponding invoice. We flag any invoice with a mismatched total before import to prevent posting errors.

Dolibarr bank accounts and transactions in llx_bank map to Dynamics 365 Bank Account records and ledger entries. The reconciliation state from Dolibarr (reconciled flag) is preserved as a written note alongside each transaction so that the customer's accountant can re-reconcile in Dynamics 365 without losing audit context. Multi-bank-account setups are each imported as a separate Bank Account entity.

Dolibarr projects map to Dynamics 365 Project records or Business Central Projects depending on the destination module. Project status, description, budget amounts, and start/end dates migrate directly. We link project tasks from llx_projet_task as sub-records under the parent Project, preserving task assignees and time budget references from the task table.

Dolibarr project tasks migrate as Project Task records under the corresponding Dynamics 365 Project. Task assignees resolve by email against migrated user accounts. Time budget fields migrate as typed decimal values, and the task status maps to the destination project task statuscode.

Dolibarr calendar events in llx_actioncomm map to Dynamics 365 Activities: meetings become Appointments with start and end times preserved, tasks become Task records with the original Dolibarr date and assignee, and calls become Task records with TaskSubtype set to Call. Attendee lists from llx_actioncomm_resources link as Party records on the destination Activity. Recurring event rules are not migrated; we flag them in the handoff document for manual recreation in Dynamics 365.

Stock levels in llx_product_stock map to Dynamics 365 warehouse inventory records. Warehouse locations from llx_entrepot map to Locations on the Inventory. Stock movement history in llx_stock_mouvement migrates as inventory posting records with transaction dates preserved. We apply the correct decimal precision for quantities during import to avoid silent rounding in unit-of-measure conversions.

Dolibarr user accounts migrate as Dynamics 365 User records with metadata (first name, last name, email, role) preserved. Password hashes (bcrypt-salted) do not migrate and are not usable at the destination. The customer's Dynamics 365 admin provisions the new users and distributes credentials post-migration. Active and inactive status from Dolibarr maps to the User.isactive flag; the admin confirms which inactive users should be provisioned as active in Dynamics 365.

Any custom fields added via Dolibarr's extrafields system are serialized as JSON in the extraoptions column on the parent table. We deserialize each object's extraoptions at migration time, map the deserialized key-value pairs to typed Dynamics 365 custom fields, and apply those values to each record. Lookup-type extrafields that reference other Dolibarr records require resolution against the migrated IDs of the target object before the custom field value is written.