ERP migration
Field-level mapping, validation, and rollback between Rootstock Cloud ERP and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.
Rootstock Cloud ERP
Source
Dolibarr ERP
Destination
Compatibility
11 of 12
objects map 1:1 between Rootstock Cloud ERP and Dolibarr ERP.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Rootstock Cloud ERP to Dolibarr is a structural migration from a Salesforce-native manufacturing suite to an open-source ERP and CRM platform. Rootstock inherits the Salesforce object model for CRM records and layers ERP objects including Items, Sales Orders, Purchase Orders, Work Orders, BOMs, and Inventory Locations on top. Dolibarr's core modules cover Third-Party (Accounts/Contacts), Products, Orders, Invoices, Stock, and Projects, but Dolibarr has no native manufacturing module, no BOM versioning, no Work Order execution tracking, and no native ECO management. We migrate the data that fits Dolibarr's schema directly and flag Work Orders, BOMs, ECOs, and Fixed Assets as records requiring manual rebuild or third-party module installation post-migration. We sequence the migration by establishing the chart of accounts and Item master first, then flowing in open sales and purchase orders, location hierarchies, and on-hand inventory. Custom Salesforce fields on ERP objects are explicitly enumerated during scoping and carried forward as Dolibarr extrafields or stored in a migration audit field.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Rootstock Cloud ERP object lands in Dolibarr ERP, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Rootstock Cloud ERP
Customers (Accounts)
Dolibarr ERP
Third-Party (Dolibarr)
1:1Rootstock Accounts (CRM layer, Salesforce object) map to Dolibarr Third-Party records. Customer type (Customer / Prospect / Supplier / Both) is set via the s.rowid type field. Address data, payment terms, and credit limits migrate to corresponding Dolibarr fields. We use the Account Name as the dedupe key. Multi-site customer locations in Rootstock (Shipping Addresses, Billing Addresses on Account) map to Dolibarr Addresses linked via the contact_address table.
Rootstock Cloud ERP
Vendors
Dolibarr ERP
Third-Party (Dolibarr)
1:1Rootstock Vendors are Account records with the Vendor checkbox enabled. These map to Dolibarr Third-Party records with type = Supplier. W-9/1099 settings and EDI identifiers on the Rootstock Vendor record migrate to Dolibarr extrafields. Multiple vendor sites in Rootstock map to Dolibarr contact addresses on the Supplier Third-Party record.
Rootstock Cloud ERP
Items (Products)
Dolibarr ERP
Product (Dolibarr)
1:1Rootstock Item master records map to Dolibarr Products. We transfer Item ID, description, unit of measure, costing method (standard or average from Rootstock maps to Dolibarr PMD), and the stock management flag. Lot and serial control settings from Rootstock Item migrate to the Dolibarr lot tracking configuration on the Product record. Custom fields on the Rootstock Item object (identified during pre-migration schema review) migrate as Dolibarr extrafields.
Rootstock Cloud ERP
Sales Orders
Dolibarr ERP
Customer Order (Dolibarr)
1:1Rootstock Sales Orders map to Dolibarr Customer Orders. Header fields (Customer reference, ship-to address, payment terms) and all line items (Item reference, quantity, unit price, discount) transfer directly. Order status in Rootstock (Draft, Pending, Submitted, Shipped, Invoiced) maps to Dolibarr status (Draft, Validated, Shipped, Closed). Partially fulfilled lines are preserved as open line quantities in the Dolibarr order.
Rootstock Cloud ERP
Purchase Orders
Dolibarr ERP
Supplier Order (Dolibarr)
1:1Rootstock Purchase Orders map to Dolibarr Supplier Orders. PO header and line structure transfers with vendor reference, terms, and line items. Approval status in Rootstock maps to Dolibarr status. Vendor records must exist in Dolibarr (from the Vendor mapping above) before Purchase Order import to satisfy the fk_soc foreign key. Receipt linkages and partial receipt flags are preserved as order line quantities.
Rootstock Cloud ERP
Bills of Materials (BOMs)
Dolibarr ERP
Product description or Project (Dolibarr)
lossyRootstock BOMs define multi-level component structures with quantities and operations. Dolibarr has no native BOM object. We store the active BOM as structured text in the Product description field (or as a Dolibarr Project attached to the finished product) and flag BOM version history as a Product note field. The customer selects BOM strategy during scoping: plain-text description for simple assemblies, or Project-based structure for complex multi-level BOMs that require reconstruction in a third-party manufacturing module post-migration.
Rootstock Cloud ERP
Work Orders
Dolibarr ERP
Project (Dolibarr)
1:1Rootstock Work Orders represent manufacturing operations tied to a Sales Order or standalone job. Dolibarr has no native Work Order or Shop Floor execution object. We migrate Work Order headers as Dolibarr Projects with routing steps and material allocations stored as Project tasks and Project task time entries. Manufacturing status and completion percentages map from Rootstock WO status to Project status. Work Order BOM references are stored as Project notes linking to the BOM mapping above.
Rootstock Cloud ERP
Inventory Locations
Dolibarr ERP
Warehouse (Dolibarr)
1:1Rootstock Inventory Locations (warehouses, plants, stock points) map to Dolibarr Warehouses. We transfer location name, address, location type, and ABC analysis codes. Complex multi-level hierarchies in Rootstock (region > plant > warehouse > bin) are flattened into Dolibarr warehouse records with parent-child relationships represented via Dolibarr's warehouse address or custom extrafield rather than a native hierarchy. Circular or orphaned location assignments identified during pre-migration review are flagged for resolution before migration.
Rootstock Cloud ERP
Inventory Balances
Dolibarr ERP
Stock (Dolibarr)
1:1Rootstock on-hand inventory quantities per location map to Dolibarr Stock movements linked to Products and Warehouses. The current stock snapshot migrates as a Stock Replenishment or Stock Correction record with transaction date set to the migration date. We preserve the per-location quantity breakdown so that the customer can verify aggregate on-hand matches between systems.
Rootstock Cloud ERP
Purchase Receipts
Dolibarr ERP
Supplier Reception (Dolibarr)
1:1Rootstock Purchase Receipts link to POs and update inventory. We migrate receipt records with PO line references and quantity received. Receipt dates and partial receipt flags are reconciled against the destination Supplier Order lines, and any discrepancies are flagged in the reconciliation report for the customer's admin to resolve post-migration.
Rootstock Cloud ERP
Lot and Serial Numbers
Dolibarr ERP
Lot (Dolibarr)
1:1Rootstock Lot and Serial Number master records map to Dolibarr Lot records linked to Products. Lot number, expiration date, and supplier reference transfer directly. Serial number assignments with transaction history map to Dolibarr Lot entries with traceability note fields. Full backward lot traceability from Rootstock (receipt to shipment links) is stored in the Lot description field since Dolibarr's lot traceability is batch-level.
Rootstock Cloud ERP
Chart of Accounts
Dolibarr ERP
Accounting Account (Dolibarr
1:1Rootstock GL accounts map to Dolibarr Accounting Account records. We transfer account number, name, account type (Asset, Liability, Equity, Revenue, Expense), and segment definitions. Multi-company and intercompany settings from Rootstock are documented separately since Dolibarr's core accounting module does not support multi-company natively; the customer's admin configures intercompany relationships via separate instances or a third-party module post-migration.
| Rootstock Cloud ERP | Dolibarr ERP | Compatibility | |
|---|---|---|---|
| Customers (Accounts) | Third-Party (Dolibarr)1:1 | Fully supported | |
| Vendors | Third-Party (Dolibarr)1:1 | Fully supported | |
| Items (Products) | Product (Dolibarr)1:1 | Fully supported | |
| Sales Orders | Customer Order (Dolibarr)1:1 | Fully supported | |
| Purchase Orders | Supplier Order (Dolibarr)1:1 | Fully supported | |
| Bills of Materials (BOMs) | Product description or Project (Dolibarr)lossy | Fully supported | |
| Work Orders | Project (Dolibarr)1:1 | Fully supported | |
| Inventory Locations | Warehouse (Dolibarr)1:1 | Fully supported | |
| Inventory Balances | Stock (Dolibarr)1:1 | Fully supported | |
| Purchase Receipts | Supplier Reception (Dolibarr)1:1 | Mapping required | |
| Lot and Serial Numbers | Lot (Dolibarr)1:1 | Fully supported | |
| Chart of Accounts | Accounting Account (Dolibarr1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Rootstock Cloud ERP gotchas
Salesforce edition gating affects available ERP objects
BOM versioning requires explicit mapping to destination structure
Multi-site inventory requires location hierarchy pre-mapping
Salesforce custom fields on ERP objects require explicit field-level mapping
CI/CD and sandbox limitations complicate staging migrations
Dolibarr ERP gotchas
Foreign key constraint errors on cross-distribution database restore
SQL injection vulnerabilities in version 9.0.1
Custom fields stored as JSON in extraoptions require field-by-field deserialization
Decimal precision and rounding configuration affects price fields
No native iOS/Android app forces reliance on browser
Pair-specific challenges
Migration approach
Discovery and source schema audit
We audit the source Rootstock org across Salesforce edition tier, activated ERP modules, and object support level (Growth vs Advanced vs Enterprise determines which ERP objects are available). We enumerate all custom fields on ERP objects, inventory the BOM version history per Item, map the multi-site location hierarchy, and extract record counts for Items, Sales Orders, Purchase Orders, Work Orders, BOMs, inventory locations, and lot/serial numbers. We also identify any Salesforce custom fields on ERP objects that carry business logic and must be preserved. The discovery output is a written migration scope document that flags the manufacturing gap and any gated features.
Dolibarr target schema setup and BOM strategy selection
We assist the customer's admin with Dolibarr target schema setup: creating Warehouses (mapped from Rootstock locations), configuring the accounting chart (mapped from Rootstock GL accounts), loading Products (mapped from Rootstock Items), and enabling the Stock and Third-Party modules. During this step the customer selects the BOM strategy: plain-text product description, Project-based structure, or a third-party manufacturing module from the Dolibarr Marketplace. We document which approach the customer chooses and structure the migration export accordingly.
Sandbox migration and reconciliation
We run a full migration into a Dolibarr staging instance (can be a local install or cloud-hosted trial) using production-like data volume. The customer's operations lead reconciles record counts (Third-Parties, Products, Orders, Stock, Projects), spot-checks 25-50 records against the Rootstock source, and reviews the BOM and Work Order representations in Dolibarr. Any schema corrections, field mapping adjustments, or BOM strategy changes happen in this phase. Sign-off on the staging migration is required before production migration begins.
Dependency-ordered data migration
We run production migration in record dependency order: Third-Parties (Customers and Vendors), Products (with lot/serial settings), Warehouses (location pre-mapping validated), Products in Stock (on-hand balances per warehouse), Customer Orders, Supplier Orders, Projects (Work Orders as Projects), and BOM notes (as Product description or Project notes). Each phase emits a row-count reconciliation report. Any records rejected due to missing parent records (e.g., an Order line referencing a non-existent Product) are held in a retry queue.
Cutover, delta sync, and manufacturing-gap disclosure
We freeze writes to Rootstock during cutover, run a final delta migration of any records modified during the migration window, and complete the reconciliation pass. We deliver the manufacturing-gap document: a structured export of BOM version history, Work Order header and line data, and ECO references that the customer's admin uses to rebuild manufacturing logic in Dolibarr or the selected third-party module. We do not rebuild Work Orders, BOMs, or ECOs in Dolibarr as part of standard scope.
Hypercare and post-migration support
We support a one-week hypercare window where we resolve any reconciliation issues raised by the customer's team. Common post-migration questions include how to handle partial Purchase Order receipts, how to post Work Order material issues in the new Project structure, and how to configure lot traceability in Dolibarr's Stock module. We do not provide ongoing admin support, training, or workflow rebuild as standard scope; these are separate engagements.
Platform deep dives
Rootstock Cloud ERP
Source
Strengths
Weaknesses
Dolibarr ERP
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. All 8 core objects map 1:1 between Rootstock Cloud ERP and Dolibarr ERP.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Rootstock Cloud ERP and Dolibarr ERP.
Object compatibility
All 8 core objects map 1:1 between Rootstock Cloud ERP and Dolibarr ERP.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Rootstock Cloud ERP: Salesforce API rate limits apply—typically 100,000 API calls per 24-hour period for standard Enterprise Edition orgs, with higher limits for Unlimited and Performance editions.
Data volume sensitivity
Rootstock Cloud ERP exposes a bulk API — large-volume migrations stream efficiently.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Rootstock Cloud ERP to Dolibarr ERP migration scoping. Not seeing yours? Book a call.
Walk through your Rootstock Cloud ERP to Dolibarr ERP migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Rootstock Cloud ERP
Other ways to arrive at Dolibarr ERP
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.