ERP migration

Migrate from inoERP to Dolibarr ERP

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

inoERP logo

inoERP

Source

Dolibarr ERP

Destination

Dolibarr ERP logo

Compatibility

85%

11 of 13

objects map 1:1 between inoERP and Dolibarr ERP.

Complexity

BStandard

Timeline

4-7 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from inoERP to Dolibarr is a simplification migration: Dolibarr is a lighter, modular ERP built for SMEs and freelancers, while inoERP is a full-stack ERP with Oracle R12 and SAP-level ambition including dynamic pull-based MRP. The most significant gap is manufacturing: inoERP's BOM, work order, WIP, and MRP modules have no fully equivalent Dolibarr counterpart outside of the optional MRP extension, and historical MRP-generated planning records reflect historical demand conditions that should be re-run post-migration rather than imported verbatim. We extract from inoERP's MySQL or MariaDB database directly, map the chart of accounts and journal entries to Dolibarr's accounting module, convert inoERP's customer and supplier structures into Dolibarr's unified third-party model, and preserve work order history as reference records even where Dolibarr's production module has limited capability. Workflows, automations, custom PHP extensions, and file attachment paths do not migrate; we deliver a written inventory for the customer's admin to rebuild. The source architecture version (PHP legacy vs Go/Flutter OneApp) must be confirmed before scoping because the database schemas differ.

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

inoERP logo

inoERP

What's pushing teams away

  • The project management module is incomplete and underdeveloped, frustrating organisations that need integrated project tracking alongside operations.
  • Documentation is sparse and community support is limited, making troubleshooting configuration issues and customisation challenges time-consuming for self-hosted deployments.
  • The platform has undergone a major architecture migration from PHP to Go back-end with a Flutter front-end, creating confusion about which version to deploy and whether older PHP documentation still applies.
  • Hosting, maintaining, and securing a self-managed ERP falls on the customer's team, generating hidden labour costs that often exceed the savings from free licensing.

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

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

inoERP

Chart of Accounts

maps to

Dolibarr ERP

Accounting - Chart of Accounts

1:1
Fully supported

inoERP's GL chart of accounts with account codes, types, descriptions, and currency assignments maps directly to Dolibarr's accounting module. The account type hierarchy (Asset, Liability, Equity, Revenue, Expense) maps to Dolibarr's account classification. We export account codes, descriptions, types, and current balances. Roll-forward balances require a year-end adjustment entry in Dolibarr's accounting module rather than a direct balance import.

inoERP

Journal Entries

maps to

Dolibarr ERP

Accounting - Journal

1:1
Mapping required

inoERP journal entries include header data (entry date, reference, description) and line-level data (account, debit, credit, cost center). We export all posted entries and flag entries with non-standard dimensions (like multi-company segments) that have no Dolibarr equivalent. Dolibarr's journal model supports basic entries but does not natively support inter-company journals or cost center consolidation; entries with these dimensions require manual post-processing in Dolibarr or a custom extension.

inoERP

Accounts Receivable / Accounts Payable

maps to

Dolibarr ERP

Third Parties (Customers and Suppliers) + Invoices

1:many
Mapping required

inoERP separates AR and AP as distinct subledgers with party records, invoice headers, and line items. Dolibarr consolidates customers and suppliers into a single Third Parties module with a Type field (Customer, Supplier, or both). We map inoERP's customer records to Dolibarr Third Parties with Type=Customer, and supplier records to Type=Supplier. Open AR/AP invoices migrate as Dolibarr Customer Proposals (quotes) converted to invoices, or as direct invoice records. Invoice status (open, paid, overdue) carries forward as Dolibarr status values.

inoERP

Items / Inventory

maps to

Dolibarr ERP

Products/Services (stock enabled)

1:1
Fully supported

inoERP item definitions with UOM, cost layers, category hierarchies, and on-hand quantities map to Dolibarr Products with stock management enabled. Multi-location on-hand quantities map to Dolibarr's multi-warehouse stock tracking. Lot and serial number traceability requires the Lot/Serial module extension in Dolibarr. We export item definitions, on-hand balances, and location assignments, and flag items with complex cost layer structures that may need simplification in Dolibarr's single cost price model.

inoERP

Sales Orders

