Migrate from WP ERP to Dolibarr ERP

WP ERP employee records in erp_hr_employees include personal details, employment status, department, job title, hire date, compensation, and WordPress user ID (wp_user_id). We extract all fields and create Dolibarr Third Party records of type Contact for each employee, with the resource table (llx_resource) activated if the HR module is enabled in Dolibarr. The wp_user_id cross-reference is resolved by matching against the WordPress user email for identity confirmation before Dolibarr User provisioning.

Department records in erp_hr_departments are straightforward key-value structures with parent-child hierarchy (parent_id). We migrate the department tree as a top-down structure, creating Dolibarr categories or using a custom llx_c_departments lookup depending on which HR module variant the customer deployed. Employees are reattached to the correct department ID on the destination by resolving the department_id foreign key during the employee import phase.

CRM contacts in erp_crm_contacts include name, email, phone, address, social profiles, lifecycle stage, source attribution, and a wp_user_id link. We extract all standard fields and map lifecycle_stage to a custom contact attribute in Dolibarr. If WooCommerce CRM integration is active, we detect contacts created by WooCommerce orders and flag duplicate candidates against manually created CRM contacts for customer-directed merge before export.

Company records in erp_crm_companies are linked to contacts via erp_crm_contact_relations. We preserve the association mapping during migration, creating Dolibarr Company (llx_societe with typent_code=2) records before contact import so that the llx_socpeople.fk_soc foreign key is satisfied at insert time. Company address, phone, email, website, and industry classification map to Dolibarr's corresponding societe fields.

The cross-reference table erp_crm_contact_relations defines which contacts belong to which companies. We resolve this relationship by first creating all llx_societe (Company) records, then inserting llx_socpeople (Contact) records with fk_soc pointing to the resolved Company ID. This ensures the Contact-Company relationship is intact in Dolibarr's commercial module from the first import phase.

Activities (calls, meetings, emails, tasks) are stored in erp_crm_activities with polymorphic type fields distinguishing the activity type. We flatten them into Dolibarr's llx_actioncomm (agenda events) with the activity type mapped to actioncomm.type_code (AC_TEL for calls, AC_MT for meetings, AC_EMAIL for emails, AC_TASK for tasks). Notes attached to contacts or companies migrate as llx_c_actioncomm entries linked to the parent llx_socpeople or llx_societe record.

Accounting chart of accounts records in erp_ac_chart_of_accounts include account code, name, type, subtype, and parent-child grouping. We preserve the full account structure including parent-child relationships for grouped accounts, mapping account type to Dolibarr's PCG type system (ACTIVA, PASSIVA, CHARGE, PRODUIT). The account codes are preserved verbatim to maintain compatibility with any existing financial reports or auditor references.

Accounting customers in erp_ac_customers link to CRM contacts via erp_crm_contacts.id. We resolve the cross-reference during migration so invoices land against the correct llx_societe record in Dolibarr. The customer accountancy code maps to llx_societe.accountancy_code_customer for tax reporting and audit trail.

Vendor records in erp_ac_vendors are migrated with their billing address, company name, and contact email. The vendor type is set in Dolibarr as typent_code=4 (Supplier). Vendor-ledger entries are linked via vendor_id foreign key in the purchase journal migration phase.

Invoices in erp_ac_invoices include line items, tax codes, payment status, and due dates. We flag open invoices versus paid or voided invoices using the status field and map invoice status to Dolibarr's facture status (Validated, Paid, Abandoned). Line items migrate as llx_facturedet records with product references resolved to Dolibarr product IDs or simple label lines if no product match exists.

Manual journal entries stored in erp_ac_journal_entries are migrated with debit/credit line items and the COA account mapping. We insert records into llx_accounting_bookkeeping (the direct accounting entry table) with proper debit/credit amounts and account references. Automated journal entries generated by the Payroll module migrate as standard journal lines with a payroll origin flag for audit purposes.

Inventory items from the WP ERP Inventory extension include item name, SKU, unit cost, current stock quantity, and reorder level. We migrate llx_product records (product type = 0 for stockable) with stock levels into llx_product_stock. Stock movement history migrates as a separate transaction log (llx_stock_mouvement) because most destination systems store movement history separately from current stock levels.

Document Manager files stored in the WordPress media library or custom uploads directory are exported as binary files and re-uploaded to Dolibarr's documents directory, associated with the relevant entity (contact, company, invoice) via Dolibarr's document management linking. We export file metadata from the wp_posts table filtered by post_type and re-create the directory structure in Dolibarr.

Historical payroll records from the WP ERP Payroll extension ($9.49/mo) include payslips, tax withholdings, and bank transfer data stored in erp_hr_payroll tables. We migrate payslip headers and line items as Dolibarr salary payment records (llx_payment_salary) with a note that payslip PDFs require regeneration on the destination system or archival as PDF files for compliance. The customer confirms before migration whether regeneration or archive is the preferred compliance approach.