ERP migration

Migrate from Paragon ERP to Dolibarr ERP

Field-level mapping, validation, and rollback between Paragon ERP and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.

Paragon ERP logo

Paragon ERP

Source

Dolibarr ERP

Destination

Dolibarr ERP logo

Compatibility

75%

9 of 12

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

Complexity

BStandard

Timeline

5-8 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from Paragon ERP to Dolibarr is a structural migration from a cloud-native proprietary ERP with apparel-specific grid features to an open-source modular platform with a different permission model. Paragon organizes data around Items with Style/Color/Size grids, multi-tier Entities (DBAs), and Locations for GL allocation; Dolibarr uses a simpler product variant model, a single-company warehouse structure, and CSV-based import. The biggest structural challenges are splitting Paragon apparel grids into Dolibarr product variants, decomposing multi-entity department and location segments into Dolibarr's category and warehouse model, and filtering Paragon's abandoned attributes from association exports before loading. We extract from Paragon via the Universal Translator, transform through custom scripts that handle the apparel variant split and attribute deduplication, and load via Dolibarr's native CSV import or REST API. We do not migrate Paragon screen configurations or workflow automations; we deliver a written inventory of these for the customer's admin to rebuild in Dolibarr.

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

Paragon ERP logo

Paragon ERP

What's pushing teams away

  • Some reviewers report significant software bugs and confusing error messages that require opening support tickets, with debugging messages that lack actionable detail for self-resolution.
  • Small business users flag the per-user pricing model as a scaling cost concern, particularly as headcount grows and the monthly spend compounds without volume discounts documented in the public pricing.
  • Performance slowdowns during large data exports and system restores frustrate users managing high-volume inventory or transaction histories, suggesting the platform's export pipeline is single-threaded for large result sets.
  • Integration bugs during custom development episodes force teams to engage Paragon support for fixes that should be self-service, extending timelines for migrations that depend on connected system parity.
  • A confusing initial setup process with non-obvious configuration dependencies (attributes before imports, screen setup before transactions) causes delays for teams that expect to import legacy data immediately after sign-up.

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 Paragon ERP objects map to Dolibarr ERP

Each row shows how a Paragon 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.

Paragon ERP

Item (Product)

maps to

Dolibarr ERP

Product

1:1
Fully supported

Paragon Items map to Dolibarr Products with SKU, description, and unit of measure preserved. The Paragon item type (stock, non-stock, service) maps to Dolibarr's product type field. Vendor associations migrate as Dolibarr supplier references on the product record. If the Paragon item uses a Style/Color/Size grid, we split each grid cell into a separate Dolibarr product and create a configurable parent product that references them via customizable options.

Paragon ERP

Style/Color/Size Grid

maps to

Dolibarr ERP

Product + Customizable Options

1:many
Fully supported

Paragon apparel grids store one row per Style/Color/Size combination with individual SKU, inventory, and pricing per cell. Dolibarr has no native grid system. We split the grid into individual Dolibarr products (one per size/color variant) and create a configurable parent product with customizable options for Size and Color. The parent product carries the base item price; variant-specific pricing and on-hand quantities map to the child product records. This is the most manual part of apparel migrations and requires a size run inventory count before migration.

Paragon ERP

Inventory Location

maps to

Dolibarr ERP

Warehouse

1:1
Fully supported

Paragon Locations (warehouses, distribution centers, retail sites) map directly to Dolibarr Warehouses. Physical stock quantities per Item-Location combination migrate as Dolibarr stock entries tied to the resolved warehouse ID. We validate that each Paragon Location has a corresponding Dolibarr warehouse created before inventory import begins.

Paragon ERP

Customer

maps to

Dolibarr ERP

Third Party (Customer)

1:1
Fully supported

Paragon Customers map to Dolibarr Third Parties with the Customer checkbox enabled. Address records deduplicate by normalized address string and link to the Third Party. Customer-specific pricing and payment terms migrate as Extra Fields or direct fields on the Third Party record. Paragon's customer type (wholesale, retail, contractor) migrates as a Category tag in Dolibarr.

