ERP migration

Migrate from Iptor ERP to Dolibarr ERP

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 logo

Iptor ERP

Source

Dolibarr ERP

Destination

Dolibarr ERP logo

Compatibility

81%

13 of 16

objects map 1:1 between Iptor ERP and Dolibarr ERP.

Complexity

BStandard

Timeline

4-8 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Iptor ERP logo

Iptor ERP

What's pushing teams away

  • Hitting number rollover limits at high transaction volumes — businesses approaching or exceeding a billion in sales have encountered data boundary issues that force a platform migration.
  • Business growth requires large-scale custom modifications to stay functional, accumulating technical debt that makes future migrations more complex and risky.
  • Slow performance and navigation complexity frustrate end users, particularly in on-premises deployments that require VPN access for remote workers.
  • Limited scalability compared to enterprise platforms like NetSuite or Microsoft Dynamics 365, especially for multi-state operations with complex tax and regulatory requirements.
  • Customer service quality concerns and support responsiveness cited as weak points in verified review data.

Choosing

Dolibarr ERP logo

Dolibarr ERP

What's pulling them in

  • Free open-source core with no per-user license fee makes it the lowest-cost entry point for small teams needing ERP and CRM in one package.
  • Self-hosted deployment gives full data ownership and eliminates vendor lock-in, especially attractive to businesses with compliance requirements.
  • Modular architecture means teams enable only the features they use, keeping the interface uncluttered and reducing learning curve.
  • Fast installation with no technical knowledge required — one reviewer set up multiple businesses in minutes using their own hosting.
  • Active community forum and marketplace of third-party add-ons provide support and extension options without mandatory subscription costs.

Object mapping

How Iptor ERP objects map to Dolibarr ERP

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)

maps to

Dolibarr ERP

Third Party (Customer)

1:many
Fully supported

Iptor'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)

maps to

Dolibarr ERP

Third Party (Supplier)

1:many
Fully supported

Vendor 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

maps to

Dolibarr ERP

Product

1:1
Fully supported

Iptor 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

maps to

Dolibarr ERP

Category or Tags

lossy
Fully supported

Iptor'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

maps to

Dolibarr ERP

Order

1:1
Fully supported

Iptor 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

maps to

Dolibarr ERP

Supplier Order

1:1
Fully supported

Iptor 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)

maps to

Dolibarr ERP

Customer Invoice

1:1
Fully supported

Iptor 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)

maps to

Dolibarr ERP

Supplier Invoice

1:1
Fully supported

Iptor 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

maps to

Dolibarr ERP

Open Items

1:1
Fully supported

We 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

maps to

Dolibarr ERP

Shipment

1:1
Fully supported

Iptor 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

maps to

Dolibarr ERP

Accounts

1:1
Mapping required

Iptor'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

maps to

Dolibarr ERP

Accounting Entries

1:1
Mapping required

Historical 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

maps to

Dolibarr ERP

Stock

1:1
Mapping required

Stock 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

maps to

Dolibarr ERP

Contract (structured flat file)

1:1
Fully supported

Present 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

maps to

Dolibarr ERP

Documents

1:1
Fully supported

Documents 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

maps to

Dolibarr ERP

User

1:1
Fully supported

User 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.

Gotchas + challenges

What specifically takes care here

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 logo

Iptor ERP gotchas

High

Number rollover threshold blocks scaling

High

Large-scale custom modifications require manual mapping

Medium

On-premises deployments need VPN or remote access coordination

Medium

Item classification hierarchies do not flatten cleanly

Medium

Publishing royalties and rights are non-standard structures

Dolibarr ERP logo

Dolibarr ERP gotchas

High

Foreign key constraint errors on cross-distribution database restore

High

SQL injection vulnerabilities in version 9.0.1

Medium

Custom fields stored as JSON in extraoptions require field-by-field deserialization

Medium

Decimal precision and rounding configuration affects price fields

Low

No native iOS/Android app forces reliance on browser

