Migrate from EBMS to Dolibarr ERP

EBMS Customers (stored as Documents within a Customers table) map to Dolibarr ThirdParty records. Standard fields — company name, billing address, shipping address, contact name, phone, email, payment terms — export via the Customer Address for Mail Merge report. Custom fields added via EBMS Customization Designer require SQL enumeration during data profiling and map to Dolibarr Extrafields columns on the ThirdParty object. We enable Dolibarr's ThirdParty module with the IsCustomer flag set on all migrated records. Vendor and Customer records in EBMS may share the same table with a type flag; we split them into separate ThirdParty imports with the appropriate IsCustomer or IsSupplier flag.

EBMS Vendors export via vendor reports and map to Dolibarr ThirdParty records with IsSupplier flag set. Purchasing terms (NET 30, NET 60, prepayment) map to the Dolibarr supplier payment term fields. Custom fields on vendor records require explicit mapping to Dolibarr Extrafields on the ThirdParty object with supplier type. If EBMS stores vendor contacts separately from vendor header records, we flatten them into a single ThirdParty with the primary contact data in the header and additional contacts loaded as Dolibarr contacts linked via the Contact object.

EBMS Products defined in the inventory module — with pricing, stock levels, units of measure, and serial numbers — export via inventory reports and map to Dolibarr Product records. We map the EBMS product type (stockable, service, assembly) to Dolibarr's pcmof_prod_type field. Product photos migrate as files attached to the Dolibarr Product record. If EBMS uses multi-level product variants or Bill of Materials assemblies, we map to Dolibarr's Product with the BOM module enabled; otherwise flat product records import directly. Price levels (price tiers per customer type) in EBMS map to Dolibarr Customer Specific Prices or a price list configuration.

EBMS Sales Order headers and line items export via order reports. The EBMS order status (Open, Closed, Cancelled) maps to Dolibarr ORDER_CLASSIFIED_* status values. Line items resolve the product reference to Dolibarr Product IDs at migration time using a lookup table built from the product import phase. Unit price, quantity, discount percentage, and tax rate migrate directly. Payment terms on the order header pull from the linked Customer's terms. We preserve the original EBMS order number as a custom field on the Dolibarr Order for invoice reconciliation.

EBMS Purchase Orders export via PO reports and map to Dolibarr Supplier Order records. Custom fields on PO headers or line items (added via EBMS Customization Designer) require explicit mapping to Dolibarr Extrafields on the supplier order and order line objects. The vendor reference on the EBMS PO resolves to the Dolibarr ThirdParty supplier ID via the vendor mapping phase. EBMS PO statuses (Open, Received, Closed) map to Dolibarr RECEIVED, DRAFT, and CANCELLED status values.

EBMS Invoices (open and historical) export via AR aging and invoice reports. We scope invoice exports by a defined date range to avoid mid-period splits between EBMS and Dolibarr. Invoice header fields (invoice number, date, due date, amount, balance) map to Dolibarr Facture fields. Invoice lines map to FactureLigne with product reference resolution via the product lookup table. Payment history — partial payments, credit memos — requires exporting payment records separately and applying them as Dolibarr payments linked to the invoice. Historical paid invoices migrate with status FACTURE_PAYED; open invoices retain FACTURE_OPEN.

EBMS B2B Customer Portal accounts store price levels, payment terms, and login credentials for customer-facing self-service. Dolibarr does not have a native B2B portal module in its core distribution — the Dolibarr member module serves NGOs and associations but not B2B eCommerce portals. We migrate portal account data as ThirdParty records with price level assignments stored as Dolibarr Customer Specific Prices on the Product object. If the customer uses portal-specific custom fields, we map them to Extrafields on ThirdParty and document the portal rebuild as a separate implementation task for a Dolibarr partner.

EBMS eCommerce tiers synchronize product availability, pricing, photos, and descriptions from the inventory module to the customer-facing website. We export the product data via EBMS inventory reports, preserving all eCommerce-specific fields (long description, product images, category assignments) and load them into Dolibarr Product records. The eCommerce storefront itself does not migrate — Dolibarr has no native storefront module, and WooCommerce, Shopify, or Magento connectors exist as separate integrations. We deliver the product data in Dolibarr's import-ready format so the customer's web team can re-connect to their chosen storefront post-migration.

EBMS Customization Designer fields added to Customer, Product, Order, Invoice, or Vendor documents require SQL-level enumeration during data profiling since not all custom fields appear in the standard report writer without first adding them to the report layout. We request read-only SQL access to the EBMS database to discover every custom field column, its data type, and the table it belongs on. Each discovered custom field maps to a Dolibarr Extrafields column on the equivalent Dolibarr object. We create the Extrafields schema in Dolibarr before the data import phase begins. Fields created by customization developers whose definitions cannot be edited in the EBMS UI require special handling — we map them by their database column name where a matching Dolibarr field can be created.

EBMS stores contact-level information (first name, last name, email, phone, job title) on Customer records and occasionally as separate contact entries linked to customers. Dolibarr uses a dedicated Contact object linked to a ThirdParty via the socid foreign key. We export EBMS contact data from the customer report and load into Dolibarr Contact records with the ThirdParty lookup resolved from the customer mapping phase. Primary contact designation migrates as the contact with the IsPrimary flag set on the Dolibarr Contact.

EBMS tracks which sales representative or user created or owns each order, quote, or customer record. We extract distinct owner values from EBMS reports and match them by name or email to existing Dolibarr User records. If the destination Dolibarr instance has no matching User, we flag the owner as unmapped and hold those records for the customer to provision the User before the migration resumes. User provisioning is a manual step that the customer's Dolibarr admin completes outside the migration workflow.

EBMS Report definitions are a configuration artifact of the EBMS report writer, not a data object. We export the data that EBMS reports reference — Customers, Products, Orders, Invoices — but the report layout definitions, grouping logic, calculated fields, and print templates do not migrate. Dolibarr's reporting module (on the ThirdParty, Product, and Stock modules) provides standard report generation for basic needs. The customer or a Dolibarr-certified consultant rebuilds custom reports in Dolibarr's report writer. We document every EBMS report used in the migration export as part of the data mapping inventory.