Paragon ERP

Vendor

maps to

Dolibarr ERP

Third Party (Supplier)

1:1
Fully supported

Paragon Vendors map to Dolibarr Third Parties with the Supplier checkbox enabled. Payment terms from Paragon (Net 30, Net 60, etc.) convert to Dolibarr Payment Term conditions. Vendor-specific lead times and EDI/PO configuration references migrate as notes since Dolibarr does not have a native EDI configuration object. We deduplicate vendor addresses before import.

Paragon ERP

Department + Entity

maps to

Dolibarr ERP

Category + Multi-Company Configuration

1:many
Fully supported

Paragon's Department-Entity-Location GL segmentation has no single Dolibarr equivalent. Departments map to Dolibarr Categories for segmentation and reporting purposes. For multi-entity Paragon customers with separate DBAs, we review whether the customer needs true multi-company isolation (separate legal entities requiring separate Dolibarr instances) versus departmental segmentation (which Dolibarr Categories handle). This decision is made during discovery because it changes the migration architecture significantly.

Paragon ERP

Association + Attribute

maps to

Dolibarr ERP

Category + Note

lossy
Fully supported

Paragon Associations define record-to-record relationships using Attribute Values. Dolibarr has no native equivalent for cross-record associations. We evaluate each association type: those functioning as categorization become Dolibarr Categories; those functioning as true inter-record links (e.g., a substitution record linking two Items) become Note records with structured relationship metadata. We filter out abandoned Paragon attributes before migration to prevent over-populating the Dolibarr category namespace.

Paragon ERP

Order (Sales)

maps to

Dolibarr ERP

Customer Order

1:1
Fully supported

Paragon Sales Orders map to Dolibarr Customer Orders with status preserved (Draft, Submitted, Shipped, Invoiced). Line items reference migrated product IDs, quantities, and unit prices. Historical orders migrate with original timestamps preserved. Paragon's screen configuration for orders must be recreated in Dolibarr's Order module settings before import.

Paragon ERP

Order (Purchasing)

maps to

Dolibarr ERP

Supplier Order

1:1
Fully supported

Paragon Purchase Orders map to Dolibarr Supplier Orders with vendor references resolved to migrated Third Party IDs. Order status (Draft, Approved, Received, Closed) migrates to Dolibarr's status model. Received quantities link to the corresponding warehouse stock entries. Historical PO data migrates with original timestamps.

Paragon ERP

AP/AR

maps to

Dolibarr ERP

Third Party Accounting Entries

1:1
Fully supported

Open Accounts Payable and Accounts Receivable records from Paragon migrate as Dolibarr Third Party accounting entries linked to the corresponding customer or vendor Third Party. Invoice reference numbers, amounts, due dates, and aging buckets migrate as individual invoice lines. We preserve original transaction dates and invoice numbers for audit trail purposes.

Paragon ERP

User

maps to

Dolibarr ERP

User

1:1
Fully supported

Paragon Users map to Dolibarr Users with login, name, and email preserved. Role assignments (Admin, Standard User, etc.) map to Dolibarr permission profiles. We do not migrate passwords or authentication credentials; the customer resets credentials post-migration. Users with no active Dolibarr equivalent are placed in a reconciliation queue.

Paragon ERP

Address

maps to

Dolibarr ERP

Address (linked to Third Party)

1:1
Fully supported

Paragon maintains separate Address records referenced by Customers, Vendors, and Locations. We deduplicate addresses by normalized street, city, state, postal code, and country before import to prevent duplicate address records in Dolibarr. Shipping and billing address flags migrate as address type labels on the linked Dolibarr Third Party.

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.

Paragon ERP logo

Paragon ERP gotchas

High

Attributes must be created before any import that references them

Medium

Association export includes all attributes including abandoned ones

High

Screen setup required before transaction imports

Medium

No public API documentation for bulk export endpoints

Medium

