ERP migration
Field-level mapping, validation, and rollback between Clear Enterprise and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.
Clear Enterprise
Source
Dolibarr ERP
Destination
Compatibility
8 of 12
objects map 1:1 between Clear Enterprise and Dolibarr ERP.
Complexity
BStandard
Timeline
4-8 weeks
Overview
Clear Enterprise builds custom ERP and CRM systems to each customer's specification, which means no two deployments share the same schema. Migrating to Dolibarr — an open-source ERP and CRM distributed under GNU GPL v3 — requires profiling that custom schema before any mapping work begins. We extract every object, custom field, and relationship from the live Clear Enterprise deployment, design the equivalent Dolibarr structure (including any required custom fields via the CustomFields module), and load data in dependency order: third parties and contacts first, then Projects, Tasks, Documents, and Custom Objects. Dolibarr's native import tool handles simple flat-file loads but we use a custom ETL pipeline for CustomObjects and relationship-dense schemas where parent-record lookup resolution matters. Workflows, automations, and Forms do not migrate as code; we deliver a written inventory of any Clear Enterprise automation logic for your admin to rebuild in Dolibarr or as a separate scoped engagement.
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 Clear Enterprise 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.
Clear Enterprise
Contact
Dolibarr ERP
Contact (Third Party with contact type)
1:1Clear Enterprise Contact records map directly to Dolibarr Contact (llx_socpeople) linked to a parent Third Party (llx_societe). Name, email, phone, address, and owner assignment migrate as standard fields. The contact_is_customer flag in Clear Enterprise determines whether the parent Third Party is typed as customer, supplier, or both. Role or department fields from Clear Enterprise map to the Dolibarr contact Poste (position) field. Owner resolution uses email matching against the Dolibarr User table.
Clear Enterprise
Company
Dolibarr ERP
Third Party (llx_societe)
1:1Clear Enterprise Company records map to Dolibarr Third Parties. Company name maps to the nom field, address and city map to address fields, and phone maps to phone. The company's domain name maps to the url field for reference. The company_id reference on Contact records is resolved at migration time so that the llx_socpeople.fk_soc foreign key points to the correct parent Third Party row. If Clear Enterprise represents customers and suppliers as separate objects, they map to client=1 and/or fournisseur=1 flags on the same Third Party record in Dolibarr.
Clear Enterprise
Project
Dolibarr ERP
Project (llx_projet)
1:1Clear Enterprise Projects map to Dolibarr Project (llx_projet). Project name, description, status, start date, and end date migrate directly. Parent-child project hierarchies (sub-projects) in Clear Enterprise map to the parent_id reference in Dolibarr's Project table if the Clear Enterprise deployment uses project nesting. Billable flag from Clear Enterprise maps to the billed flag in Dolibarr Project. The project public or private visibility setting maps to the public flag in Dolibarr.
Clear Enterprise
Task
Dolibarr ERP
Task (llx_projet_task)
1:1Clear Enterprise Tasks map to Dolibarr Tasks (llx_projet_task). Parent-child task hierarchies (sub-tasks) migrate via the fk_task_parent reference. Task fields (name, description, start date, end date, status, priority) map to Dolibarr equivalents. Custom task fields from the Clear Enterprise deployment are stored using the Dolibarr CustomFields module (llx_customfields), preserving the property name and data type. The fk_projet foreign key links each Task to its parent Project in Dolibarr.
Clear Enterprise
Document
Dolibarr ERP
Document (file attachments via llx_extrafields + file store)
1:1Documents attached to Projects, Tasks, Contacts, Companies, and Custom Objects in Clear Enterprise are exported as individual files and re-associated to the correct parent record in Dolibarr. Dolibarr stores documents in the documents directory with a naming convention based on the object type and record ID. We replicate the file directory structure and update Dolibarr's extrafiles and content maps so that clicking the attachment icon in the Dolibarr UI displays the correct file. Document metadata (filename, upload date, uploader) is recorded in Dolibarr's llx_document_model or stored as extra fields.
Clear Enterprise
Custom Object
Dolibarr ERP
Custom Fields (llx_customfields) on relevant standard object
lossyClear Enterprise Custom Objects have no direct Dolibarr equivalent because Dolibarr's core does not include a generic custom object type. We handle this by discovering every Custom Object type during schema profiling, then creating Dolibarr CustomFields entries (using the stable CustomFields module) on the nearest standard object — typically Project, Task, Third Party, or Contact — that matches the logical domain. For example, a Clear Enterprise custom object tracking Equipment assignments might map to Project with extra fields for equipment_id and assignment_date. We document every Custom Object mapping in the schema design phase and deploy the CustomFields schema to a Dolibarr sandbox before production load.
Clear Enterprise
User
Dolibarr ERP
User (llx_user)
1:1Clear Enterprise Users map to Dolibarr Users (llx_user) by email address match. First name, last name, email, and active status migrate directly. Role and permission translation requires per-implementation review because Clear Enterprise role definitions are custom and Dolibarr uses a simpler permission model (global permissions for admin, read, write, and delete on per-module basis). We map Clear Enterprise role names to the nearest Dolibarr permission set and flag any role that cannot be translated for the customer's admin to resolve post-migration.
Clear Enterprise
Team
Dolibarr ERP
User Group (llx_usergroup)
lossyClear Enterprise Teams aggregate Users and may control access scoping. Dolibarr has a User Group concept (llx_usergroup) for grouping users. Where Clear Enterprise teams represent hierarchical access control (nested teams), we flatten the hierarchy into Dolibarr User Groups and assign the group's members accordingly. Team-specific permissions are mapped to Dolibarr module-level permissions where applicable. If the Clear Enterprise deployment uses teams to restrict record visibility (shared ownership model), we document this for the customer's admin to implement using Dolibarr's user permission rules post-migration.
Clear Enterprise
Chart of Accounts / GL data
Dolibarr ERP
Accounting module (llx_accounting_account)
lossyIf the Clear Enterprise deployment includes GL data, Chart of Accounts, or financial transactions, we map them to Dolibarr's accounting module. Dolibarr's accounting functionality requires the Accounting Expert module to be activated. Account codes from Clear Enterprise map to account_number in llx_accounting_account, and transaction amounts map to llx_accounting_bookkeeping. Currency, tax codes, and effective-dated balances require careful field-to-field translation during the ETL pipeline build. If the Clear Enterprise deployment does not include a formal chart of accounts (many SMB-focused deployments do not), this object is skipped and noted in the scope document.
Clear Enterprise
Custom Fields on standard objects
Dolibarr ERP
CustomFields (llx_customfields)
lossyClear Enterprise standard objects (Contacts, Companies, Projects, Tasks) may carry custom fields beyond the platform defaults. We discover all custom fields during schema profiling and use Dolibarr's CustomFields module to recreate them as extra fields on the equivalent Dolibarr standard object. Field types are mapped: text fields to varchar, numbers to integer or float, dates to datetime, checkboxes to yesno, dropdowns to select. The CustomFields module stores these in separate tables (llx_customfields) that hook into the standard Dolibarr object lifecycle, so create, read, and update operations work natively in the Dolibarr UI.
Clear Enterprise
Engagements (calls, emails, meetings, tasks, notes)
Dolibarr ERP
Tasks (llx_projet_task), Events (llx_actioncomm), Notes (llx_note)
1:1Clear Enterprise engagement records (if present in the deployment) map to Dolibarr's Task, Event, and Note objects. Calls map to Task with type=phone; emails map to Event records or Note depending on the engagement type in Clear Enterprise; meetings map to Event records with start and end timestamps and location. Each engagement's parent reference (project, task, contact, or company) is resolved at migration time so that the activity appears in the correct context within Dolibarr. Historical timestamps are preserved in Dolibarr's date field on the relevant object.
Clear Enterprise
Relationships (cross-object references)
Dolibarr ERP
Foreign key lookups and extra field links
1:1Clear Enterprise relationships between records (Contact-to-Company, Task-to-Project, Document-to-Parent) are preserved through foreign key lookups during migration. We build a reference resolution table as part of the ETL pipeline: each Clear Enterprise record ID is mapped to its corresponding Dolibarr record ID after insertion, and subsequent imports use the resolved destination ID rather than the source ID. This ensures that the relationship graph in Dolibarr matches the original Clear Enterprise structure — a Contact correctly attached to its Company, a Task correctly linked to its Project, a Document correctly attached to its parent record.
| Clear Enterprise | Dolibarr ERP | Compatibility | |
|---|---|---|---|
| Contact | Contact (Third Party with contact type)1:1 | Fully supported | |
| Company | Third Party (llx_societe)1:1 | Fully supported | |
| Project | Project (llx_projet)1:1 | Fully supported | |
| Task | Task (llx_projet_task)1:1 | Fully supported | |
| Document | Document (file attachments via llx_extrafields + file store)1:1 | Fully supported | |
| Custom Object | Custom Fields (llx_customfields) on relevant standard objectlossy | Fully supported | |
| User | User (llx_user)1:1 | Fully supported | |
| Team | User Group (llx_usergroup)lossy | Fully supported | |
| Chart of Accounts / GL data | Accounting module (llx_accounting_account)lossy | Fully supported | |
| Custom Fields on standard objects | CustomFields (llx_customfields)lossy | Fully supported | |
| Engagements (calls, emails, meetings, tasks, notes) | Tasks (llx_projet_task), Events (llx_actioncomm), Notes (llx_note)1:1 | Fully supported | |
| Relationships (cross-object references) | Foreign key lookups and extra field links1: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.
Clear Enterprise gotchas
Non-modular packaging hides which features are actually live
Add-on Clear* tools (ClearOnline, ClearMobile, ClearScan, ClearView) live in separate data stores
Deployment can be cloud, managed-hosted, or on-premise — extraction differs per mode
Public technical documentation is sparse
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
Schema discovery and profiling
We begin by profiling the live Clear Enterprise deployment through available export interfaces. We enumerate every object type (standard and custom), every field on each object, every custom field and its data type, and every relationship between records. This produces a written Schema Profile Document that is the authoritative source for the migration mapping work. If Clear Enterprise provides a database export or API access, we use it directly; if the deployment relies on UI exports, we coordinate with the Clear Enterprise team to extract the data in a structured format. The Schema Profile Document is reviewed and signed off by the customer before mapping begins.
Dolibarr environment setup and CustomFields deployment
We stand up a Dolibarr instance — either a local installation or a DoliCloud sandbox — and activate the required modules (Third Parties, Contacts, Projects, Tasks, Invoices, Products, HR, and any others relevant to the customer's scope). We deploy the CustomFields module and create all extra field definitions identified during schema profiling, mapping each Clear Enterprise custom field to a typed Dolibarr CustomField entry on the appropriate standard object. The target schema is deployed to sandbox and validated against a small sample of data before full migration build begins.
ETL pipeline build and sandbox test migration
We build a custom ETL pipeline that extracts data from the Clear Enterprise export, transforms each record using the mapping defined in the Schema Profile Document, and loads to Dolibarr in dependency order. The pipeline handles ID reference resolution (resolving Clear Enterprise record IDs to the corresponding Dolibarr record IDs after insertion), batch chunking, and error logging. We run a full sandbox migration using production-like data volume and the customer's admin validates record counts, spot-checks 25-50 records against the source, and signs off the mapping before production migration begins. Any mapping corrections are made in sandbox.
User and contact ownership reconciliation
We extract every distinct Clear Enterprise user referenced as an owner or assigned user on any record (Contact, Company, Project, Task, Document) and match by email against the destination Dolibarr User table. Any Clear Enterprise user without a matching Dolibarr User is added to a reconciliation queue for the customer's admin to provision before the production phase begins. This step must complete before any record load because OwnerId references are required on most standard objects in Dolibarr.
Production migration in dependency order
We run production migration in record-dependency order: Third Parties first (from Clear Enterprise Companies), then Contacts (linked to Third Parties by resolved fk_soc), then Projects, then Tasks (with parent_id and fk_projet resolved), then Documents (file re-association verified against the mapping table), then Custom Fields (via CustomFields module), then any engagement history. Each phase emits a row-count reconciliation report. We use a migration user with the appropriate Dolibarr permissions and temporarily relax any validation rules that would block bulk imports to ensure records load without silent rejection.
Cutover, delta migration, and automation inventory handoff
We freeze writes to Clear Enterprise during the cutover window, run a final delta migration of any records modified during the migration phase, validate the final record counts against the source, and hand over to the customer's team as the system of record. We deliver the automation inventory document (covering any Clear Enterprise business rules and triggers discovered during profiling) and a written data quality report listing any records that could not be migrated and the reason for each. We do not rebuild Clear Enterprise workflows or automations in Dolibarr; that work is documented for the customer's admin to implement or for a separate scoped engagement.
Platform deep dives
Clear Enterprise
Source
Strengths
Weaknesses
Dolibarr ERP
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. All 8 core objects map 1:1 between Clear Enterprise and Dolibarr ERP.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Clear Enterprise and Dolibarr ERP.
Object compatibility
All 8 core objects map 1:1 between Clear Enterprise 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
Clear Enterprise: Not publicly documented..
Data volume sensitivity
Clear Enterprise 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 Clear Enterprise to Dolibarr ERP migration scoping. Not seeing yours? Book a call.
Walk through your Clear Enterprise 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 Clear Enterprise
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.