Migrate from Sales ERP to Dolibarr ERP

Salesforce Account records map to Dolibarr llx_societe (Third Party) with client=1 for customer accounts and supplier=1 for vendor accounts. The Account Name becomes nom, Website maps to url, Phone maps to phone, and Address fields map to address, zip, town, country. Parent Account hierarchy in Salesforce maps to parent_id on llx_societe if Dolibarr's multi-company module is activated. We preserve the original Salesforce Account ID in a custom field ref_ext for audit traceability and for resolving any downstream cross-object references.

Salesforce Contact records map to Dolibarr llx_socpeople linked to a parent Third Party via fk_soc. LastName maps to lastname, FirstName to firstname, Email to email, Phone to phone, and Title to civilite (using Dolibarr's civilite lookup). The Account-Contact relationship resolves to fk_soc at migration time after the parent Third Party is created. Salesforce's Account Contact Relation object maps to multiple Contact records under a single Third Party in Dolibarr.

Salesforce Opportunity records require a design decision during scoping: open pipeline opportunities map to Dolibarr llx_propal (Commercial Proposal) with status=draft or status=open; won opportunities that require fulfillment map to llx_commande (Order). The Opportunity name becomes ref or label, Amount maps to amount, CloseDate maps to fin_validite (validity end date) on proposals, and Stage maps to a Dolibarr status field. Lost opportunities are migrated as closed proposals with status=0 (draft) and a note field capturing the loss reason. We flag this decision at scoping because it affects the CRM reporting structure in Dolibarr.

Salesforce Order records map to Dolibarr llx_commande with Order Number as ref, Account linked via fk_soc, and OrderStatus mapped to Dolibarr's statut field (draft, validated, approved, shipped, delivered, cancelled). Order effective dates map to date_creation and date_delivery. We flag when Salesforce OrderStatus includes values (e.g., Activated, In Progress) that have no direct Dolibarr equivalent and propose a status mapping table during scoping.

Salesforce Contract records map to Dolibarr llx_contrat linked to the Third Party via fk_soc. Contract Number becomes ref, Status maps to statut, StartDate and EndDate map to date_creation and date_fin_validite. Contract line items (if implemented via custom fields or a managed package) map to llx_contratdet rows. Renewal terms in Salesforce map to fk_contrat for renewal-linked contracts if Dolibarr's contracts module is configured with the renewal extension.

Salesforce Product2 records map to Dolibarr llx_product with product name as label, ProductCode as ref, and IsActive controlling the finished or stock status. The Salesforce IsActive flag maps to Dolibarr's finished=1 for sellable products. We validate that all products have a barcode or product code before import to avoid Dolibarr's unique constraint violations on the ref field.

Salesforce PricebookEntry records map to Dolibarr llx_product_price linked to the product via fk_product and optionally to a price level via fk_price_list. UnitPrice maps to price, CurrencyIsoCode maps to currency if Dolibarr's multi-currency module is activated, and IsActive determines whether the price row is included. Custom Price Books require explicit mapping during scoping because Dolibarr's price list structure differs from Salesforce's Pricebook model.

Salesforce Order Products (OrderItems) map to Dolibarr llx_commandedet lines linked to the parent Order via fk_commande and to the Product via fk_product. Quantity maps to qty, UnitPrice maps to unit price, and TotalLineAmount maps to total_ht. We resolve the product reference and price list at migration time before inserting lines. If Salesforce OrderItems reference a PricebookEntry that does not exist in the destination, we flag it for manual price list configuration.

Salesforce Case records map to Dolibarr llx_ticket (if the Ticket module is activated) or llx_actioncomm with type=action and label=ticket. Case Subject maps to subject, Description maps to note_private, Priority maps to priority, and Status maps to statut. The Contact on Case resolves to fk_socpeople after the Contact mapping is complete. Cases without an associated Contact link to the parent Third Party via fk_soc if no contact is available.

Salesforce User records map to Dolibarr llx_user by email match. Active Salesforce users become Dolibarr users with a mapped Profile (admin, sales agent, or readonly). Deactivated Salesforce users are not migrated by default to avoid license waste in Dolibarr. Owners without a matching Dolibarr user are held in a reconciliation queue for the customer's admin to provision before record import resumes.

Salesforce custom objects require a case-by-case migration design. If the custom object is simple (name, date, number fields), we create a Dolibarr extra fields definition on the equivalent standard object (Third Party, Contact, or Product) via Dolibarr's Extra fields module. For complex custom objects with lookup relationships, we design a custom MySQL table in the Dolibarr database with corresponding fk_* foreign keys and map records accordingly. This requires developer access to Dolibarr's database schema and is scoped as a separate configuration item during discovery.

Salesforce Attachment records linked to Accounts, Contacts, Opportunities, and Orders migrate as Dolibarr documents attached via the llx_element_element cross-reference table. Base64-encoded attachment Body from Salesforce decodes to a file stored in Dolibarr's documents directory, with the original filename preserved and the element_type and element_id linking to the parent record. We validate UTF-8 encoding and file size limits before insertion to avoid Dolibarr's document storage constraints.