ERP migration
Field-level mapping, validation, and rollback between inoERP and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.
inoERP
Source
Dolibarr ERP
Destination
Compatibility
11 of 13
objects map 1:1 between inoERP and Dolibarr ERP.
Complexity
BStandard
Timeline
4-7 weeks
Overview
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.
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 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
Dolibarr ERP
Accounting - Chart of Accounts
1:1inoERP'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
Dolibarr ERP
Accounting - Journal
1:1inoERP 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
Dolibarr ERP
Third Parties (Customers and Suppliers) + Invoices
1:manyinoERP 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
Dolibarr ERP
Products/Services (stock enabled)
1:1inoERP 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
Dolibarr ERP
Customer Orders
1:1inoERP 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
Dolibarr ERP
Supplier Orders
1:1inoERP 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
Dolibarr ERP
Production Orders (via MRP extension)
1:1inoERP 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
Dolibarr ERP
BOMs (via production module)
1:1inoERP 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
Dolibarr ERP
HR Module (Employees)
1:1inoERP 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
Dolibarr ERP
Users
1:1inoERP 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
Dolibarr ERP
Asset Module
1:1inoERP 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
Dolibarr ERP
Payroll Module (where activated)
1:1inoERP 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
Dolibarr ERP
Extra Fields (Dolibarr's custom field system)
lossyinoERP 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.
| inoERP | Dolibarr ERP | Compatibility | |
|---|---|---|---|
| Chart of Accounts | Accounting - Chart of Accounts1:1 | Fully supported | |
| Journal Entries | Accounting - Journal1:1 | Mapping required | |
| Accounts Receivable / Accounts Payable | Third Parties (Customers and Suppliers) + Invoices1:many | Mapping required | |
| Items / Inventory | Products/Services (stock enabled)1:1 | Fully supported | |
| Sales Orders | Customer Orders1:1 | Fully supported | |
| Purchase Orders | Supplier Orders1:1 | Fully supported | |
| Work Orders / WIP | Production Orders (via MRP extension)1:1 | Mapping required | |
| Bills of Material / Routings | BOMs (via production module)1:1 | Fully supported | |
| Employees / HR | HR Module (Employees)1:1 | Mapping required | |
| Users / Roles | Users1:1 | Mapping required | |
| Asset Accounting | Asset Module1:1 | Fully supported | |
| Payroll / Bank Files | Payroll Module (where activated)1:1 | Mapping required | |
| Custom Fields / Extended Attributes | Extra Fields (Dolibarr's custom field system)lossy | 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.
inoERP gotchas
Architecture version split between PHP and Go/Flutter
OneApp API has no publicly documented rate limits
Closed-order and historical transaction volume drives migration scope
Dynamic pull system recalculates lot sizes at runtime
Self-hosting creates data export dependency on the customer
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
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.
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.
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.
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.
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.
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
inoERP
Source
Strengths
Weaknesses
Dolibarr ERP
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. All 8 core objects map 1:1 between inoERP and Dolibarr ERP.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across inoERP and Dolibarr ERP.
Object compatibility
All 8 core objects map 1:1 between inoERP and Dolibarr ERP.
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
inoERP: Not publicly documented.
Data volume sensitivity
inoERP 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 inoERP to Dolibarr ERP migration scoping. Not seeing yours? Book a call.
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 consultationAdjacent paths
Other ways to leave inoERP
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.