ERP migration
Field-level mapping, validation, and rollback between Epicor Eclipse and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.
Epicor Eclipse
Source
Dolibarr ERP
Destination
Compatibility
12 of 12
objects map 1:1 between Epicor Eclipse and Dolibarr ERP.
Complexity
BStandard
Timeline
5-8 weeks
Overview
Moving from Epicor Eclipse to Dolibarr is a structural migration that must address Eclipse's UniVerse MultiValue architecture before any data reaches a relational database. Eclipse stores customer records, parts, pricing matrices, and orders in file-based dynamic arrays that do not map 1:1 to Dolibarr's normalized MySQL/PostgreSQL schema. We extract via Eclipse's REST API or direct UniVerse file access, flatten dynamic array fields into standard columns, and load through Dolibarr's native import tools or REST API. Open Sales Orders and Open Purchase Orders carry the highest risk because Eclipse's order-to-invoice chain is tightly linked; we validate the full sequence post-load. Dolibarr's modular architecture means we activate only the modules needed for the migrated data (ThirdParty, Product, Order, Stock, Accounting) and we flag which distribution-specific features (counter/POS, RF scanning, cross-docking) have no native Dolibarr equivalent and require manual configuration or third-party modules. Workflows, custom UniBASIC programs, EDA dashboards, and EDI configurations do not migrate; we deliver a written inventory of these for the customer's team to address post-cutover.
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 Epicor Eclipse 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.
Epicor Eclipse
Customer
Dolibarr ERP
ThirdParty (type: Customer)
1:1Eclipse CUSTOMER records map to Dolibarr ThirdParty entries with type=Customer. Eclipse ship-to addresses stored in SHIP.TO files map to Dolibarr address records linked to the parent ThirdParty. Eclipse customer class and price class fields map to Dolibarr price level or category. We flatten dynamic array address fields (street, city, state, zip, country) into standard Dolibarr address table columns and validate against Dolibarr's country and state/province picklists.
Epicor Eclipse
Supplier
Dolibarr ERP
ThirdParty (type: Supplier)
1:1Eclipse vendor records from the VENDOR file map to Dolibarr ThirdParty entries with type=Supplier. Eclipse PO history, rebate terms, and EDI capability flags transfer as supplier notes or custom fields. We map Eclipse buying codes (VENDOR.PRODUCT cross-references) to Dolibarr supplier product references so that purchase orders can display both Eclipse part numbers and vendor part numbers.
Epicor Eclipse
Part / Product
Dolibarr ERP
Product (or Service)
1:1Eclipse PRODUCT records map to Dolibarr Product entries with type=Product (for physical goods) or type=Service (for non-stocked items). Eclipse dynamic array attributes—warehouse-specific stocking data, substitute chains, product group assignments—require flattening into Dolibarr product custom fields or multi-line text notes. Eclipse UOM definitions map to Dolibarr unit of measure entries. If the customer uses Eclipse's IDW (Industry Data Warehouse) attributes for electrical distribution, we flag these for manual configuration in Dolibarr because IDW is an Eclipse-specific taxonomy with no direct Dolibarr equivalent.
Epicor Eclipse
Open Sales Order
Dolibarr ERP
Order
1:1Open Eclipse orders map to Dolibarr CustomerOrder records with status in progress. Eclipse order headers contain customer reference, order date, terms, and salesperson; these map to Dolibarr Order fields directly. Eclipse order lines map to OrderLine records with product reference, quantity, unit price, and discount. We preserve customer-specific pricing and quantity breaks from Eclipse as Dolibarr line-level prices. Eclipse order notes and special instructions transfer as Dolibarr Order notes.
Epicor Eclipse
Open Purchase Order
Dolibarr ERP
SupplierOrder
1:1Open Eclipse POs map to Dolibarr SupplierOrder entries. Eclipse PO fields (vendor, terms, line items, receiving status) map to Dolibarr SupplierOrder fields. Partially-received Eclipse POs require careful line-level tracking because Dolibarr's receiving workflow is simpler than Eclipse's multi-stage receiving and inspection process; we flag any partially-received lines that need special handling during cutover validation.
Epicor Eclipse
Inventory / Stock
Dolibarr ERP
Stock
1:1Eclipse INVENTORY records by warehouse map to Dolibarr Stock entries per warehouse. Eclipse bin locations and rankings map to Dolibarr warehouse location fields. On-hand, allocated, and on-order quantities per warehouse per part transfer as Dolibarr stock values. Eclipse multi-value fields that store multiple quantity types per part require unpacking into separate Dolibarr stock entries per status. We validate total inventory value post-load against Eclipse's inventory valuation report.
Epicor Eclipse
Chart of Accounts
Dolibarr ERP
Account (Accounting module)
1:1Eclipse account structures (which may combine division, cost center, and account number in one field) must be segmented and mapped to Dolibarr's accounting chart. Dolibarr's accounting module supports standard chart of accounts templates (PCG82 for France, generic templates for other countries) that we customize with the customer's Eclipse account structure. Eclipse cost center usage determines whether we create Dolibarr cost center dimensions as separate accounts or as analytical dimensions.
Epicor Eclipse
Open AR / AP
Dolibarr ERP
Invoice (or Bill) and Payment
1:1Outstanding Eclipse AR invoices map to Dolibarr CustomerInvoice records with status unpaid. Eclipse AP vouchers map to Dolibarr SupplierInvoice (Bill) records. Aging data and payment terms transfer as invoice metadata. Eclipse apply-to information (which payments were allocated to which invoices) requires mapping to Dolibarr payment allocations. We validate that total AR and AP balances match Eclipse's aging report before declaring the migration phase complete.
Epicor Eclipse
Historical Transactions
Dolibarr ERP
Invoice and Order (closed)
1:1Scoping determines which historical records migrate. We typically migrate 2-5 years of sales history (orders, invoices, payments, RMAs) per the customer's requirements. Eclipse closed orders older than the retention period are summarized or excluded. Complete invoice and payment history is optional and adds cost because of volume. We document the scope upfront and validate historical totals against Eclipse's period-end reports.
Epicor Eclipse
Quote / Estimate
Dolibarr ERP
Propal (Commercial Proposal)
1:1Open Eclipse quotes map to Dolibarr Propal records. Eclipse quote lines with configuration details and quantity break pricing transfer as Dolibarr PropalLine entries. Closed quote statistics (win rate, average value) migrate as summary records in a custom field or note because Dolibarr does not have a native closed-quote history object. Quote expiration dates and status transfer to Propal validity dates and status.
Epicor Eclipse
Tax Code
Dolibarr ERP
Tax (VAT or local tax rules)
1:1Eclipse tax jurisdiction assignments tied to customer ship-to locations map to Dolibarr tax rules per customer and per product category. Eclipse tax codes embedded in custom UniBASIC programs are flagged for manual configuration in Dolibarr's tax management module. We export the Eclipse tax code master and jurisdiction mappings as a CSV that the customer's admin imports into Dolibarr's tax rules table.
Epicor Eclipse
Employee / User
Dolibarr ERP
User
1:1Eclipse user records (with role assignments, warehouse access, and salesperson links) map to Dolibarr User entries. Eclipse salesperson codes transfer as Dolibarr user tags or custom fields so that orders and quotes can be attributed to the correct salesperson. We extract user status (active/inactive) and map to Dolibarr User active flag. Eclipse security settings and authorization keys do not transfer and require reconfiguration in Dolibarr's permission system.
| Epicor Eclipse | Dolibarr ERP | Compatibility | |
|---|---|---|---|
| Customer | ThirdParty (type: Customer)1:1 | Fully supported | |
| Supplier | ThirdParty (type: Supplier)1:1 | Fully supported | |
| Part / Product | Product (or Service)1:1 | Fully supported | |
| Open Sales Order | Order1:1 | Fully supported | |
| Open Purchase Order | SupplierOrder1:1 | Fully supported | |
| Inventory / Stock | Stock1:1 | Mapping required | |
| Chart of Accounts | Account (Accounting module)1:1 | Mapping required | |
| Open AR / AP | Invoice (or Bill) and Payment1:1 | Mapping required | |
| Historical Transactions | Invoice and Order (closed)1:1 | Mapping required | |
| Quote / Estimate | Propal (Commercial Proposal)1:1 | Fully supported | |
| Tax Code | Tax (VAT or local tax rules)1:1 | Fully supported | |
| Employee / User | User1: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.
Epicor Eclipse gotchas
UniVerse MultiValue extraction requires non-standard tools
Performance degradation post-Kinetic migration
End-to-end workflow must be validated as a chain
Historical data scoping determines migration cost
Integration connections require separate migration planning
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 Eclipse environment audit
We audit the source Eclipse environment: current version (e.g., 9.x series), modules licensed and active (Order Management, Counter/POS, Inventory, Purchasing, Financials, CRM, Job Management, EDI), number of concurrent users, custom UniBASIC programs in use, and EDA dashboard configurations. We identify all integration endpoints (MES, quality tools, EDI, shipping, CRM) that will require re-establishment in Dolibarr. We review the Eclipse REST API availability and licensing status, noting that the Sales Order API requires an additional $24,000 license fee that affects extraction strategy. The discovery output is a written scope document covering data volumes, extraction method, historical data scope, and a list of integrations requiring post-migration attention.
Extraction from Eclipse UniVerse
We extract Eclipse data using the appropriate method based on the discovery findings. Where Eclipse REST API is licensed and available, we use standard endpoints for Customers, Suppliers, Products, Orders, and Inventory. For data not exposed via REST API, we use Eclipse's CSV export specifications (Mass Load utility) or direct UniVerse file extraction via Eterm connections with UniBASIC queries in RetrieVe query language. We parse dynamic arrays in Eclipse fields (multi-value address components, multi-warehouse quantities, product attribute arrays) into normalized columns during extraction. We run extraction during off-peak hours to avoid impacting Eclipse performance for active users.
Dolibarr schema design and module activation
We design the destination Dolibarr schema based on the migrated data. This includes activating the required Dolibarr modules: ThirdParty (for customers and suppliers), Product, Stock, CustomerOrder, SupplierOrder, Propal, Accounting, and any others needed. We configure the chart of accounts to match the customer's Eclipse account structure, set up tax rules per jurisdiction, define warehouse locations, and configure Dolibarr's price management system with the flattened pricing data from Eclipse. For distribution-specific configurations (counter/POS, RF scanning), we document the desired behavior and recommend appropriate Dolibarr modules or configuration steps for the customer's team to implement post-migration.
Test migration and reconciliation
We run a full test migration into a staging Dolibarr instance using representative data volumes. We reconcile record counts (customers in, suppliers in, products in, orders in, inventory values) against Eclipse source reports. We validate that open order totals match Eclipse balances, that inventory on-hand matches per warehouse, and that AR/AP aging matches Eclipse's ledger. The customer reviews the test migration data and confirms mapping accuracy before production migration begins. Any pricing matrix flattening issues, attribute mapping corrections, or account structure adjustments are resolved at this stage.
Production migration in dependency order
We run production migration in dependency order: ThirdParty records (customers and suppliers first), Products, Warehouses and stock levels, Open Customer Orders, Open Supplier Orders, Open AR/AP, Historical transactions (if scoped), and Tax rules. Each phase emits a reconciliation report comparing counts and totals to Eclipse source reports before the next phase begins. We use Dolibarr's native import tools or REST API based on volume; for large historical transaction sets, we batch inserts to stay within Dolibarr's processing limits. We freeze Eclipse writes during the final delta migration window to capture any records modified during the migration window.
Cutover, validation, and handoff
We validate the production migration end-to-end: customer and supplier counts, product counts, open order totals and line counts, inventory values per warehouse, AR/AP balances, and historical transaction totals. We run a sample of orders through Dolibarr end-to-end (from order entry to invoice to payment) to verify the workflow chain. We deliver the written automation inventory covering active UniBASIC programs, EDI configurations, and custom EDA dashboards that require redevelopment in Dolibarr. We provide a one-week hypercare window for reconciliation issues raised by the customer's team. We do not rebuild Eclipse workflows, EDI connections, or custom UniBASIC programs as part of the migration scope; those are documented for the customer's team to address separately.
Platform deep dives
Epicor Eclipse
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 Epicor Eclipse 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
Epicor Eclipse: Rate limiting settings exist on the app server but are not publicly documented by Epicor.
Data volume sensitivity
Epicor Eclipse 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 Epicor Eclipse to Dolibarr ERP migration scoping. Not seeing yours? Book a call.
Walk through your Epicor Eclipse 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 Epicor Eclipse
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.