Migrate from Kladana ERP to Dolibarr ERP

Kladana Items with variants, bundles, serial numbers, batches, and expiry dates map to Dolibarr Products. Variant structures in Kladana decompose into individual Product records in Dolibarr with sub-product relationships where Dolibarr's bom module is used. Serial number, batch number, and expiry date fields migrate as extra parameters on the Product record or into Dolibarr's lot/serial module if that module is activated. Barcode associations map to the barcode field on the Dolibarr Product.

Kladana Counterparties (unified customers and suppliers) map to Dolibarr Third Parties. The is_supplier and is_customer flags on Kladana Counterparty map to Dolibarr's prospected/customer/supplier typology. Transaction history linked to each Counterparty migrates as open document references (Orders, Invoices) attached to the Third Party record. Kladana Free tier customers with more than 200 counterparties must upgrade before migration; we flag this during scoping.

Kladana Sales Orders map to Dolibarr Customer Orders. The order lifecycle states (draft, confirmed, reserved, fulfilled, invoiced) map to Dolibarr status values (Draft, Validated, Shipped, Closed). Line items with pricing, quantities, and discounts migrate as order lines referencing the mapped Product. Open orders (not yet invoiced) migrate with their current fulfillment status preserved so that in-progress orders can be completed in Dolibarr.

Kladana Purchase Orders map to Dolibarr Supplier Orders with the same line-item and status mapping logic as Sales Orders. Linked supplier references from Kladana map to the Third Party supplier record. Expected delivery dates migrate as the date_livraison field on the Dolibarr order. Receipt status (fully received, partially received, not received) maps to Dolibarr's order status and line-level reception tracking.

Kladana warehouses map to Dolibarr warehouses or stock locations depending on which Dolibarr module is activated. Per-warehouse stock-on-hand quantities, reserved quantities, and pending inbound and outbound movement positions migrate as stock entries. Multiple Kladana warehouses create multiple Dolibarr warehouse records with independent stock levels. Bin storage locations within a Kladana warehouse map to Dolibarr stock locations if the multi-location stock module is enabled.

Kladana multi-level BOMs map to Dolibarr BOM structures. The critical constraint is that Kladana supports multiple BOM versions per product while Dolibarr does not track BOM versions as a first-class concept. We export all BOM versions and present the customer with a version selection decision during scoping: which version should be treated as the canonical BOM at cutover. Subassembly nesting depth is preserved where Dolibarr's bom module supports multi-level explosion.

Kladana Production Orders reference a BOM, routing, and planned quantities with actual output, material consumption, labour hours, and variance tracking. Dolibarr's production module handles work orders but does not natively track planned-versus-actual variance to the same depth. We migrate Production Order headers and material consumption lines, and flag the variance data for manual reconstruction in Dolibarr's production tracking or as a reconciliation report the customer's team reviews post-migration.

Kladana Sales Invoices and Purchase Invoices map to Dolibarr Customer Invoices and Supplier Invoices respectively. Invoice headers, line items, tax codes, payment status, and outstanding balances migrate as historical documents. Fully paid invoices migrate as closed records; open invoices migrate with their outstanding balance so that payment can be recorded in Dolibarr. The invoice-to-order linkage is preserved so that invoices can be traced back to their originating orders.

Kladana CRM contacts linked to counterparties map to Dolibarr contacts under the Third Party record. Interaction notes and activity history migrate as Dolibarr Actions (Events or Tasks) attached to the contact or Third Party. Custom offer records migrate as Dolibarr Proposals if the commercial proposals module is active. The contact hierarchy under Third Party is preserved so that primary and secondary contacts retain their roles.

Kladana custom fields on Items, Counterparties, Orders, and other objects migrate as Dolibarr Extra Fields (extra parameters). Custom field definitions and their values are exported as key-value pairs and inserted into Dolibarr's extrafield schema. The destination Dolibarr instance must have the Extra Fields module enabled and the corresponding extrafield columns created before migration. We provide a schema definition file for the customer's Dolibarr admin to apply before import.

Kladana role-based access control maps to Dolibarr user permissions at the module level. Kladana's fine-grained permission model per module does not map 1:1 to Dolibarr's permission system. We export role assignments as a mapping reference document and flag which Dolibarr permission groups correspond to each Kladana role. User provisioning is the customer's responsibility; we provide a user-permission matrix that the Dolibarr admin applies post-installation.

Kladana Tasks migrate as Dolibarr Tasks attached to the relevant Third Party, Project, or other parent record. Kladana Workflow configurations are proprietary business logic that do not map to Dolibarr's workflow module. We deliver a written inventory of all active Kladana Workflows with their trigger conditions, actions, and recommended Dolibarr equivalent module configuration. The customer's admin rebuilds these in Dolibarr post-migration.