ERP migration
Field-level mapping, validation, and rollback between Solution ERP and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.
Solution ERP
Source
Dolibarr ERP
Destination
Compatibility
12 of 13
objects map 1:1 between Solution ERP and Dolibarr ERP.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Solution ERP to Dolibarr is primarily a cost and complexity transition driven by Gulf-market businesses seeking open-source flexibility over regional licensing. Solution ERP charges per user per month in QAR with tiered module access, while Dolibarr's core platform is free to download with optional paid cloud hosting from €9 per user per month. The migration requires resolving Gulf-specific VAT and excise tax codes that have no Dolibarr native equivalent, segmenting multi-site records into separate Dolibarr entities where applicable, and reclassifying Solution ERP POS transaction logs into standard invoice and cost-of-goods-sold journal lines. We sequence Vendors before AP ledger entries, preserve project cost centres as Dolibarr third-party projects, and quarantine historical records older than three to five years for cleaning before import. We do not migrate Solution ERP workflows, POS automation rules, or custom Gulf-specific integrations as code; we deliver a written inventory of these for the customer's admin to rebuild in Dolibarr's module activation model.
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 Solution 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.
Solution ERP
Chart of Accounts
Dolibarr ERP
Bank - Account, Third Party - Account (configuration required)
1:1Account codes, names, and hierarchies transfer cleanly from Solution ERP into Dolibarr's accounting module. Gulf-specific VAT and Services excise tax codes that have no native Dolibarr equivalent require extension development or manual chart-of-accounts mapping. We extract the full tax code catalogue during scoping, build a mapping table to Dolibarr's closest equivalent accounts or VAT product types, and flag any codes with no destination match for the customer's accountant to resolve before import. Active versus inactive account flags map to the active checkbox in Dolibarr's account record.
Solution ERP
Customers
Dolibarr ERP
Third Party (type: Customer)
1:1Customer records including company name, contact details, addresses, and payment terms migrate as Dolibarr Third Party records with the Customer flag enabled. Arabic company names are preserved in UTF-8 encoding throughout the migration; we verify that the destination Dolibarr instance's character set supports full Unicode before import and confirm RTL rendering configuration with the hosting provider if Arabic-language interface is active. Payment terms migrate to Dolibarr's condiciones de pago (payment conditions) lookup.
Solution ERP
Vendors
Dolibarr ERP
Third Party (type: Supplier)
1:1Vendor master records including tax registration numbers, IBAN and bank account details, and addresses migrate as Dolibarr Third Party records with the Supplier flag enabled. We validate IBAN format against the destination country's banking standards for any vendors outside the Gulf region. Tax registration numbers migrate as a custom field or into the TVA/SIRET equivalent depending on whether the vendor is EU-based or Gulf-based, since tax registration field semantics differ between jurisdictions.
Solution ERP
Items
Dolibarr ERP
Product (type: Stock and/or Service)
1:1Items with pricing, stock levels, and unit-of-measure hierarchies require unit-of-measure mapping between the two systems as naming conventions differ. Solution ERP's stock quantity and warehouse assignments map to Dolibarr's product stock levels and entrepots. Products that are services rather than physical goods are flagged with the Service type in Dolibarr to bypass stock management. SKU (hs_sku equivalent in Solution ERP) maps to the ref field in Dolibarr Product.
Solution ERP
Open AP/AR
Dolibarr ERP
Supplier Invoice (AP) and Customer Invoice (AR)
1:1Outstanding payables and receivables require careful date-range scoping around the migration cutoff. We match open invoice numbers from Solution ERP to prevent duplicate creation in Dolibarr and flag any partial payments that span the migration date. Outstanding AR balances post as Dolibarr Customer Invoice records in open status; outstanding AP balances post as Supplier Invoice records. Historical paid invoices are migrated last as closed records to maintain audit continuity without cluttering open aging reports.
Solution ERP
Historical Transactions
Dolibarr ERP
Accounting Entry (Ecriture Comptable)
1:1Past journal entries transfer on request with full line-item detail. Volume-based chunking applies for large histories (we chunk in batches of 5,000 lines) to avoid memory exhaustion on the migration server. We preserve original posting dates and fiscal periods to maintain audit continuity, and we quarantine historical records older than three to five years separately for data quality remediation before import. Any inconsistent date formats or duplicate ledger entries accumulated through years of manual corrections are flagged in the pre-migration cleaning report.
Solution ERP
Projects
Dolibarr ERP
Project (third-party module or native tasks)
1:1Project records including budgets, milestones, and cost allocations transfer. Dolibarr's native project module provides basic task and milestone management; construction-specific phases and billing schedules that require advanced cost tracking may need the third-party projetex module or a custom extension. We flag any Solution ERP project fields with no Dolibarr equivalent during scoping and deliver a written list of those fields for the customer's admin to assess against available Dolibarr extensions or for custom development post-migration.
Solution ERP
POS Transactions
Dolibarr ERP
Customer Invoice + COGS Journal Entry
1:manySolution ERP POS transaction logs require reclassification because retail POS entries in Solution ERP often lack the cost-of-goods-sold split needed for accurate financial posting in Dolibarr's accounting module. We identify POS-specific transaction types during discovery, split them into a Customer Invoice record for the sales side and a COGS journal line referencing the appropriate cost account, and apply the destination's COGS accounts during migration. POS cash-drawer and payment-method information migrates to Dolibarr's payment conditions and bank/cash account links on the invoice.
Solution ERP
Documents
Dolibarr ERP
Document management (linked to Third Party, Product, Project)
1:1Attached files and records require file-type filtering. We extract document metadata (date, author, document type) separately from binary content because Dolibarr stores documents in a documents directory with a specific naming convention that differs from Solution ERP's structure. Binary file migration is limited to common formats (PDF, DOCX, XLSX, images); legacy binary formats are logged as unsupported and delivered in an archive for manual handling. Document links to Third Parties, Products, and Projects are recreated in Dolibarr's object linkage model.
Solution ERP
Users
Dolibarr ERP
User
1:1User accounts and role assignments migrate as Dolibarr User records with role names mapped from Solution ERP's permission structure. Permission structures are fundamentally different between platforms, so we do not map permissions directly. We flag admin-level accounts during scoping for explicit review, and we deliver a written role-matrix showing each Solution ERP role's nearest Dolibarr permission group so the customer's admin can configure access in Dolibarr post-migration. Users without a matching email or login in the destination are placed in a reconciliation queue.
Solution ERP
Custom Fields
Dolibarr ERP
Extra fields (Extra fields module)
1:1Custom properties on any standard object in Solution ERP are exported as key-value pairs. We map these to Dolibarr's Extra fields module (champs perdus) where the destination field type is supported, and we flag any Solution ERP custom field types (such as Gulf-specific dropdown values or calculated fields) with no Dolibarr equivalent for manual resolution. The customer's admin reviews and activates each extra field in Dolibarr's module configuration before the migration phase begins.
Solution ERP
Bank/Cash Accounts
Dolibarr ERP
Bank Account
1:1Bank account balances and cash account records migrate as Dolibarr Bank Account records. We apply a migration-date cutoff balance adjustment to reconcile any transactions posted after the export snapshot, and we flag any accounts with a material discrepancy (>1% of stated balance) for the customer's finance team to investigate before finalising. IBAN and SWIFT/BIC codes migrate to the appropriate Dolibarr Bank Account fields with format validation applied.
Solution ERP
Fixed Assets
Dolibarr ERP
Asset (Asset module)
1:1Asset registers including acquisition dates, depreciation methods, and net book value transfer to Dolibarr's Asset module. We validate depreciation schedules against the destination's tax depreciation rules, particularly for assets originally booked under Gulf tax treatment that may have different depreciation rates than EU or international equivalents. Any assets with partially completed depreciation cycles are flagged for the customer's accountant to confirm the remaining schedule before import.
| Solution ERP | Dolibarr ERP | Compatibility | |
|---|---|---|---|
| Chart of Accounts | Bank - Account, Third Party - Account (configuration required)1:1 | Mapping required | |
| Customers | Third Party (type: Customer)1:1 | Fully supported | |
| Vendors | Third Party (type: Supplier)1:1 | Fully supported | |
| Items | Product (type: Stock and/or Service)1:1 | Mapping required | |
| Open AP/AR | Supplier Invoice (AP) and Customer Invoice (AR)1:1 | Mapping required | |
| Historical Transactions | Accounting Entry (Ecriture Comptable)1:1 | Mapping required | |
| Projects | Project (third-party module or native tasks)1:1 | Fully supported | |
| POS Transactions | Customer Invoice + COGS Journal Entry1:many | Fully supported | |
| Documents | Document management (linked to Third Party, Product, Project)1:1 | Mapping required | |
| Users | User1:1 | Mapping required | |
| Custom Fields | Extra fields (Extra fields module)1:1 | Mapping required | |
| Bank/Cash Accounts | Bank Account1:1 | Fully supported | |
| Fixed Assets | Asset (Asset module)1:1 | Mapping required |
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.
Solution ERP gotchas
Gulf VAT and tax code mapping is non-trivial
POS transaction logs may require reclassification
Multi-site records require entity-level segmentation
Historical data quality is often inconsistent in legacy exports
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 data audit
We audit the source Solution ERP database across chart of accounts structure, customer and vendor volumes, item/product catalogue size, open AP/AR aging, historical transaction volume, POS transaction count and type distribution, project count and cost-centre depth, and user/role inventory. We also identify the Gulf VAT and excise tax code catalogue, multi-site or branch structure, and any legacy Arabic-field encoding formats. The discovery output is a written migration scope including record counts per object, a tax code mapping table draft, and a multi-site segmentation plan if applicable.
Data quality assessment and cleaning
We run pre-migration data quality checks against the Solution ERP export including duplicate detection, missing required-field analysis, date-format normalisation, and Arabic-character encoding verification. We produce a cleaning report that categorises records by severity (critical, moderate, cosmetic) and deliver it to the customer's finance and IT teams for remediation before migration begins. Historical records older than three to five years are quarantined for separate handling. This step prevents dirty data from landing in Dolibarr and generating incorrect financial balances or duplicate records that are expensive to clean post-migration.
Dolibarr environment preparation
We assist the customer with Dolibarr installation and module activation in a staging environment, including the accounting module, third-party or service product module, project module (if required), and extra fields module. We provision the chart of accounts in Dolibarr using the tax code mapping table from discovery, configure payment conditions to match Solution ERP terms, and set up entrepot (warehouse) records if multi-site segmentation applies. We do not install community Gulf tax extensions as part of standard scope; if required, we identify the extension and provide installation instructions. The customer configures user access roles using the role-matrix handoff document delivered at this stage.
Sandbox migration and reconciliation
We run a full migration into the staging Dolibarr instance using production-like data volumes. The customer's finance lead reconciles record counts, spot-checks ten to twenty records per object type against the Solution ERP source, and validates account balances and open invoice aging. We correct any mapping errors identified during reconciliation in the migration scripts and re-run the sandbox migration before production cutover. This step prevents production data integrity issues that would require disruptive rollback.
Production migration in dependency order
We run production migration in record-dependency order: chart of accounts first, then Third Parties (Customers and Vendors in parallel), then Products/Items, then open AP/AR invoices, then historical journal entries (chunked and quarantined by year), then POS transaction reclassification, then Projects, then bank/cash accounts with migration-date cutoff balances, then user accounts and extra fields. Each phase emits a row-count reconciliation report before the next phase begins. We maintain a migration log that maps every Solution ERP record ID to its Dolibarr record ID for audit and rollback purposes.
Cutover, validation, and handoff
We freeze Solution ERP writes during cutover, run a final delta migration of any records modified during the migration window, then lock the Solution ERP export and enable Dolibarr as the system of record. We deliver the automation inventory (any POS automation rules, custom Gulf integrations, or system-level workflows in Solution ERP that require rebuild in Dolibarr's module model), the tax code mapping confirmation document, the role-matrix for user access configuration, and the data quality residual report listing any records that were quarantined and require manual entry. We support a five-day hypercare window where we resolve any record-level reconciliation issues raised by the customer's team.
Platform deep dives
Solution 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 Solution 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
Solution ERP: Not publicly documented.
Data volume sensitivity
Solution 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 Solution ERP to Dolibarr ERP migration scoping. Not seeing yours? Book a call.
Walk through your Solution 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 Solution 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.