ERP migration
Field-level mapping, validation, and rollback between iCast and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.
iCast
Source
Dolibarr ERP
Destination
Compatibility
10 of 12
objects map 1:1 between iCast and Dolibarr ERP.
Complexity
CModerate
Timeline
4-6 weeks
Overview
Moving from iCast to Dolibarr is a cross-platform ERP migration that requires coordinating data extraction through iCast professional services since no self-service export exists, then building Dolibarr's modular schema before loading records via CSV. iCast uses separate Customer and Vendor objects; Dolibarr consolidates these under Third Parties with a Type field distinguishing customers from suppliers. We map inventory locations to Dolibarr Warehouses, map iCast's hierarchical Chart of Accounts to Dolibarr's accounting module, and preserve journal entry line structure. Multi-location inventory from iCast maps to Dolibarr's multi-warehouse configuration. We do not migrate custom iCast fields, calculated fields, or saved reports as they require manual recreation in Dolibarr's module builder. Workflows and automations built in iCast do not migrate; we deliver a written inventory for the customer's admin to rebuild using Dolibarr's workflow and trigger system.
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 iCast 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.
iCast
Customer
Dolibarr ERP
Third Party (Type = Customer)
1:1iCast Customer records with payment terms, credit limits, and account managers map to Dolibarr Third Party records with Type set to Customer. The source payment terms map to Dolibarr's fk_payment_termout field. We extract customers first so that the Third Party IDs are available for linking during Sales Order and Invoice import. Duplicate detection uses company name and email as matching criteria.
iCast
Vendor
Dolibarr ERP
Third Party (Type = Supplier)
1:1iCast Vendor records map to Dolibarr Third Party with Type = Supplier. The source vendor account number maps to Dolibarr's code_fournisseur field for supplier code tracking. Vendor payment terms map to fk_payment_termout. We load all vendors before Purchase Orders so that the supplier linkage resolves correctly during PO import.
iCast
Inventory Item
Dolibarr ERP
Product (Article)
1:1iCast inventory items with SKU, description, unit of measure, cost, and warehouse location map to Dolibarr Product records. The product_type field is set to 1 for stockable items matching iCast's inventory tracking. Unit of measure maps to Dolibarr's unit_of_measure field. Multi-location inventory from iCast (multiple warehouse assignments per item) maps to Dolibarr Warehouse records with inventory tracked per warehouse via the stock module.
iCast
Inventory Location
Dolibarr ERP
Warehouse
lossyiCast warehouse location codes map to Dolibarr Warehouse records created in the stock module. Each warehouse gets an address and manager assignment. The product-to-warehouse relationship is established via the和产品_stock table during inventory load, preserving per-location quantity on hand from iCast's last inventory snapshot.
iCast
Sales Order
Dolibarr ERP
Order
1:1Open and historical iCast Sales Orders map to Dolibarr Order records with the customer Third Party ID linked via fk_soc. Order status from iCast maps to Dolibarr's fk_statut field (0=Draft, 1=Validated, etc.). Line items, pricing, and quantities map to OrderLines with the Product reference resolved from the inventory mapping. We recommend closing open iCast orders and importing only current-state or recently closed orders to reduce complexity.
iCast
Purchase Order
Dolibarr ERP
Supplier Order
1:1iCast Purchase Orders map to Dolibarr Supplier Order records with the vendor Third Party ID linked via fk_soc. Line items reference the Product records imported from iCast inventory. Expected delivery dates map to date_liv_expected. We map vendor-held PO references to the ref_supplier field for cross-system auditing.
iCast
Chart of Accounts
Dolibarr ERP
Account (Accounting Module)
lossyiCast's hierarchical chart of accounts with account numbers, types, and parent-child relationships maps to Dolibarr's accounting module account structure. We create the full account hierarchy in Dolibarr's plan_comptable table before journal entry import so that all account references in journal lines resolve correctly. Account type mapping (asset, liability, equity, income, expense) follows Dolibarr's pcg_type field values.
iCast
Journal Entry
Dolibarr ERP
Accounting Entry (Ecriture)
1:1iCast general journal entries with date, account references, debit/credit amounts, and memo fields map to Dolibarr accounting entries. We import journal lines with the account ID resolved to the new Dolibarr account codes, debit/credit amounts preserved, and the original iCast memo retained in the label field. Entries referencing accounts not yet created in Dolibarr go to a reconciliation queue for account creation before retry.
iCast
User
Dolibarr ERP
User
1:1iCast User accounts with login, roles, and access permissions map to Dolibarr User records. We match by email address. Any iCast user without a corresponding Dolibarr user goes to a reconciliation queue for admin provisioning. Role structures require manual recreation in Dolibarr's Users and Rights management (DOLIBARR_ADMIN_ALL_PERMS flag) since role modeling differs from iCast.
iCast
Sales Order Line Item
Dolibarr ERP
Order Line
1:1iCast sales order line items map to Dolibarr OrderLine records linked to the parent Order via fk_commande. Each line references the Product ID resolved from the inventory item mapping. Quantity, unit price, discount percentage, and VAT rate migrate directly. Extended amounts recalculate in Dolibarr on insert.
iCast
Purchase Order Line Item
Dolibarr ERP
Supplier Order Line
1:1iCast purchase order line items map to Dolibarr CommandeFournisseurLigne records with fk_commande linked to the parent Supplier Order. Product reference, quantity, cost, and discount migrate. We validate that the source unit cost aligns with the Product's buying price in Dolibarr before insert.
iCast
Product Image / Attachment
Dolibarr ERP
Document (documents directory)
1:1iCast attachments on inventory items and orders map to files in Dolibarr's documents directory (or dolibarr_documents root). We extract binary attachments, copy them to the corresponding Dolibarr entity subdirectory (products, orders, etc.), and create the database record in the extension_table referencing the file path. Image thumbnails preserve for product catalog display.
| iCast | Dolibarr ERP | Compatibility | |
|---|---|---|---|
| Customer | Third Party (Type = Customer)1:1 | Fully supported | |
| Vendor | Third Party (Type = Supplier)1:1 | Fully supported | |
| Inventory Item | Product (Article)1:1 | Fully supported | |
| Inventory Location | Warehouselossy | Fully supported | |
| Sales Order | Order1:1 | Fully supported | |
| Purchase Order | Supplier Order1:1 | Fully supported | |
| Chart of Accounts | Account (Accounting Module)lossy | Mapping required | |
| Journal Entry | Accounting Entry (Ecriture)1:1 | Fully supported | |
| User | User1:1 | Fully supported | |
| Sales Order Line Item | Order Line1:1 | Fully supported | |
| Purchase Order Line Item | Supplier Order Line1:1 | Fully supported | |
| Product Image / Attachment | Document (documents directory)1: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.
iCast gotchas
No self-service data export mechanism
Custom fields and reports do not migrate automatically
Historical data volume complicates migration timelines
Limited third-party integrator ecosystem
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 extraction coordination with iCast
We audit the iCast environment across all modules in scope (Customers, Vendors, Inventory, Sales Orders, Purchase Orders, Chart of Accounts, Journal Entries, Users). We document the historical window, identify custom fields and calculated fields, and assess the multi-entity structure. We initiate coordination with iCast professional services to schedule database extraction or managed export, and include this extraction step in the project timeline with buffer days for iCast response.
Dolibarr schema setup and module configuration
We configure the Dolibarr instance with the modules required for the migration scope: Third Parties (with customer and supplier types enabled), Products (stock module for inventory), Orders, Supplier Orders, Accounting (if financial history is in scope), and Warehouse management. We create the warehouse records matching the iCast inventory location codes, and we pre-build the chart of accounts in Dolibarr's accounting module before journal entry import. The migration user receives Create/Read/Update permissions on the relevant modules.
Third party and product import
We import all iCast Customer records as Dolibarr Third Parties with Type = Customer, followed by all Vendor records as Third Parties with Type = Supplier. The import uses Dolibarr's CSV import wizard (enabled via the Tools module) with a custom CSV profile we build during setup that maps iCast field names to Dolibarr column headers. After third parties load, we import iCast inventory items as Dolibarr Products, establishing the product ID mapping required for all downstream order and line item imports. We run duplicate detection (by email for contacts, by name+address for companies) and flag any potential duplicates for manual review.
Sales Orders and Purchase Orders import
With third parties and products loaded, we import open iCast Sales Orders as Dolibarr Orders and Purchase Orders as Supplier Orders. Line items import with the product reference resolved to the new Dolibarr product ID. We hold orders with a status of Pending or Held for customer review before inserting into the validated state. We preserve the original iCast order number in Dolibarr's ref_customer and ref_supplier fields for cross-reference.
Chart of Accounts and Journal Entry import
We create the full iCast chart of accounts in Dolibarr's accounting module, mapping account types to Dolibarr's pcg_type values and preserving the parent-child hierarchy. With the account structure confirmed, we import journal entries in date order, inserting debit/credit lines with the resolved account ID. Entries referencing accounts not yet created go to a hold queue; we resolve and retry until all lines insert without referential integrity errors. We validate total debits equal total credits per entry as a checksum.
Cutover, validation, and custom field handoff
We freeze writes in iCast during cutover, run a final delta migration of any records modified since the last extract, validate record counts against the iCast source totals, and spot-check 25-50 records for field-level accuracy. We deliver the custom field inventory document to the customer's Dolibarr admin with the list of fields to recreate in Extrafields and any calculation logic to implement via Dolibarr's calculated field system or custom PHP hook. We support a five-day hypercare window for reconciliation issues.
Platform deep dives
iCast
Source
Strengths
Weaknesses
Dolibarr ERP
Destination
Strengths
Weaknesses
Complexity grading
Moderate ERP migration. 4 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across iCast and Dolibarr ERP.
Object compatibility
4 of 8 objects need a mapping; the rest are 1:1.
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
iCast: Not publicly documented..
Data volume sensitivity
iCast doesn't expose a bulk API — REST + parallelization used for high-volume runs.
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 iCast to Dolibarr ERP migration scoping. Not seeing yours? Book a call.
Walk through your iCast 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 iCast
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.