Pair-specific challenges

  • Iptor number rollover limits approaching high-volume thresholds

    Iptor's integer-based transaction numbering has a rollover ceiling that becomes visible as companies grow into high-volume order and invoice counts. Verified customer reviews document this causing companies to migrate away when they approach billion-dollar sales volumes. We detect rollover risk during the pre-migration data audit by analyzing max transaction ID values. If records approach the limit, we flag this before migration scoping so the customer understands the urgency and can plan a destination system that handles larger ID ranges natively. Dolibarr has no documented integer rollover ceiling for typical SMB transaction volumes.

  • Publishing Royalties and Rights have no native Dolibarr equivalent

    Iptor's Publishing module stores Royalties, Rights, Permissions, and Contract data in a multi-dimensional structure that reflects publishing industry workflows. Dolibarr has no native royalty, rights, or permissions object. We convert these records to structured flat files with key fields (contract ID, right type, royalty rate, entitlement period, counterparty, territory) preserved in columns. The customer reviews and approves the flattened schema before we commit. If the customer requires a custom module to maintain royalty tracking in Dolibarr, that is a separate development scope outside standard migration.

  • Item Classification hierarchies require flattening or tagging strategy

    Iptor's Item Classification system supports multi-level hierarchical categorization that is industry-specific. The hierarchy does not map 1:1 to Dolibarr's flat category fields. We extract the full classification tree, preserve parent-child relationships, and resolve each item's classification path to a single primary category or to multiple tag attributes depending on what the destination supports. This adds a mapping step that is not present for companies with flat item taxonomies. The customer chooses between category assignment and tag distribution during scoping.

  • Large-scale custom modifications require manual mapping with customer approval

    Growing companies that stayed on Iptor past their original scope often added extensive custom modifications to compensate for platform limits. These customizations are not part of the standard schema and have no automated export path. We identify every custom field and modified table during the discovery phase, document their dependencies, and create a manual mapping specification. The customer must approve the mapping before we proceed, and the data migrates as custom properties on standard Dolibarr objects using the extrafields mechanism. Custom modification debt accumulated by growing customers makes data extraction and schema mapping complex.

  • On-premises Iptor deployments need VPN or direct database access coordination

    Iptor on-premises installations require either direct database access or VPN tunnels for API-based extraction. Cloud customers access Iptor through its hosted environment with its own authentication and permission model. We confirm the deployment type during scoping and arrange appropriate access credentials. On-premises migrations require IT coordination from the customer's side and may introduce timeline dependencies on network team availability. Dolibarr's PHP/MySQL stack is self-hosted, so the customer must also provision the destination server environment before migration data is delivered.

Migration approach

Six steps for a successful Iptor ERP to Dolibarr ERP data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Context on both ends of the pair

Iptor ERP logo

Iptor ERP

Source

Strengths

  • Deep distribution-domain functionality for order processing, inventory, and fulfillment built specifically for wholesalers.
  • Modular architecture allows companies to activate only the modules they need, reducing complexity for smaller operations.
  • Strong item classification and lot/serial tracking for industries with traceability requirements like food & beverage.
  • Industry-specific editions for publishing, pharma, and distribution rather than a one-size-fits-all ERP.
  • Integrated EDI and supply chain collaboration capabilities for B2B transaction automation.

Weaknesses

  • Limited scalability for very large transaction volumes, with known rollover thresholds that affect high-growth companies.
  • Pricing is opaque and quote-based, making cost comparison difficult during the migration planning phase.
  • On-premises and VPN-dependent deployments create friction for fully remote or cloud-native operations.
  • Custom modification debt accumulated by growing customers makes data extraction and schema mapping complex.
  • API documentation is not publicly prominent; deep technical extraction often requires coordinated access with the Iptor team.
Dolibarr ERP logo

Dolibarr ERP

Destination

Strengths

  • Free core software with AGPL license and no per-user mandatory fee for self-hosted deployments.
  • Modular architecture lets teams activate only needed features, keeping the interface focused and the database lean.
  • Self-hosted option provides full data sovereignty and avoids recurring SaaS subscription costs.
  • Built-in CSV/Excel import and export wizard with saved profiles simplifies recurring data operations.
  • Low-code Module Builder allows functional extensions without writing PHP code.

Weaknesses

  • No native documented REST API for programmatic bulk operations — all migrations depend on the import/export wizard or direct database access.
  • Reporting and analytics are weak without paid add-ons, and built-in charts are limited compared to modern SaaS platforms.
  • UI design is described as dated by multiple reviewers, with infrequent visual updates to the default theme.
  • Community-only support for self-hosted deployments means no SLA or guaranteed response time for issues.
  • Security vulnerabilities (CVE-2024-5314, CVE-2024-5315) in version 9.0.1 with no immediate patch reported.

Complexity grading

How hard is this migration?

Standard ERP migration. 2 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Iptor ERP and Dolibarr ERP.

  • Object compatibility

    B

    2 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    Iptor ERP: Not publicly documented.

  • Data volume sensitivity

    B

    Iptor ERP doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Iptor ERP to Dolibarr ERP migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Iptor ERP to Dolibarr ERP data migrations

Answers to the questions buyers ask most during Iptor ERP to Dolibarr ERP migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most migrations land between four and eight weeks for accounts under 10,000 Business Partners, 5,000 orders, and no Publishing or Pharma modules. Migrations with Publishing Royalties, large-scale custom modifications, multi-level Item Classification trees, or complex multi-warehouse inventory configurations move to ten to sixteen weeks because of manual mapping scope, schema validation, and customer approval cycles for flattened royalty structures.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Iptor ERP.
Land in Dolibarr ERP, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day