ERP migration
Field-level mapping, validation, and rollback between ABRA Gen and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.
ABRA Gen
Source
Dolibarr ERP
Destination
Compatibility
9 of 12
objects map 1:1 between ABRA Gen and Dolibarr ERP.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from ABRA Gen to Dolibarr is a platform-level migration requiring direct database extraction, schema redesign, and re-import into Dolibarr's PHP-and-MySQL stack. ABRA Gen has no documented public REST API, so we work with the customer's IT team to obtain read-only database credentials and extract firmy (companies), zakazky (jobs/contracts), sklady (warehouses), vyrobky (products), ucetni (accounting journal entries), and doklady (documents/invoices) from the live instance. We map the Czech accounting chart of accounts to Dolibarr's llx_accounting_account table, preserve historical journal entries for the legally required retention period, and load Dolibarr's third-party, product, stock, and project modules in dependency order. We do not migrate custom modules, on-premise integrations, or ERP workflows as code; we deliver a written inventory of any such objects for the customer's admin to rebuild. ABRA Gen's production and BOM modules require special scoping because Dolibarr's MRP module is optional and supports a narrower feature set than ABRA Gen's production planning capabilities.
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 ABRA Gen 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.
ABRA Gen
Firmy (Companies/Accounts)
Dolibarr ERP
ThirdParty (llx_societe)
1:1ABRA Gen firmy records map to Dolibarr llx_societe (third-party) with separate llx_socpeople entries for individual contacts. Address, VAT number, customer/supplier classification, and payment terms migrate to Dolibarr's corresponding fields. The firmy financial classification (customer type, credit limit) maps to Dolibarr's code_client, code_fournisseur, and statut fields. Custom firmy extensions identified during schema discovery require manual field mapping and customer review before load.
ABRA Gen
Odberatele (Customers)
Dolibarr ERP
ThirdParty (llx_societe) with client = 1
1:1ABRA Gen odberatele are a subset of firmy flagged as customers. We filter firmy by the customer classification property and load only those records into llx_societe with client = 1. Billing and shipping addresses migrate to llx_societe_rib for payment banking details and to llx_element_contact for address association.
ABRA Gen
Dodavatele (Vendors)
Dolibarr ERP
ThirdParty (llx_societe) with supplier = 1
1:1ABRA Gen dodavatele map to llx_societe with supplier = 1. Vendor-specific fields including payment terms, vendor code, and banking details migrate to llx_societe_rib. Vendor-specific discount structures are preserved in a custom field or the local VAT identifier field depending on usage.
ABRA Gen
Zakazky (Jobs/Contracts)
Dolibarr ERP
Project (llx_projet)
1:1ABRA Gen zakazky capture project-level financial tracking, cost allocation, and contract billing. We map zakazky to llx_projet with the project code preserved as ref, the customer reference resolved to a llx_societe lookup, and any financial budgets carried into the budget fields. Nested zakazky hierarchies are flattened with a parent-child project structure using the father_id field.
ABRA Gen
Sklady (Warehouses/Stock)
Dolibarr ERP
Warehouse (llx_entrepot)
1:1ABRA Gen sklady map to Dolibarr llx_entrepot. Warehouse codes, physical addresses, and manager assignments migrate. Stock quantities per warehouse map to llx_product_stock after the product import is complete. Dolibarr's multi-warehouse support is activated during installation before migration begins; if ABRA Gen uses multiple storage locations within a single warehouse, we create separate Dolibarr warehouse records and document the consolidation decision.
ABRA Gen
Vyrobky (Products/Items)
Dolibarr ERP
Product (llx_product)
1:1ABRA Gen vyrobky (products, raw materials, services) map to Dolibarr llx_product with product type (product vs service) determined by the ABRA Gen item type field. Pricing migrates to llx_product_price and llx_product_price_level; unit-of-measure definitions map to Dolibarr's unit of measure fields. Multi-level BOMs (Bill of Materials) from ABRA Gen require scoping: we map them to Dolibarr's llx_product_bom for the optional MRP module, but complex multi-level BOMs may require flattening or manual reconstruction.
ABRA Gen
Doklady (Documents/Invoices)
Dolibarr ERP
Invoice/Order (llx_facture, llx_commande)
1:1ABRA Gen doklady include sales invoices, purchase orders, and delivery notes stored as document headers with line items. We map open documents (unpaid invoices, pending purchase orders) to llx_facture (customer) or llx_facture_fourn (supplier) and llx_commande. Historical closed documents are scoped based on the legal retention period for the customer's jurisdiction; we recommend exporting closed fiscal years as read-only PDF archives rather than loading them into Dolibarr to avoid bloating the live system.
ABRA Gen
Ucetni (Accounting Records)
Dolibarr ERP
Accounting entries (llx_accounting_account, llx_accounting_move, llx_accounting_movent)
lossyCzech accounting journal entries from ucetni require chart-of-accounts mapping to Dolibarr's llx_accounting_account table. We extract the source account codes, map them to the destination COA using a customer-supplied mapping table or a Czech statutory COA template, and load to llx_accounting_movent linked to llx_accounting_move. Account numbers, labels, and group hierarchies migrate; debit/credit amounts and currency codes are preserved directly. Any posting dates outside the migration window are flagged for customer review.
ABRA Gen
Uzivatele (Users)
Dolibarr ERP
User (llx_user)
1:1ABRA Gen user accounts, roles, and permission sets map to Dolibarr llx_user. Login, name, email, and active status migrate. Role and permission mapping is recorded in a written document for the customer's admin to reassign Dolibarr permission profiles (RH/HR manager, sales manager, accountant, etc.) post-migration because Dolibarr's permission model uses a flat profile system rather than ABRA Gen's module-level role grants.
ABRA Gen
Zamestnanci (Employees)
Dolibarr ERP
User or ThirdParty (llx_user, llx_societe for external)
1:1ABRA Gen zamestnanci (employee records) for internal staff map to llx_user with employment status, department, and contact data preserved. External contractors or freelancers who are ABRA Gen suppliers or customers map to llx_societe with the employee flag recorded. HR and payroll-specific fields that have no Dolibarr equivalent are documented in a supplemental export for the customer's HR team.
ABRA Gen
Custom Modules
Dolibarr ERP
Custom Objects or Extra Fields (llx_extrafields)
lossyABRA Gen implementations frequently include custom-developed modules or heavily customized standard modules that are not documented in a machine-readable format. We identify custom objects during discovery by inspecting the live database schema against the standard ABRA Gen data dictionary. Each custom object is assessed individually: standard-mapping objects are mapped to Dolibarr llx_extrafields (extra fields on standard objects) or to a custom Dolibarr table; complex custom modules that exceed Dolibarr's schema flexibility are flagged as outside standard migration scope and documented for the customer.
ABRA Gen
BOM (Bill of Materials)
Dolibarr ERP
BOM (llx_product_bom)
lossyMulti-level BOMs from ABRA Gen's vyrobky require scoping before migration. Dolibarr's llx_product_bom table supports single-level BOMs natively; multi-level BOMs may require flattening into a single assembled product or manual reconstruction in Dolibarr's MRP module. We document the full ABRA Gen BOM hierarchy during discovery, map what is migratable, and flag any levels requiring manual rebuild. The MRP module must be installed and activated in Dolibarr before BOM data is loaded.
| ABRA Gen | Dolibarr ERP | Compatibility | |
|---|---|---|---|
| Firmy (Companies/Accounts) | ThirdParty (llx_societe)1:1 | Mapping required | |
| Odberatele (Customers) | ThirdParty (llx_societe) with client = 11:1 | Mapping required | |
| Dodavatele (Vendors) | ThirdParty (llx_societe) with supplier = 11:1 | Mapping required | |
| Zakazky (Jobs/Contracts) | Project (llx_projet)1:1 | Mapping required | |
| Sklady (Warehouses/Stock) | Warehouse (llx_entrepot)1:1 | Mapping required | |
| Vyrobky (Products/Items) | Product (llx_product)1:1 | Mapping required | |
| Doklady (Documents/Invoices) | Invoice/Order (llx_facture, llx_commande)1:1 | Mapping required | |
| Ucetni (Accounting Records) | Accounting entries (llx_accounting_account, llx_accounting_move, llx_accounting_movent)lossy | Mapping required | |
| Uzivatele (Users) | User (llx_user)1:1 | Mapping required | |
| Zamestnanci (Employees) | User or ThirdParty (llx_user, llx_societe for external)1:1 | Mapping required | |
| Custom Modules | Custom Objects or Extra Fields (llx_extrafields)lossy | Fully supported | |
| BOM (Bill of Materials) | BOM (llx_product_bom)lossy | 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.
ABRA Gen gotchas
On-premise deployment requires direct database access
Custom modules and extensions lack standard documentation
Historical accounting data retention obligations vary by jurisdiction
No publicly documented REST API for ABRA Gen
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
Access and discovery
We coordinate with the customer's IT team to obtain read-only database credentials for the ABRA Gen instance. We audit the live schema to identify which ABRA Gen modules are active (accounting, stock, production, CRM, HR), the total record counts per table, the active historical periods, and any custom modules or extensions that deviate from the standard ABRA Gen data dictionary. The discovery output is a written migration scope document listing every object to be migrated, the source table name, estimated record counts, and the mapping type (1:1, split, configuration, or flagged outside scope). We also confirm the target Dolibarr version and confirm that required Dolibarr modules (stock, accounting, project, MRP) are installed and activated.
Schema design for Dolibarr
We design the destination Dolibarr configuration based on the discovery output. This includes activating the required Dolibarr modules (ThirdParty, Product, Stock, Project, Invoice, Accounting, MRP), setting the country and currency defaults, importing or manually creating the chart of accounts mapped from the ABRA Gen COA, configuring warehouse records (llx_entrepot) matching the ABRA Gen sklady, and setting up user profiles (llx_user) corresponding to ABRA Gen role assignments. Custom ABRA Gen fields that map to Dolibarr extra fields are added as llx_extrafields on the corresponding standard object before data loading begins.
Data extraction and transformation
We extract data from the ABRA Gen database in dependency order: first the reference data (accounts, products, warehouses, contacts), then the transactional data (orders, invoices, stock movements, accounting entries), then the engagement and project data (zakazky, documents). Custom module tables are extracted separately and reviewed for mapping feasibility. We apply the COA mapping table to all accounting entries, resolve foreign-key references (supplier code to llx_societe ID, warehouse code to llx_entrepot ID, product code to llx_product ID) during the transform phase, and emit a pre-load validation report showing record counts, null-field counts, and any unmapped reference codes that require customer input.
Staging migration and reconciliation
We run a full migration into a staging Dolibarr instance (a separate installation or a development environment) using production-like data volume. The customer's administrator reconciles record counts against the ABRA Gen source (companies in, contacts in, products in, invoices in, stock quantities in, accounting entries in), spot-checks 25 to 50 records per object type against the ABRA Gen source for accuracy, and validates that Dolibarr's accounting balance (debit total vs credit total) matches the ABRA Gen ucetni closing balance. Any mapping corrections, COA gaps, or custom field issues are resolved at this stage before production migration begins.
Production migration in dependency order
We run production migration in record-dependency order. Reference data loads first: llx_societe (third parties), llx_product (products), llx_entrepot (warehouses), llx_user (users). Transactional data loads second: llx_projet (zakazky), llx_product_stock (stock quantities by warehouse), llx_facture and llx_facture_fourn (open documents), llx_accounting_movent (accounting entries). Each phase emits a row-count reconciliation report before the next phase begins. Closed fiscal-year documents are exported as PDF archives for legal retention rather than loaded into the live system unless the customer specifically requests it.
Cutover, validation, and supplemental handoff
We freeze ABRA Gen writes during cutover, run a final delta migration of any records created or modified during the migration window, then mark Dolibarr as the system of record. We validate Dolibarr's accounting trial balance against the ABRA Gen closing balances, confirm all warehouse stock quantities match the ABRA Gen sklady totals, and run a final record-count reconciliation across all object types. We deliver the custom module inventory and the user-role mapping document to the customer's administrator for post-migration rebuild and configuration. We support a one-week hypercare window for reconciliation issues; we do not rebuild ABRA Gen workflows, custom modules, or integrations as standard scope.
Platform deep dives
ABRA Gen
Source
Strengths
Weaknesses
Dolibarr ERP
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. All 8 core objects map 1:1 between ABRA Gen and Dolibarr ERP.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across ABRA Gen and Dolibarr ERP.
Object compatibility
All 8 core objects map 1:1 between ABRA Gen 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
ABRA Gen: Not publicly documented.
Data volume sensitivity
ABRA Gen 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 ABRA Gen to Dolibarr ERP migration scoping. Not seeing yours? Book a call.
Walk through your ABRA Gen 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 ABRA Gen
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.