Migrate from Ridder iQ to Dolibarr ERP

Ridder iQ customer and prospect records map to Dolibarr ThirdParty with the Customer category. We preserve the customer name, address, contact email, phone, payment terms, and any credit limit data. Ridder iQ's CRM-linked Outlook integration notes are not carried as Dolibarr does not have a native Outlook sync feature; we document the contact sync gap for the customer's admin to evaluate a third-party add-on or manual reconnection post-migration.

Ridder iQ supplier master records map to Dolibarr ThirdParty with the Supplier category. We preserve supplier name, address, contact email, phone, payment terms, and lead time data in the corresponding Dolibarr ThirdParty fields. Associated purchase history line items migrate as read-only supplier invoice records in Dolibarr's Accounting module.

Ridder iQ Items (raw materials, components, finished goods) map to Dolibarr Product records. Unit-of-measure, cost price, and selling price migrate to Dolibarr's price fields. Supplier-linked items carry the supplier reference as a Dolibarr supplier barcode or product supplier link record. Multi-UOM items are flagged during discovery because Dolibarr supports only one default UOM per product; secondary UOMs require the MultiUOM add-on or manual unit conversion at migration time.

Ridder iQ multi-level BOMs map to Dolibarr Product BOM entries. Each BOM component is entered as a child Product linked to the parent Product BOM. We handle the single-level flat BOM import via Dolibarr's BOM module. Multi-level BOMs are flattened to the first level in the standard import; second-level BOM expansion is documented as a manual step or configured as phantom assemblies in Dolibarr. Any items with more than one active BOM variant (Ridder iQ's make-or-buy flexibility) are flagged as separate product variants for customer review before import.

Ridder iQ Sales Orders map to Dolibarr Propal (for quotes in draft or sent status) and Dolibarr Order (for accepted orders). We map order headers (customer reference, date, due date, payment terms) and line items (product, quantity, unit price, discount). Ridder iQ's pre- and post-calculation margin data per order line has no direct Dolibarr equivalent; we preserve margin as a calculated value in a custom field or in a supplemental spreadsheet for customer reference. Open orders migrate in full; closed orders migrate as read-only records.

Ridder iQ Purchase Orders map to Dolibarr Supplier Order (CommandeFournisseur). We preserve the supplier reference, order date, due date, and line items with quantities and unit costs. Open POs migrate as active orders; closed POs migrate as historical records. Purchase history against the supplier is preserved as line-item records in Dolibarr's supplier invoice module.

Ridder iQ Production Orders reference a BOM and routing, carrying scheduled start and end dates, work center assignments, and component allocations. Dolibarr's MRP module (when enabled) provides work orders for manufacturing but lacks native work center scheduling and production routing found in Ridder iQ. We migrate Production Order headers as Dolibarr Manufacturing Orders if the MRP module is active; routing step data and work center assignments are preserved in a custom field or supplemental record for manual rebuild. Production Orders without MRP are flagged as a gap requiring post-migration process redesign or a third-party add-on evaluation.

Ridder iQ ETO Projects (coordinating R&D, engineering, purchasing, and production phases) map to Dolibarr Project records. We preserve project name, description, start and end dates, budget fields, and milestone data. Phase-level data (R&D phase, engineering phase, etc.) migrates as Dolibarr project tasks with parent-child task hierarchy. Cost tracking data migrates as project task time entries or expense lines. Native ETO phase gating logic does not exist in Dolibarr Project and is flagged for manual rebuild in project configuration.

Ridder iQ invoices linked to Sales Orders map to Dolibarr Customer Invoice (Facture). Supplier invoices map to Dolibarr Supplier Invoice. We preserve invoice headers, line items, totals, and payment status. Historical closed invoices migrate as paid read-only records. Ridder iQ's payment reconciliation records attach to the corresponding Dolibarr invoice as payment entries.

Ridder iQ Documents attached to Orders, Projects, and Items (including version history) migrate as Dolibarr document attachments. File attachments and metadata export to the Dolibarr documents directory; we do not migrate version-diff data or previous revision trails. Document linkage to the parent record (Order, Project, Item) is preserved via Dolibarr's ECM module or direct file reference.

Ridder iQ custom objects and extended fields (manufacturing-specific extensions beyond standard CRM and ERP fields) map to Dolibarr ExtraFields on the equivalent standard object or to a Dolibarr custom table (llx_table_xxx). We pre-create the destination ExtraField definitions before import, matching field type, length, and picklist values where applicable. Custom object lookups to standard objects require lookup field resolution during import.

Ridder iQ owner records (users who own records in the system) map to Dolibarr User accounts. We resolve owners by email match against the Dolibarr user table. Any Ridder iQ owner without a matching Dolibarr user is held in a reconciliation queue for the customer's admin to provision before record import resumes. Dolibarr's permission model (module-level and object-level rights per user) is configured post-migration as a separate administrative step.