maps to

Dolibarr ERP

Customer Orders

1:1
Fully supported

inoERP Sales Orders with header fields (dates, terms, party references) and line items (item, quantity, price, warehouse) map to Dolibarr Customer Orders. We export open orders by status and map inoERP order status to Dolibarr order status. Closed sales orders are mapped to Dolibarr Customer Order records with a Closed status for historical reference, or excluded from migration per the customer's date-range preference during scoping. Shipping address and payment terms carry forward as line-item and header attributes.

inoERP

Purchase Orders

maps to

Dolibarr ERP

Supplier Orders

1:1
Fully supported

inoERP Purchase Orders map to Dolibarr Supplier Orders using the same header and line structure as Sales Orders. We map inoERP's supplier references, lead times, and receipt status to Dolibarr fields. Closed purchase orders follow the same date-range migration logic as sales orders. Multi-unit purchase orders (orders placed in a different UOM than stock) require UOM conversion mapping at migration time.

inoERP

Work Orders / WIP

maps to

Dolibarr ERP

Production Orders (via MRP extension)

1:1
Mapping required

inoERP work orders include routing steps, material issues, resource transactions, and completion records, with a WIP ledger aggregating costs per work order. Dolibarr's production module (available as a module extension) supports basic production orders but does not include a WIP ledger, multi-level routing steps, or resource capacity planning. We export full work order history as Dolibarr Production Order records with bill of materials linkage. The WIP cost aggregation is flagged as a custom field (wip_total_cost__c) on the Production Order for reference rather than a native accounting ledger entry. Historical MRP-generated planning records are flagged as Plan-Generated and should be re-run in Dolibarr post-migration rather than imported verbatim because inoERP's dynamic pull-based MRP recalculates lot sizes at runtime against historical demand conditions.

inoERP

Bills of Material / Routings

maps to

Dolibarr ERP

BOMs (via production module)

1:1
Fully supported

inoERP BOMs with multi-level structures, super BOMs, and phantom assemblies map to Dolibarr BOM definitions. Routing sequences map to Dolibarr BOM line order. We export the full BOM hierarchy and flag phantom BOMs and costed BOMs that require the production module's cost calculation extension in Dolibarr. Phantom sub-assemblies in inoERP map to Dolibarr BOM lines with the phantom flag where supported. Multi-level BOM flattening is available as a pre-migration step if Dolibarr's single-level BOM model creates display issues.

inoERP

Employees / HR

maps to

Dolibarr ERP

HR Module (Employees)

1:1
Mapping required

inoERP HR includes employee profiles, job definitions, positions, leave balances, and approval hierarchies. Dolibarr's HR module (requires activation) supports employee records with contact details, job title, and contract type but has limited support for compensation history and complex approval chains. We export employee data and position assignments. Compensation history (salary records, bonuses) is flagged as a custom field set requiring manual entry in Dolibarr or a custom HR extension. Leave balances export as Dolibarr HR leave entries where the module is activated.

inoERP

Users / Roles

maps to

Dolibarr ERP

Users

1:1
Mapping required

inoERP role-based access control with users, roles, and permissions maps to Dolibarr Users and permission groups. We export user accounts and role assignments. Mappings must translate inoERP permission strings to Dolibarr's permission model, which uses a module-level permission grant system rather than named roles. We flag any inoERP role that does not map directly to a Dolibarr permission group and provide a permission matrix for the customer to assign post-migration. Active vs inactive user status carries forward.

inoERP

Asset Accounting

maps to

Dolibarr ERP

Asset Module

1:1
Fully supported

inoERP asset registers with acquisition details, depreciation schedules, and asset categories map directly to Dolibarr's Asset module. We export the full asset record including acquisition cost, in-service date, depreciation method, accumulated depreciation, and book value. Depreciation methods (straight-line, declining balance) map to Dolibarr's supported depreciation calculation methods. Asset categories map to Dolibarr asset classification.

inoERP

Payroll / Bank Files

maps to

Dolibarr ERP

Payroll Module (where activated)

1:1
Mapping required

