Migrate from Decision Builder to Dolibarr ERP

Decision Builder Customer records map to Dolibarr Third Party objects with Type = Customer. We preserve all contact details, customer-specific pricing tiers, and associated hierarchies. Dolibarr uses a single Third Party object for customers, prospects, and suppliers differentiated by the Client/Supplier checkboxes, so multi-type entities require separate Third Party records or the Multi-contact module.

Decision Builder Vendor records map to Dolibarr Third Party objects with Type = Supplier. We preserve payment terms, tax IDs, and address information. Dolibarr's Supplier module must be activated in Dolibarr's module configuration before vendor records import. Address formats require normalization because Decision Builder and Dolibarr use different field structures for address lines.

Decision Builder Item records (inventory products, services, non-inventory items) map to Dolibarr Product records with type flagged as Product, Service, or stock-enabled based on Decision Builder item type. We map item pricing, unit of measure, and bill of materials structures. Multi-level BOMs require decomposition into Dolibarr's multi-level BOM model or simplification depending on Dolibarr's installed modules.

Open invoices, credit memos, and payment records export cleanly from Decision Builder. We preserve document numbers, dates, amounts, aging information, and payment terms. In Dolibarr, open invoices map to Facture (Customer) or Supplier Facture (Vendor), credit memos map to Credit Note, and payments map to Payment records linked via PaiementFacture junction table. Post-migration reconciliation closes the loop between open items and their payments.

Invoice history, payment records, and adjustment logs migrate with full audit trails preserved in record comments or custom fields. Journal entries require mapping to Dolibarr's chart of accounts which uses a different account numbering scheme than Decision Builder. We run a pre-migration account mapping session to align source and destination account frameworks before journal records are inserted.

Decision Builder's account structures including segment definitions, account types, and rollup hierarchies require pre-migration mapping to Dolibarr's Accounting Account objects. Dolibarr's accounting module must be enabled and configured before account import. We recommend mapping the top-level account segments first and handling detail accounts in subsequent phases based on transaction volume.

Custom Data Structures in Decision Builder store business-specific data that does not map directly to standard Dolibarr objects. We assess each Data Structure during scoping: simple flat structures with no interdependencies migrate via CSV to Dolibarr custom fields; complex structures with relationships require Project-level .dec.obj export converted to Dolibarr custom object format or stored as JSON in a custom text field pending module development.

Decision Builder Projects bundle related Data Structures, workflows, and configurations. Project-level export (.dec.obj) preserves context that individual object export cannot. We map Decision Builder Project records to Dolibarr Project objects, including dates, status, description, and linked third parties. Note that Dolibarr's Project module must be activated in module configuration before import.

Attached documents and files migrate alongside their parent records (Third Parties, Products, Projects, Invoices). We verify file integrity after transfer and flag any documents that reference objects not included in the migration scope. Dolibarr stores documents in the /documents/ directory with references in the database; we map the file paths accordingly during import.

Decision Builder user accounts and role assignments require mapping to Dolibarr's permission model. Dolibarr's User module handles internal users; external contacts use the Third Party contact model. Active versus inactive status transfers, but login credentials do not migrate for security reasons. Dolibarr's permission system (global permissions, per-module permissions, and per-entity permissions) differs significantly from Decision Builder's role model and requires a separate permission mapping session.

Decision Builder rule flows encode business logic that has no automatic migration path to Dolibarr. We document every active rule flow with its trigger conditions, field evaluations, and resulting actions as a written specification for the customer's admin to configure in Dolibarr's module-based workflow layer or via custom module development. This is a rebuild scope, not a data migration.

Decision Builder workflows encode multi-step approval and routing logic. Dolibarr does not have a native workflow engine at the core level; workflow automation requires third-party modules or custom development. We deliver a written inventory of every active workflow including its steps, conditions, assignees, and escalation paths so the customer's admin can evaluate Dolibarr workflow modules or commission custom development. This is an admin rebuild scope outside standard data migration.