ERP migration
Field-level mapping, validation, and rollback between EQUAL and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.
EQUAL
Source
Dolibarr ERP
Destination
Compatibility
10 of 12
objects map 1:1 between EQUAL and Dolibarr ERP.
Complexity
CModerate
Timeline
3-5 weeks
Overview
Moving from EQUAL to Dolibarr is a migration from a cloud-native spend management platform to a self-hosted open-source ERP. EQUAL tracks bank accounts, virtual cards, and multi-currency transactions with live SQL query access. Dolibarr provides a modular ERP and CRM stack with llx_bank for bank accounts, llx_bank_account for bank account records, llx_facture for invoices, and llx_societe for third parties. We map EQUAL's Accounts to Dolibarr llx_bank, Transactions to llx_bank_line, Cards to llx_bank_account entries with card metadata stored in a custom field set, and multi-currency amounts with their original exchange rates preserved. Dolibarr's community-supported 3.7/5 support rating means post-migration admin tasks require self-service or paid support contracts. We do not migrate SQL query configurations, custom reporting dashboards, or API access tokens; these require rebuild in Dolibarr's module framework.
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 EQUAL 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.
EQUAL
Account
Dolibarr ERP
llx_bank
1:1EQUAL bank account records map to Dolibarr llx_bank entries representing the bank itself. The account name from EQUAL becomes the label (label) field, and the currency code maps to Dolibarr's currency module configuration. Bank account numbers from EQUAL store in a custom field cf_bank_account_number on llx_bank. Multi-currency accounts use Dolibarr's multi-entity or multi-currency configuration which must be enabled in Dolibarr Setup before migration.
EQUAL
Transaction
Dolibarr ERP
llx_bank_line
1:1EQUAL transaction records map to Dolibarr llx_bank_line (bank line entries). The debit or credit amount maps to debot and credit fields respectively. The original currency amount from EQUAL's multi-currency transactions stores in a custom field cf_original_amount with the exchange rate in cf_exchange_rate, preserving the original ledger value for audit. The transaction date becomes the dateo (operation date) and datev (value date) fields.
EQUAL
Card
Dolibarr ERP
llx_bank_account + Custom Fields
1:1EQUAL virtual card and expense card records map to llx_bank_account entries with card metadata (card type, BIN range, spending limits, status) stored in custom fields on the bank account. The parent llx_bank reference links the card to the issuing bank account. Card assignment (which user or cost center the card is assigned to) maps to the fk_user (user assignment) or a custom fk_expense_category field depending on the customer's cost-center structure.
EQUAL
Currency Balance
Dolibarr ERP
llx_bank_currency
lossyEQUAL multi-currency ledger balances map to Dolibarr llx_bank_currency records linked to the parent llx_bank account. We preserve the original currency code, balance amount in that currency, and the exchange rate to the base currency as of the migration snapshot date. Dolibarr's currency module must be activated and configured with exchange rate feeds before this object migrates.
EQUAL
Expense Category
Dolibarr ERP
llx_categorie
1:1EQUAL expense category tags map to Dolibarr llx_categorie entries with type=3 (products/categories). We preserve the category hierarchy if EQUAL supports parent-child tags, mapping it to Dolibarr's fk_parent nested structure. Tags that do not have a direct equivalent in Dolibarr's category system store as custom fields cf_expense_tag on the llx_bank_line record for granular expense reporting.
EQUAL
Merchant Metadata
Dolibarr ERP
Custom Fields on llx_bank_line
lossyEQUAL merchant metadata (MCC code, merchant name, merchant category) attaches to llx_bank_line records via a custom field group. Dolibarr's native transaction view does not include merchant metadata fields by default, so we create cf_mcc_code, cf_merchant_name, and cf_merchant_category custom fields on the bank line table. This preserves the full merchant context for expense categorization and policy compliance.
EQUAL
Third Party (counterparties)
Dolibarr ERP
llx_societe
1:1EQUAL transaction counterparties (vendors, suppliers, income sources) map to Dolibarr llx_societe (third-party) records. The company name maps to the nom field, and the counterparty's country and VAT number map to country and tva_intra if present. Customer versus supplier classification uses llx_societe.client (1=customer, 2=supplier, 3=both) which we populate from EQUAL's party type.
EQUAL
Contact
Dolibarr ERP
llx_socpeople
1:1EQUAL contact records associated with accounts map to Dolibarr llx_socpeople linked via fk_soc to the corresponding llx_societe record. Email, phone, and address fields migrate directly. The contact's role (billing, technical, primary) maps to the fk_socpeople_role or a custom field cf_contact_role if role-based contact segmentation exists in the source.
EQUAL
Invoice
Dolibarr ERP
llx_facture
1:1EQUAL invoice records (if exported from a connected accounting layer) map to Dolibarr llx_facture. The invoice number becomes ref, the total maps to total_ttc, and tax amounts map to total_tva. Status (paid, unpaid, cancelled) maps to Dolibarr's fk_statut field. Multi-currency invoice amounts store in a custom field cf_original_amount with the applicable exchange rate.
EQUAL
Product
Dolibarr ERP
llx_product
1:1EQUAL products or SKUs referenced in expense transactions map to Dolibarr llx_product if the destination uses inventory or project management modules. The product reference becomes ref, description maps to description, and price maps to price. If the customer does not activate the product module, these records are flagged as optional scope during discovery.
EQUAL
User
Dolibarr ERP
llx_user
1:1EQUAL user records who own cards or are assigned to transactions map to Dolibarr llx_user. We resolve by email match. Active versus inactive status maps from EQUAL's user status. Admin flag maps to admin=1 in Dolibarr. Users without an email match go to a reconciliation queue for manual provisioning before card assignment records migrate.
EQUAL
Timestamp History
Dolibarr ERP
date_creation, tms on target tables
1:1EQUAL's historical transaction timestamps migrate to Dolibarr's datec (creation date) and tms (modification timestamp) fields on llx_bank_line. We preserve the original ledger timestamp rather than overwriting with migration run time, maintaining audit continuity. For transactions with no timestamp in EQUAL, we use a default migration-date value and flag the record in the reconciliation report.
| EQUAL | Dolibarr ERP | Compatibility | |
|---|---|---|---|
| Account | llx_bank1:1 | Fully supported | |
| Transaction | llx_bank_line1:1 | Fully supported | |
| Card | llx_bank_account + Custom Fields1:1 | Fully supported | |
| Currency Balance | llx_bank_currencylossy | Fully supported | |
| Expense Category | llx_categorie1:1 | Fully supported | |
| Merchant Metadata | Custom Fields on llx_bank_linelossy | Fully supported | |
| Third Party (counterparties) | llx_societe1:1 | Fully supported | |
| Contact | llx_socpeople1:1 | Fully supported | |
| Invoice | llx_facture1:1 | Fully supported | |
| Product | llx_product1:1 | Fully supported | |
| User | llx_user1:1 | Fully supported | |
| Timestamp History | date_creation, tms on target tables1: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.
EQUAL gotchas
No documented public API for self-service extraction
Regional tax and compliance baked into modules
One-time licensing model complicates cutover budgeting
Limited independent review data complicates customer-side validation
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 hosting readiness
We audit the EQUAL portal for account count, transaction volume, multi-currency currency codes used, card records, expense category tags, and merchant metadata fields. We simultaneously assess the target Dolibarr hosting environment: PHP version, MariaDB/MySQL version, Dolibarr version planned, and whether the CustomFields module is installed. We deliver a written scope document that lists every EQUAL object, its record count, and the target Dolibarr table and custom field plan. If multi-currency is in scope, we confirm that Dolibarr's currency module is activated and exchange rate feeds are configured.
Schema design and custom field deployment
We design the Dolibarr target schema: llx_bank entries from EQUAL accounts, llx_bank_line structure for transactions, llx_societe for counterparties, llx_bank_account for cards with custom fields (cf_card_type, cf_bin_range, cf_spending_limit, cf_merchant_name, cf_mcc_code, cf_original_amount, cf_exchange_rate). Custom fields deploy via Dolibarr's CustomFields module or via a PHP migration script that writes directly to the database. We validate the schema in a staging Dolibarr instance before production migration to catch any foreign key constraint violations.
Currency and third-party normalization
We normalize currency codes from EQUAL against Dolibarr's currency table (llx_c_currencies) and create any missing currency records. We deduplicate counterparty names from EQUAL's transaction feed, merge identical counterparties, and create llx_societe records in bulk. Any counterparty that requires manual review (name ambiguity, missing VAT number) goes to a reconciliation queue for the customer's admin to resolve before the final import.
Staging migration and reconciliation
We run a full migration into a staging Dolibarr instance using production-like data volume. The customer's finance lead reconciles transaction totals per currency, card count per assignee, and expense category distribution. We compare the EQUAL ledger balance at migration date against the Dolibarr llx_bank_line sum and flag any discrepancy above 0.01 units. The customer signs off on the staging reconciliation before production migration is scheduled.
Production migration in dependency order
We run production migration in record-dependency order: currencies first, then llx_bank (accounts), llx_societe (counterparties), llx_bank_line (transactions), llx_bank_account (cards), llx_socpeople (contacts), and finally llx_facture (invoices) if applicable. Each phase emits a row-count report. We preserve original transaction timestamps in datec and tms fields. Multi-currency amounts store in custom fields alongside the converted base-currency amounts.
Cutover, validation, and admin handoff
We freeze EQUAL write access during cutover, run a final delta migration of any transactions created after the snapshot, and deliver a reconciliation summary comparing EQUAL's final ledger total against Dolibarr's llx_bank_line sum. We provide a written document listing the CustomFields created, the custom report SQL templates (if applicable), and the recommended next steps for activating Dolibarr's report module. We offer a one-week hypercare window for reconciliation issues. We do not rebuild EQUAL's SQL query configurations, custom reporting dashboards, or API access tokens in Dolibarr; these require rebuild in Dolibarr's PHP-based module framework and sit outside the migration scope.
Platform deep dives
EQUAL
Source
Strengths
Weaknesses
Dolibarr ERP
Destination
Strengths
Weaknesses
Complexity grading
Moderate ERP migration. 8 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across EQUAL and Dolibarr ERP.
Object compatibility
8 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
EQUAL: Not publicly documented.
Data volume sensitivity
EQUAL 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 EQUAL to Dolibarr ERP migration scoping. Not seeing yours? Book a call.
Walk through your EQUAL 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 EQUAL
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.