Multi-entity structure requires careful chart of accounts mapping

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

  • Dolibarr import rejects non-strict ISO date formats

    Dolibarr's import system enforces a strict date regex pattern: ^[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]$ for date fields. Paragon's Universal Translator sometimes exports timestamps in formats like 2015-01-01 12:30:00 that fail this pattern. A documented Dolibarr GitHub issue (dolibarr/dolibarr #24700) shows this breaking imports even with simple date values. We normalize all date fields in the transformation layer to YYYY-MM-DD before writing any Dolibarr import file, stripping time components from date-only fields and validating against the Dolibarr regex before each batch upload.

  • Paragon exports abandoned attributes that bloat association files

    The Paragon Universal Translator's association export includes every attribute ever created in the system, including attributes defined and subsequently abandoned during past configuration experiments. For manufacturing companies with years of Paragon customization, this export can include hundreds of irrelevant attribute columns that cause Dolibarr import failures or over-populate the target category namespace. We filter the export to retain only active attribute definitions before generating the migration file, removing abandoned columns and any association rows that reference only abandoned attributes.

  • Apparel Size/Color grids have no native Dolibarr equivalent

    Paragon's Style/Color/Size grid interface is a first-class feature with per-cell inventory, pricing, and GS1 code support. Dolibarr has no grid or matrix product view. We split each Paragon grid row into a separate Dolibarr product, which is the structurally correct approach but requires a size-run inventory count during discovery to identify all active variant combinations. If the migration skips this step, size variants are missed and on-hand quantities end up misallocated. We include a mandatory variant inventory audit as part of the discovery phase for every apparel Paragon migration.

  • Dolibarr CSV imports from other Dolibarr instances fail on field mismatches

    Dolibarr's native import wizard has a known issue when attempting to import data exported from another Dolibarr installation: field numbers and column definitions do not align cleanly, causing row-level rejection. While this is a Dolibarr intra-platform gotcha rather than a Paragon-specific issue, it matters here because our migration preparation scripts generate CSV files in Dolibarr-compatible column order. We validate every generated CSV against a test Dolibarr instance before production import, ensuring field numbers and data types match before any batch upload. Raw exports from Paragon that pass through without this validation step will fail.

  • Paragon screen setup requirements have no Dolibarr analog

    Paragon requires transaction screens (orders, POs, shipments, invoices) to be configured before the transaction import step can succeed. This is a Paragon prerequisite that does not map to any Dolibarr concept because Dolibarr does not require pre-configuration of screen definitions before import. However, the inverse is true for Dolibarr: some Dolibarr modules (Accounting, Projects, Stock) require the module to be enabled and basic account or warehouse configuration to exist before import files referencing those modules are accepted. We include a module-enablement and configuration checklist as part of every Dolibarr migration discovery phase.

Migration approach

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

  1. Discovery and attribute audit

    We audit the Paragon ERP instance across items (including all active Style/Color/Size grid combinations), customers, vendors, orders (open and historical), inventory locations, departments and entities, active attribute definitions, and association records. We filter abandoned attributes immediately to produce a cleaned attribute list. We identify any EDI or PO configuration that needs to be documented for manual rebuild. We review Dolibarr's module state (Warehouse, Customer Relationship, Sales, Purchases, Accounting, Projects) and confirm which modules the customer wants active. The discovery output is a written migration scope, a cleaned attribute list, and a Dolibarr module-enablement checklist.

  2. Schema design and variant split planning

    We design the target Dolibarr schema based on the discovery output. This includes creating the warehouse records (mapped from Paragon Locations), provisioning Third Party records for customers and vendors, configuring Dolibarr Categories to replicate the Paragon department structure, planning the apparel grid variant split (one configurable parent product per grid plus one child product per Size/Color combination), and mapping the Paragon entity segmentation to either Dolibarr multi-company configuration or category-based segmentation. All schema elements are deployed into a test Dolibarr instance for validation before production.

  3. Sandbox migration and reconciliation

    We run a full migration into a test Dolibarr instance using production-like data volume. The customer's operations lead reconciles record counts (products in, customers in, vendors in, open orders in, inventory levels in), spot-checks 30–50 records per object against the Paragon source, and confirms the apparel variant split is complete. Any mapping corrections, missing attributes, or variant gaps identified during reconciliation are resolved before production migration begins. This step is particularly important for apparel grids because missed variant rows are difficult to add post-migration without disrupting inventory counts.

  4. Owner and vendor reconciliation

    We extract every distinct Paragon user referenced as an order owner, customer relationship owner, or assignment on any record. We match by email against the target Dolibarr User table. Any Paragon user without a matching Dolibarr User goes to a reconciliation queue for the customer's admin to provision. Similarly, vendor codes referenced on Paragon inventory or PO records are reconciled against the migrated vendor Third Party list before inventory and purchasing migrations proceed.

  5. Production migration in dependency order

    We run production migration in record-dependency order: Warehouses (from Paragon Locations), Third Parties (customers and vendors), Products with apparel variant split applied, Stock levels per warehouse, Open Customer Orders, Open Supplier Orders, AP/AR balances, and finally historical orders if the customer has requested historical data. Each phase emits a row-count reconciliation report before the next phase begins. We normalize all Paragon date fields to YYYY-MM-DD during transformation and validate each CSV against Dolibarr's field-numbering expectations before batch upload.

  6. Cutover, validation, and configuration handoff

    We freeze Paragon write access 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 Paragon screen configurations and EDI/PO setup that requires rebuild in Dolibarr, along with a recommendation for any Dolibarr community modules that replace missing integrations (Shopify, WooCommerce). We support a one-week hypercare window where we resolve any record-level reconciliation issues. We do not rebuild Paragon configurations as Dolibarr workflows or automations inside the migration scope; those are documented for the customer's admin to implement.

Platform deep dives

Context on both ends of the pair

Paragon ERP logo

Paragon ERP

Source

Strengths

  • Universal Translator enables bulk import and export of inventory, associations, addresses, and transaction data without per-record manual entry.
  • Cloud-native delivery with frequent updates and no on-premise infrastructure requirements for SMB customers.
  • Style/Color/Size grid support with apparel-specific features (GS1 codes, Canadian tax, cut-and-sold reports) differentiates it from horizontal ERPs.
  • Native integrations with Shopify, WooCommerce, QuickBooks Online, NuOrder, EDI, and Xperience API reduce middleware dependencies.
  • Multi-entity and multi-location GL structure supports companies operating multiple DBAs across several warehouses under one legal entity.

Weaknesses

  • Requires attributes and screen setup to be configured before importing new data, creating a sequential dependency that adds planning steps to migration timelines.
  • Association exports include all attributes even those created but abandoned, producing oversized files that require manual filtering before re-import.
  • Error messages during import failures are not always self-explanatory, often requiring Paragon support engagement to diagnose the root cause.
  • Slow performance reported on large data exports and system restores, suggesting throughput limitations on bulk data operations for high-volume inventory sites.
  • Per-user pricing model lacks documented volume discounts, making cost projections uncertain for growing teams beyond the initial deployment size.
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. 3 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 Paragon ERP and Dolibarr ERP.

  • Object compatibility

    B

    3 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

    Paragon ERP: Not publicly documented.

  • Data volume sensitivity

    A

    Paragon ERP exposes a bulk API — large-volume migrations stream efficiently.

Estimator

Estimate your Paragon 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 Paragon ERP to Dolibarr ERP data migrations

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

Can't find your answer?

Walk through your Paragon ERP to Dolibarr ERP migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Straightforward migrations with under 5,000 items, no apparel grids, and no multi-entity Paragon structure land in 5–8 weeks. Migrations with active Style/Color/Size grids requiring variant split, multi-entity department and location segmentation, large open-order backlogs, or complex attribute namespaces requiring abandoned-attribute filtering move to 11–17 weeks. The apparel variant split during discovery and sandbox validation adds 1–2 weeks to the front end of the timeline compared to non-apparel migrations.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Paragon 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