Migrate from Expandable ERP to Dolibarr ERP

Expandable's Part Master maps to Dolibarr Product records. We extract part number, description, revision, unit of measure, lot/serial tracking flags, and part parameters via SQL from the Expandable database. Revision history is preserved as custom text fields rev_history__c (last revision) and rev_list__c (comma-separated revision chain) since Dolibarr Products are not revision-controlled objects. User-defined fields from Expandable's QBE exports migrate to Dolibarr extrafields on the Product object. Part status (active, inactive, discontinued) maps to the Dolibarr To purchase / To sell / To produce checkbox set.

Expandable BOMs are multi-level versioned structures linked to Part revisions via ECO effective dates. Dolibarr BOMs are recipe-style single-level structures stored per Product without native multi-level assembly or revision tracking. Single-level BOMs migrate directly to Dolibarr BOM records with the parent part as the finished product and sub-assembly lines as BOM lines. Multi-level BOMs require flattening (we collapse sub-assemblies to top-level lines) or a third-party Dolibarr module like MRP Extended; we scope this during discovery and advise the customer before migration. BOM revision sequencing is handled by loading parts first, then BOMs in reverse-indent order, with each BOM revision mapped to a separate Dolibarr BOM record with an activated/disabled status toggle.

Expandable Sales Order headers map to Dolibarr Customer Order records, preserving order date, customer reference, payment terms, and order total. Line items migrate with product reference (resolved to Dolibarr Product ID), quantity, unit price, and discount. Order status transitions (Quoted, Booked, Shipped, Closed) map to Dolibarr Status values. Open orders migrate at full fidelity; historical closed orders migrate with their line item history preserved as order history lines rather than active inventory reservations.

Expandable PO headers map to Dolibarr Supplier Order records, preserving vendor assignment, PO date, payment terms, and total. Line items migrate with vendor part number cross-reference, quantity ordered, unit cost, and expected delivery date. Partial receipts and multi-vendor scenarios are preserved: we load receipt records as Dolibarr Reception lines linked to the supplier order, maintaining the receipt-to-PO relationship that Expandable tracks natively.

Expandable's Lot Master maps to Dolibarr Stock records with lot number, warehouse location, on-hand quantity, and lot expiry date. Serial number traceability records migrate to Dolibarr as lot-level stock movement entries tracking receipt date, supplier, and current location. Multiple warehouses in Expandable map to Dolibarr multi-warehouse Stock entities, preserving location-specific quantities. On-hand quantities are reconciled against open sales and purchase order reservations before migration to avoid negative stock at go-live.

Expandable GL journal entries map to Dolibarr Accounting entries, preserving account number, debit/credit amount, entry date, and source reference. Expandable does not generate financial statements natively (it uses Crystal Reports), so we extract raw subledger transaction data — AR invoices, AP vouchers, inventory movements, and bank transactions — to enable financial reconstruction in Dolibarr's basic accounting module. Dolibarr does not support cost centers, inter-company consolidation, or multi-currency ledgers in its standard accounting module; we flag these gaps early and advise the customer on whether a third-party Dolibarr accounting add-on or a separate financial reporting tool is needed for their reporting obligations.

Expandable Quality Events carry FDA-relevant compliance metadata — event severity, root cause classification, corrective action status, and lot/part/supplier linkages — required in med-tech environments under FDA 21 CFR Part 820. Dolibarr has no native quality module. We map Quality Events to Dolibarr Product and Stock extrafields (quality_event_id__c, severity__c, root_cause__c, corrective_action__c, event_date__c) and preserve the lot-part-supplier linkage in a companion Dolibarr third-party extrafield. This preserves the structured event data in searchable custom fields rather than flattening it to plain notes. If the customer's quality requirements are strict (ISO 13485, FDA 21 CFR Part 820), we recommend a dedicated quality management add-on module for Dolibarr or a parallel QMS during migration scoping.

Expandable ECO and ECM records track revision-controlled changes to parts and BOMs with effective dates and affected BOM levels. Dolibarr has no native ECO or ECM equivalent. We extract ECO records and map them to Dolibarr BOM extrafields (eco_number__c, eco_status__c, effective_date__c, affected_levels__c) and store the full ECO change description in a text extrafield. The ECO-to-part revision linkage is preserved via the part revision mapping already described. Any downstream BOM changes triggered by an ECO are tracked manually by the customer's admin using the ECO inventory document we deliver post-migration.

Expandable role-based security with Advanced Security features maps to Dolibarr Users and Permission profiles. We extract the user-to-role mapping table from Expandable's SQL database and map it to Dolibarr's users, groups, and rights matrix. Expandable users without a clear Dolibarr equivalent receive a written user-role mapping table for the customer's admin to configure post-migration. Active/inactive status, email addresses, and default warehouse assignments migrate directly.

Expandable stores document references and link paths but does not have a native document management engine. Dolibarr has a document management module that stores files linked to records, but binary attachment migration is out of scope because file paths in Expandable may reference network drives, SharePoint, or local storage that is not accessible from the Dolibarr hosting environment. We export a document inventory list mapping each Expandable document link to its record context and advise the customer to manually migrate or re-attach files post-go-live.

Expandable does not natively handle RMA or CAPA workflows; some customers run third-party standalone RMA/CAPA tools integrated via EDI or API. Dolibarr has no native RMA or CAPA module. If RMA/CAPA data lives in a standalone tool integrated with Expandable, we treat it as a separate migration workstream and scope it independently. If it lives only in Expandable as notes or custom records, we extract what we can find and deliver it as a structured CSV inventory for the customer to import into a dedicated RMA add-on or alternative tool post-migration.

Expandable customer and vendor records map to Dolibarr Third-Party entities with the IsCustomer and IsSupplier flags set respectively. Customer address, contact name, phone, email, payment terms, and tax ID migrate to Dolibarr extrafields where the native fields do not cover Expandable's data model. Customer-specific pricing tiers and credit limits from Expandable's vendor/customer masters migrate to Dolibarr's price negotiation and credit limit fields.