ERP migration
Field-level mapping, validation, and rollback between Proteus ERP and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.
Proteus ERP
Source
Dolibarr ERP
Destination
Compatibility
10 of 12
objects map 1:1 between Proteus ERP and Dolibarr ERP.
Complexity
BStandard
Timeline
3-6 weeks
Overview
Moving from Proteus ERP to Dolibarr is an all-in-one ERP to open-source modular ERP migration. Proteus ERP has no publicly documented API, so all data extraction relies on the platform's built-in CSV export utility; we handle large transaction histories by chunking exports into date-range or category-scoped batches, validating each independently before proceeding. Dolibarr's modular architecture means we activate only the modules matching the customer's active Proteus modules—CRM, invoicing, inventory, accounting, HR, projects, and POS—and we flag which Dolibarr modules require activation before data lands. We preserve multi-revenue-center inventory assignments as Dolibarr warehouse locations, map the Proteus GST-compliant Chart of Accounts through a translation table, and deliver a written inventory of Proteus custom fields requiring Dolibarr extra-fields configuration. Workflows, automations, e-commerce storefront configurations, and POS terminal settings do not migrate; we deliver a written map for the customer's admin to rebuild in Dolibarr.
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 Proteus 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.
Proteus ERP
Customer
Dolibarr ERP
ThirdParty (llx_societe)
1:1Proteus ERP customer records map to Dolibarr ThirdParty objects. Contact data (name, email, phone, address) migrates directly. Buying habits and referral source fields from Proteus map to Dolibarr extra-fields that we configure during scoping. If the customer uses Proteus's CRM module, we also create Dolibarr Contact records linked to the ThirdParty. Deduping uses email as the primary key.
Proteus ERP
Vendor
Dolibarr ERP
ThirdParty (llx_societe) with Supplier flag
1:1Proteus ERP vendor records map to Dolibarr ThirdParty with the Supplier type flag set. Vendor code mapping requires a collision check against existing Dolibarr supplier records; we prefix vendor codes with VND- during import if collisions are detected.
Proteus ERP
Item (Inventory)
Dolibarr ERP
Product (llx_product)
1:1Proteus ERP item records (SKU, description, stock levels, pricing tiers, revenue center assignments) map to Dolibarr Product records. Multi-revenue-center flags from Proteus translate to Dolibarr warehouse locations (stock per warehouse). Pricing tiers map to Dolibarr price lists attached to the Product. We create warehouse records in Dolibarr before product import so stock levels land in the correct location.
Proteus ERP
Sales Order
Dolibarr ERP
Order (llx_commande)
1:1Open and historical sales orders map to Dolibarr Orders. Header fields (customer reference, order date, status) migrate directly. Line items require the Product reference resolved to Dolibarr Product IDs at migration time. We stage product imports before order imports so that line items resolve without orphan references. Historical orders beyond two years may be scoped to archive-only migration to reduce file size.
Proteus ERP
Purchase Order
Dolibarr ERP
Supplier Order (llx_commande_fournisseur)
1:1Purchase orders map to Dolibarr Supplier Orders linked to the vendor ThirdParty record. PO-to-receive linkage migrates to Dolibarr's receipt workflow (receptions). Line items resolve against the Product table using SKU as the dedupe key.
Proteus ERP
Invoice
Dolibarr ERP
Invoice (llx_facture)
1:1Proteus ERP invoices map to Dolibarr Customer Invoices. GST/HST tax data from Proteus requires mapping to Dolibarr's VAT configuration. Payment status (paid, unpaid, partial) migrates to Dolibarr payment condition fields. Historical invoices beyond two years are date-range scoped based on the customer's reporting needs. We create the corresponding third party and product records before invoice import to satisfy foreign key constraints.
Proteus ERP
Chart of Accounts
Dolibarr ERP
Account (llx_accounting_account)
1:1Proteus ERP's GST-compliant Chart of Accounts maps to Dolibarr's accounting module accounts. We build a COA translation table during scoping that aligns Proteus account codes and segment lengths to Dolibarr's account numbering convention (typically 6-digit numeric). Revenue, expense, asset, and liability accounts map individually; any accounts without a Dolibarr equivalent are flagged for the customer's admin to configure post-migration.
Proteus ERP
Employee
Dolibarr ERP
User (llx_user)
1:1Proteus ERP employee records map to Dolibarr User objects. HR data (name, role, department, pay grade) migrates as User properties. Dolibarr's HR module must be activated if the customer wants leave tracking, expense reporting, or salary history to migrate; if HR is not active, we import employees as User records only.
Proteus ERP
E-commerce Order
Dolibarr ERP
Order (llx_commande)
1:manyProteus ERP e-commerce orders are split by sales channel in the export. We merge channel-specific order records into a single Dolibarr Order per transaction, tagging the order source in an extra-field for reporting. Line items resolve against the Product table. Inventory deduction migrates as stock movement records in Dolibarr.
Proteus ERP
POS Transaction
Dolibarr ERP
Bank Statement Line + Product Movement
1:1POS transactions from Proteus ERP map to Dolibarr cash reconciliation records. Transaction-level sales data creates Dolibarr bank statement line entries; the linked inventory reduction migrates as Product stock movements. We coordinate with the customer to identify their primary cash drawer or bank account as the Dolibarr target.
Proteus ERP
Custom Fields
Dolibarr ERP
Extra-fields (llx_accounting_extra, llx_product_extrafields, etc.)
lossyProteus ERP custom fields added within CRM, accounting, or inventory modules are not included in the default export. During scoping we request a full field export including custom columns and map each to a Dolibarr extra-field of the equivalent type (string, integer, select, date, checkbox). We pre-create the extra-field definitions in Dolibarr before any record import so that data lands in the correct custom property on first write.
Proteus ERP
Owner / User
Dolibarr ERP
User (llx_user)
1:1Proteus ERP owner or user records referenced on orders, invoices, and tasks map to Dolibarr User accounts. We resolve by email match against the Dolibarr destination User table. Any Proteus owner without a matching Dolibarr User goes to a reconciliation queue for the customer to provision before record import continues.
| Proteus ERP | Dolibarr ERP | Compatibility | |
|---|---|---|---|
| Customer | ThirdParty (llx_societe)1:1 | Fully supported | |
| Vendor | ThirdParty (llx_societe) with Supplier flag1:1 | Fully supported | |
| Item (Inventory) | Product (llx_product)1:1 | Fully supported | |
| Sales Order | Order (llx_commande)1:1 | Fully supported | |
| Purchase Order | Supplier Order (llx_commande_fournisseur)1:1 | Fully supported | |
| Invoice | Invoice (llx_facture)1:1 | Fully supported | |
| Chart of Accounts | Account (llx_accounting_account)1:1 | Mapping required | |
| Employee | User (llx_user)1:1 | Fully supported | |
| E-commerce Order | Order (llx_commande)1:many | Fully supported | |
| POS Transaction | Bank Statement Line + Product Movement1:1 | Fully supported | |
| Custom Fields | Extra-fields (llx_accounting_extra, llx_product_extrafields, etc.)lossy | Fully supported | |
| Owner / User | User (llx_user)1: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.
Proteus ERP gotchas
No publicly documented API forces direct database work
Export file sizes can fragment large transaction histories
Custom fields are not exposed in the standard export
No public pricing page creates billing uncertainty
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 audit
We audit the source Proteus ERP environment: active modules (CRM, accounting, inventory, HR, e-commerce, POS), record counts per entity type, custom field inventory, COA structure, and any negotiated contract terms that affect export limits. We pair this with a Dolibarr module activation plan that mirrors the customer's active Proteus footprint. The discovery output is a written migration scope with record counts, a Dolibarr module checklist, and a custom field mapping sheet.
Dolibarr environment staging
We set up a Dolibarr staging instance (on the customer's chosen hosting or a DoliCloud trial) and activate the required modules: ThirdParty/Contact for customers and vendors, Product for items, Commercial for orders and invoices, Stock for inventory, Accounting for the chart of accounts, and User/HR for employees. We pre-create extra-field definitions for every custom Proteus field identified in discovery so that the import framework writes to typed custom properties from the first batch onward.
Data export in staged batches
We extract Proteus ERP data using the built-in CSV export utility. For large datasets, we chunk exports by date range (quarters or half-years) or category scope, validate row counts and column headers per batch, and run a sample reconciliation against the source before proceeding. Custom fields are requested as a separate full-field export. Export files are staged in a secure workspace for transform and import.
Transform and field mapping
We transform each batch through a mapping layer that aligns Proteus CSV columns to Dolibarr fields. Key transform decisions include: multi-revenue-center flags to Dolibarr warehouse locations, GST account codes through the COA translation table, Proteus customer and vendor status to Dolibarr ThirdParty status, and any enum values (order status, payment terms) to Dolibarr picklist equivalents. The transform output is a Dolibarr-compatible CSV per entity type, ready for import via Dolibarr's native import tool or direct database insert.
Import in dependency order with reconciliation
We import in record-dependency order: ThirdParties (customers and vendors first, because they are referenced on orders and invoices), Products with warehouse stock levels, Accounting accounts, then Orders, Purchase Orders, Invoices, Employee Users, and E-commerce/POS records. Each phase emits a row-count reconciliation report against the source extract before the next phase begins. We resolve all foreign key references (Product IDs on line items, ThirdParty IDs on orders) before closing each phase.
Cutover, validation, and automation handoff
We freeze Proteus ERP writes during the cutover window, run a final delta migration of any records modified during the migration window, then mark Dolibarr as the system of record. We deliver a written inventory of Proteus custom fields, any manual COA account creates required, and a Dolibarr module activation checklist for the customer's admin to complete. We do not rebuild Proteus workflows, automations, or e-commerce storefront settings in Dolibarr; that inventory is documented for the customer's team or a Dolibarr integrator to address as a separate configuration task. We support a one-week post-cutover window to resolve reconciliation discrepancies.
Platform deep dives
Proteus 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 Proteus 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
Proteus ERP: Not publicly documented.
Data volume sensitivity
Proteus 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 Proteus ERP to Dolibarr ERP migration scoping. Not seeing yours? Book a call.
Walk through your Proteus 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 Proteus 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.