inoERP payroll generates electronic bank files for direct deposit. Dolibarr's payroll module is an optional extension with basic salary and deduction management. We export payroll registers, leave balances, and compensation history as Dolibarr salary records where the module is activated. Bank file formats are flagged as non-migratable because inoERP generates custom-format files; the customer should configure Dolibarr's bank transfer module or use a separate payroll tool for direct deposit generation.

inoERP

Custom Fields / Extended Attributes

maps to

Dolibarr ERP

Extra Fields (Dolibarr's custom field system)

lossy
Fully supported

inoERP extended attributes on any object map to Dolibarr's Extra Fields system (core_extrafields table). We export the field definitions (name, type, options) and values per record. Dolibarr's Extra Fields support varchar, text, int, float, date, datetime, select, checkbox, and link types. Complex inoERP extended fields (like formula-based calculations) are flagged as requiring post-migration review because Dolibarr does not support formula-driven calculated fields natively.

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.

inoERP logo

inoERP gotchas

High

Architecture version split between PHP and Go/Flutter

Medium

OneApp API has no publicly documented rate limits

Medium

Closed-order and historical transaction volume drives migration scope

Low

Dynamic pull system recalculates lot sizes at runtime

Low

Self-hosting creates data export dependency on the customer

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

  • inoERP PHP vs Go architecture version must be confirmed before scoping

    inoERP has two distinct codebases: the legacy PHP version and the newer OneApp version built on a Go back-end with a Flutter front-end. The database schemas differ between versions, and community documentation is fragmented across both. We confirm which version the source system runs during scoping by checking the database schema and file system structure. Extracting from the wrong schema produces corrupt mappings that corrupt the Dolibarr target. Customers running the Go/Flutter version may also have fewer community resources to reference during migration discovery.

  • Dolibarr production module does not replicate inoERP's dynamic pull MRP

    inoERP's dynamic pull-based MRP recalculates Kanban lot sizes at each supply trigger, meaning historical MRP-generated planning records reflect demand conditions that may not be valid in any destination system. Dolibarr's production module (an optional extension) supports basic BOM-based production orders but has no dynamic lot-sizing logic, no WIP ledger, and no multi-level routing with resource capacity planning. We export work order history as reference records and flag MRP-generated records as Plan-Generated. The customer's team re-runs planning in Dolibarr's MRP extension post-migration rather than importing historical planning output.

  • Dolibarr's basic accounting lacks multi-currency and inter-company consolidation

    inoERP's GL module supports multi-currency journal entries and cost center hierarchies that Dolibarr's basic accounting module does not natively provide. Organizations with multi-currency AR/AP or inter-company journal entries must either simplify to single-currency entries during migration or procure a Dolibarr accounting extension from the marketplace. We identify all multi-currency and inter-company records during discovery and present the simplification options before migration begins.

  • Closed-order and historical transaction volume materially affects scope

    inoERP does not enforce record-retention limits. Organizations running inoERP for several years often accumulate thousands of closed sales orders, purchase orders, and work orders. Migrating all closed historical orders increases migration time and target database size with limited operational value. We scope all transactional history explicitly during discovery and offer selective date-range filtering so customers choose which historical closed orders are migrated versus re-created manually in Dolibarr for audit purposes only.

  • Dolibarr CSV import is table-by-table and requires correct column ordering

    Dolibarr's built-in import tool processes CSV files one table at a time with limited validation and no automated dependency resolution. We use the Dolibarr REST API for most object inserts, but the API requires parent-record existence before child records can be linked. We sequence the migration in strict dependency order: third parties before orders, orders before invoices, BOMs before production orders, accounts before journal entries. Any import failures caused by missing parent records require re-sequencing or manual pre-creation in Dolibarr.

Migration approach

Six steps for a successful inoERP to Dolibarr ERP data migration

  1. Architecture version confirmation and database access

    We confirm whether the source inoERP instance runs the PHP legacy codebase or the Go/Flutter OneApp version by inspecting the database schema and file system structure. We require read access to the MySQL or MariaDB database instance, or a database dump file. In deployments where the database server is on an internal network without external connectivity, the customer sets up VPN access or runs our migration agent on-premises before we begin extraction. This step gates all subsequent work because the wrong schema assumption corrupts the entire mapping.

  2. Discovery, date-range scoping, and Dolibarr module activation plan

    We audit the inoERP source across every module: chart of accounts and GL balances, AR/AP open items, closed order history, work order and BOM inventory, employee records, asset registers, and any extended attribute definitions. We scope transactional history by date range based on the customer's audit and operational requirements, and identify which Dolibarr modules to activate (Third Parties, Products, Stock, Customer Orders, Supplier Orders, BOMs, Production, HR, Accounting, Assets). The discovery output is a written migration scope with object counts, date-range filters, and a Dolibarr module activation checklist.

  3. Schema design and destination configuration in Dolibarr

    We configure the Dolibarr destination instance before any data loads: activate required modules, set the chart of accounts structure, configure tax rules and payment terms, define product categories and warehouse locations, set up user accounts and permission groups, and create extra field definitions for any inoERP extended attributes that have no native Dolibarr equivalent. The production module is activated if BOM and production order migration is in scope. We run this configuration in a clean Dolibarr instance, not against a pre-populated demo database.

  4. Sandbox migration and reconciliation

    We run a full migration into a test Dolibarr instance using production-like data volumes. The customer reconciles record counts per object, spot-checks 25-50 records against the inoERP source (account balances, order totals, employee names, asset book values), and validates that Dolibarr's calculated totals match source totals for open AR/AP. Any mapping corrections, missing fields, or extra field configuration gaps surface here before production migration begins. No production data moves until the sandbox sign-off is received.

  5. Production migration in dependency order

    We run production migration in strict record-dependency order: Third Parties (customers and suppliers), then Products (items with stock), then BOM definitions, then Customer and Supplier Orders (open and optionally closed by date range), then Production Orders and work order history, then accounting journal entries and AR/AP open items, then Employees and HR records, then Asset registers, then extra field values last. Each phase emits a row-count reconciliation report before the next phase begins. The Bulk API or direct database insert approach is used based on volume; adaptive throttling and exponential backoff handle any rate-limit responses.

  6. Cutover, delta migration, and automation inventory delivery

    We freeze inoERP writes during cutover, run a final delta migration of any records created or modified during the migration window, then hand off Dolibarr as the system of record. We deliver a written inventory of every inoERP workflow, automation, and custom PHP extension requiring rebuild in Dolibarr's module system, plus a BOM flattening recommendation if the customer's multi-level structures do not display cleanly in Dolibarr. We support a one-week hypercare window for reconciliation issues. We do not rebuild inoERP workflows or automations inside the migration scope; that is a separate engagement.

Platform deep dives

Context on both ends of the pair

inoERP logo

inoERP

Source

Strengths

  • 100% free and open source with no per-user or per-module licensing fees.
  • Full ERP stack covering Finance, SCM, Manufacturing, and HR in a single integrated system.
  • Dynamic pull-based MRP adapts lot sizes to real-time demand changes rather than using fixed Kanban quantities.
  • Multi-database support including Oracle 12c, MySQL, and MariaDB on Windows, macOS, and Linux.
  • Mobile clients available for Android, iOS, macOS, Windows, and web browsers.

Weaknesses

  • Sparse official documentation and limited community support make self-hosting challenging.
  • Project Management module is under development and not yet production-ready.
  • Major architecture shift from PHP to Go/Flutter has created documentation fragmentation.
  • Self-hosting model shifts infrastructure labour costs to the customer, often negating free-licensing savings.
  • Very limited third-party review coverage and few public case studies demonstrating real-world deployments.
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. All 8 core objects map 1:1 between inoERP and Dolibarr ERP.

B

Overall complexity

Standard migration

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

  • Object compatibility

    A

    All 8 core objects map 1:1 between inoERP and Dolibarr ERP.

  • 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

    inoERP: Not publicly documented.

  • Data volume sensitivity

    B

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

Estimator

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

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

Can't find your answer?

Walk through your inoERP 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 seven weeks for straightforward scopes under 15,000 records with no work orders, single-level BOMs, and a single currency. Migrations with multi-level BOMs, work order history, large closed-order volumes (over 5,000 records), multi-currency AR/AP, or HR compensation record complexity move to ten to sixteen weeks because of BOM flattening work, MRP record flagging scope, and accounting simplification requirements.

Adjacent paths

Related migrations to explore

Ready when you are

Move from inoERP.
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