ERP migration
Field-level mapping, validation, and rollback between Iptor ERP and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.
Iptor ERP
Source
Dolibarr ERP
Destination
Compatibility
13 of 16
objects map 1:1 between Iptor ERP and Dolibarr ERP.
Complexity
BStandard
Timeline
4-8 weeks
Overview
Moving from Iptor ERP to Dolibarr is a structural migration from a distribution-focused ERP with modular deployment and opaque enterprise pricing to an open-source, modular ERP designed for small and mid-sized businesses. Iptor's Business Partner entity is a unified record type for both customers and vendors; Dolibarr separates Third Parties into customers and suppliers, requiring a type-based split during migration. Iptor's Item Classification hierarchies map to Dolibarr's flat product category structure with multi-level paths collapsed or tagged. We preserve open AP/AR balances as explicit records so the destination begins with accurate go-live financial data. Industry-specific Publishing module objects (Royalties, Rights, Permissions, Contracts) have no native Dolibarr equivalent; we convert them to structured flat files for customer review before commit. Workflows, automations, and EDI integrations do not migrate; we deliver a written inventory of these for the customer's admin to rebuild in Dolibarr or via third-party modules.
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 Iptor 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.
Iptor ERP
Business Partner (Customer)
Dolibarr ERP
Third Party (Customer)
1:manyIptor's unified Business Partner entity stores both customers and vendors in a single table with a type attribute. We split by BP type during migration: Customer BPs map to Dolibarr Third Parties with the Customer checkbox enabled. The BP code, name, address, contact details, payment terms, and tax ID transfer directly. Any custom fields on the Customer BP migrate as Dolibarr extrafields on the Third Party.
Iptor ERP
Business Partner (Vendor)
Dolibarr ERP
Third Party (Supplier)
1:manyVendor BPs from Iptor map to Dolibarr Third Parties with the Supplier checkbox enabled. Vendor-specific fields including bank details, W-9/W-8 information, and supplier-specific payment terms transfer as extrafields on the Third Party. We preserve the vendor code from Iptor as a reference field for reconcilliation after migration.
Iptor ERP
Item
Dolibarr ERP
Product
1:1Iptor Items with their configurable attributes, unit-of-measure settings, and lot/serial tracking data map to Dolibarr Products. Item pricing (cost price, sale price, minimum price) transfers to Dolibarr price levels. The product type (stockable, service, assembly) maps from Iptor's item type field. Any item barcodes migrate to the barcode field in Dolibarr.
Iptor ERP
Item Classification
Dolibarr ERP
Category or Tags
lossyIptor's multi-level Item Classification hierarchy does not map 1:1 to Dolibarr's flat category structure. We extract the full classification tree, compute the full path for each item (e.g., Food/Beverages/Snacks/Chips), and either assign the deepest level as the primary Dolibarr Category or distribute the path across Dolibarr's tag system depending on the customer's reporting needs. The customer chooses the strategy during scoping.
Iptor ERP
Sales Order
Dolibarr ERP
Order
1:1Iptor Sales Orders map directly to Dolibarr Customer Orders. Order headers (order number, date, customer reference, payment terms, status) transfer with their original values. Order lines migrate with product reference, quantity, unit price, and discount. Open orders (not yet fulfilled) retain their status for continuation in Dolibarr; fulfilled orders migrate as historical records.
Iptor ERP
Purchase Order
Dolibarr ERP
Supplier Order
1:1Iptor Purchase Orders map to Dolibarr Supplier Orders. Vendor assignment, expected delivery dates, and line quantities transfer directly. Partially received POs are migrated with received quantities flagged so that the destination reflects current receipt status. Purchase Order number and date are preserved for audit continuity.
Iptor ERP
Invoice (AR)
Dolibarr ERP
Customer Invoice
1:1Iptor AR invoices map to Dolibarr Customer Invoices with invoice number, date, due date, tax jurisdiction codes, and payment terms preserved. The invoice total and tax amount transfer to Dolibarr's total and tva fields. Open invoices (unpaid) migrate with their status so that the customer can continue collections in Dolibarr.
Iptor ERP
Invoice (AP)
Dolibarr ERP
Supplier Invoice
1:1Iptor AP invoices map to Dolibarr Supplier Invoices with vendor reference, invoice date, due date, and amount preserved. Tax codes and payment terms transfer as extrafields where not natively supported. Open AP balances are migrated as explicit open items (see below) to ensure the aged trial balance is accurate at go-live.
Iptor ERP
Open AP/AR Balances
Dolibarr ERP
Open Items
1:1We extract open payables and receivables as explicit records at migration time so that Dolibarr begins with accurate aged trial balance data. Each open item includes the BP reference, invoice or document number, original date, due date, open amount, and currency. Closed items are migrated as historical records for reporting continuity but are flagged as closed in Dolibarr's status fields.
Iptor ERP
Delivery Note
Dolibarr ERP
Shipment
1:1Iptor Delivery Notes map to Dolibarr Shipments. Header and line details including quantities shipped versus ordered transfer, with a linkage back to the originating Sales Order for audit trail. The delivery date and carrier reference migrate where present. Shipment status reflects the fulfillment state at migration time.
Iptor ERP
Chart of Accounts
Dolibarr ERP
Accounts
1:1Iptor's configurable segment layout maps to Dolibarr's chart of accounts. We analyze the segment structure during discovery, identify the account number and name components, and map them to Dolibarr's account coding scheme. Accounts with non-standard segment assignments are flagged for manual review before migration. Recurring journal types are noted for the customer to configure in Dolibarr's cron-based automation.
Iptor ERP
Journal Entries
Dolibarr ERP
Accounting Entries
1:1Historical journal entries migrate for reporting continuity. Iptor's journal date, description, and all debit/credit lines transfer to Dolibarr's accounting entry format. Complex journal types (including recurring entries) are preserved with their periodicity noted so that the customer can configure Dolibarr's cron-based recurrence where applicable. We skip locked periods based on the destination's fiscal year close status.
Iptor ERP
Inventory / Warehouse Records
Dolibarr ERP
Stock
1:1Stock levels, warehouse locations, and lot/serial numbers migrate as current-state snapshots at go-live. Iptor's multi-warehouse setup requires us to map warehouse codes to Dolibarr's location IDs. Lot and serial traceability data transfers to Dolibarr's lot tracking module. Post-migration stock movements are recorded in Dolibarr's standard stock movement tables.
Iptor ERP
Publishing Royalties and Rights
Dolibarr ERP
Contract (structured flat file)
1:1Present only where the Iptor Publishing module is active. Royalties and Rights records have complex multi-dimensional structures reflecting publishing industry workflows. Dolibarr has no native royalty or rights object. We convert these records to a structured flat file with key fields preserved in columns: contract ID, right type, royalty rate, entitlement period, counterparty, and territory. The customer reviews and approves the flattened schema before we commit the data.
Iptor ERP
Document and Attachments
Dolibarr ERP
Documents
1:1Documents stored in Iptor's document management system export as file packages alongside the related transactional record. We extract the file package with folder structure preserved, map the parent record reference, and deliver the package for the customer to attach to the corresponding Dolibarr records post-import. Document content itself does not migrate through Dolibarr's API; the file transfer is a separate delivery.
Iptor ERP
User and Security Role
Dolibarr ERP
User
1:1User accounts, passwords, and role assignments do not migrate directly due to identity and security constraints. We provide a user mapping table that maps each Iptor user to their Dolibarr user account by email. The customer provisions Dolibarr users and assigns permissions before go-live. The mapping table ensures that migrated records are traceable to the correct owner in Dolibarr.
| Iptor ERP | Dolibarr ERP | Compatibility | |
|---|---|---|---|
| Business Partner (Customer) | Third Party (Customer)1:many | Fully supported | |
| Business Partner (Vendor) | Third Party (Supplier)1:many | Fully supported | |
| Item | Product1:1 | Fully supported | |
| Item Classification | Category or Tagslossy | Fully supported | |
| Sales Order | Order1:1 | Fully supported | |
| Purchase Order | Supplier Order1:1 | Fully supported | |
| Invoice (AR) | Customer Invoice1:1 | Fully supported | |
| Invoice (AP) | Supplier Invoice1:1 | Fully supported | |
| Open AP/AR Balances | Open Items1:1 | Fully supported | |
| Delivery Note | Shipment1:1 | Fully supported | |
| Chart of Accounts | Accounts1:1 | Mapping required | |
| Journal Entries | Accounting Entries1:1 | Mapping required | |
| Inventory / Warehouse Records | Stock1:1 | Mapping required | |
| Publishing Royalties and Rights | Contract (structured flat file)1:1 | Fully supported | |
| Document and Attachments | Documents1:1 | Fully supported | |
| User and Security Role | User1: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.
Iptor ERP gotchas
Number rollover threshold blocks scaling
Large-scale custom modifications require manual mapping
On-premises deployments need VPN or remote access coordination
Item classification hierarchies do not flatten cleanly
Publishing royalties and rights are non-standard structures
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 module identification
We audit the source Iptor environment to identify which modules are active (Distribution, Publishing, Pharma) and which vertical-specific fields are present. We extract record counts for Business Partners, Items, Sales Orders, Purchase Orders, Invoices, Delivery Notes, Chart of Accounts, Journal Entries, and Inventory levels. We confirm deployment type (on-premises or cloud) and arrange access credentials. We also identify any custom modifications, non-standard account segment assignments, and multi-level Item Classification trees that require manual mapping. The discovery output is a written migration scope with object counts, module flags, and a list of fields requiring custom mapping decisions.
Business Partner split and user mapping design
We design the Business Partner split strategy: Iptor BPs of type Customer map to Dolibarr Third Parties with Customer checked; BPs of type Vendor map to Third Parties with Supplier checked. We extract the full list of Iptor users referenced on transactional records and create a user mapping table that matches by email to Dolibarr user accounts. The customer provisions Dolibarr users before production migration. We also design the Item Classification flattening or tagging strategy based on the customer's reporting preferences.
Sandbox migration and reconciliation
We run a full migration into a Dolibarr test environment (a separate Dolibarr instance or database clone) using production-like data volume. The customer's operations lead reconciles record counts against the Iptor source system, spot-checks 25-50 records per object type for data accuracy, and reviews the Publishing Royalties flat file if the Publishing module is active. Any mapping corrections happen in this phase. We do not proceed to production until the customer signs off on the sandbox results.
Production migration in dependency order
We run production migration in record-dependency order: Third Parties (customers and suppliers split by type), Products (with category or tag assignments), Accounts (from Iptor Chart of Accounts), then transactional records (Sales Orders, Purchase Orders, Invoices, Delivery Notes). Open AP/AR balances migrate as explicit open items after invoice migration to ensure the aged trial balance is accurate. Journal Entries migrate after accounts are established. Stock levels migrate as a go-live snapshot with warehouse-to-location mapping resolved. Each phase emits a row-count reconciliation report before the next phase begins.
Publishing module data delivery (if active)
If the Iptor Publishing module is active, we deliver the Royalties and Rights data as a structured CSV file alongside the main migration. The file contains contract ID, right type, royalty rate, entitlement period, counterparty, and territory columns for customer review. The customer approves the schema before we commit the file. Any Dolibarr custom module development to maintain royalties as native records is a separate engagement.
Cutover, validation, and handoff
We freeze Iptor writes during the cutover window, run a final delta migration of any records modified during the migration window, then enable Dolibarr as the system of record. We deliver a written inventory of Iptor Workflows, EDI configurations, and automations that require rebuild in Dolibarr's module ecosystem or via third-party add-ons. We do not rebuild Iptor Workflows or EDI integrations as code inside the migration scope. We support a one-week hypercare window where we resolve any reconciliation issues raised by the customer's team. Post-migration admin support, training, and workflow rebuild are separate engagements.
Platform deep dives
Iptor ERP
Source
Strengths
Weaknesses
Dolibarr ERP
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Iptor ERP and Dolibarr ERP.
Object compatibility
2 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
Iptor ERP: Not publicly documented.
Data volume sensitivity
Iptor ERP 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 Iptor ERP to Dolibarr ERP migration scoping. Not seeing yours? Book a call.
Walk through your Iptor 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 Iptor 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.