ERP migration

Migrate from ABRA Gen to Dolibarr ERP

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 logo

ABRA Gen

Source

Dolibarr ERP

Destination

Dolibarr ERP logo

Compatibility

75%

9 of 12

objects map 1:1 between ABRA Gen and Dolibarr ERP.

Complexity

BStandard

Timeline

3-5 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

ABRA Gen logo

ABRA Gen

What's pushing teams away

  • Global feature set of competitors like NetSuite and SAP S/4HANA Cloud surpasses ABRA Gen in multi-country consolidation, international reporting, and cloud-native architecture.
  • User interface and user experience lag behind modern SaaS ERPs, with desktop-client workflows that feel dated compared to browser-based alternatives.
  • Limited API ecosystem and third-party integrations restrict connectivity to modern e-commerce, CRM, and business intelligence platforms popular outside Central Europe.
  • Lower G2 rating (3.0/5) reflects consistent complaints about ease of use, steep learning curve for new users, and slower adoption of cloud and mobile capabilities.
  • Migration to international systems driven by company growth, acquisition, or desire to move to cloud infrastructure where ABRA Gen's on-premise deployment is a constraint.

Choosing

Dolibarr ERP logo

Dolibarr ERP

What's pulling them in

  • Free open-source core with no per-user license fee makes it the lowest-cost entry point for small teams needing ERP and CRM in one package.
  • Self-hosted deployment gives full data ownership and eliminates vendor lock-in, especially attractive to businesses with compliance requirements.
  • Modular architecture means teams enable only the features they use, keeping the interface uncluttered and reducing learning curve.
  • Fast installation with no technical knowledge required — one reviewer set up multiple businesses in minutes using their own hosting.
  • Active community forum and marketplace of third-party add-ons provide support and extension options without mandatory subscription costs.

Object mapping

How ABRA Gen objects map to Dolibarr ERP

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)

maps to

Dolibarr ERP

ThirdParty (llx_societe)

1:1
Mapping required

ABRA 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)

maps to

Dolibarr ERP

ThirdParty (llx_societe) with client = 1

1:1
Mapping required

ABRA 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)

maps to

Dolibarr ERP

ThirdParty (llx_societe) with supplier = 1

1:1
Mapping required

ABRA 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)

maps to

Dolibarr ERP

Project (llx_projet)

1:1
Mapping required

ABRA 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)

maps to

Dolibarr ERP

Warehouse (llx_entrepot)

1:1
Mapping required

ABRA 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)

maps to

Dolibarr ERP

Product (llx_product)

1:1
Mapping required

ABRA 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)

maps to

Dolibarr ERP

Invoice/Order (llx_facture, llx_commande)

1:1
Mapping required

ABRA 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)

maps to

Dolibarr ERP

Accounting entries (llx_accounting_account, llx_accounting_move, llx_accounting_movent)

lossy
Mapping required

Czech 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)

maps to

Dolibarr ERP

User (llx_user)

1:1
Mapping required

ABRA 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)

maps to

Dolibarr ERP

User or ThirdParty (llx_user, llx_societe for external)

1:1
Mapping required

ABRA 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

maps to

Dolibarr ERP

Custom Objects or Extra Fields (llx_extrafields)

lossy
Fully supported

ABRA 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)

maps to

Dolibarr ERP

BOM (llx_product_bom)

lossy
Fully supported

Multi-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.

Gotchas + challenges

What specifically takes care here

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 logo

ABRA Gen gotchas

High

On-premise deployment requires direct database access

Medium

Custom modules and extensions lack standard documentation

Medium

Historical accounting data retention obligations vary by jurisdiction

Medium

No publicly documented REST API for ABRA Gen

Dolibarr ERP logo

Dolibarr ERP gotchas

High

Foreign key constraint errors on cross-distribution database restore

High

SQL injection vulnerabilities in version 9.0.1

Medium

Custom fields stored as JSON in extraoptions require field-by-field deserialization

Medium

Decimal precision and rounding configuration affects price fields

Low

No native iOS/Android app forces reliance on browser

Pair-specific challenges

  • No ABRA Gen REST API; direct database access required

    ABRA Gen has no publicly documented REST API, so all migration work requires direct access to the underlying SQL or proprietary database. We coordinate with the customer's IT team to obtain read-only database credentials and perform extraction in a controlled maintenance window. This adds an access-coordination step that SaaS-to-SaaS migrations do not require. Cloud-hosted ABRA Gen instances have the same constraint; the on-premise versus cloud distinction does not change the extraction method for this pair.

  • Czech COA mapping to Dolibarr llx_accounting_account

    ABRA Gen's ucetni accounting module uses Czech-specific account codes and tax codes aligned with Czech statutory reporting. Dolibarr's accounting module requires manual chart-of-accounts setup or import of a country-specific COA template. We map the customer's existing ABRA Gen account codes to Dolibarr account numbers using a customer-supplied or generated mapping table, but Dolibarr's accounting module must be activated (Setup > Modules > Accounting) before any journal entries are loaded. Closed fiscal year journal entries should be exported as read-only archives for the retention period rather than loaded into the live system to avoid schema complexity.

  • Dolibarr major version migration schema changes

    Dolibarr's internal schema changes significantly between major versions (for example, Dolibarr 19 to 20 introduced database migration errors reported on the GitHub issue tracker, including ALTER TABLE constraint failures and key-length violations on PostgreSQL). We verify the target Dolibarr version before migration, run schema validation, and apply any required Dolibarr patch upgrades before loading data. If the customer is also migrating from an older Dolibarr version to a newer one as part of this project, we handle that as a separate upgrade step with the same database-migration best practices.

  • Custom ABRA Gen modules lack machine-readable documentation

    Many ABRA Gen implementations include custom modules or heavily customized standard modules that are not documented in a machine-readable format. We identify custom objects during the discovery phase by inspecting the live database schema and comparing it against the standard ABRA Gen data dictionary. Custom objects are mapped manually and flagged for customer review before load. If a custom module's schema cannot be reverse-engineered within the discovery window, it is documented as outside standard migration scope and added to the supplemental export list.

Migration approach

Six steps for a successful ABRA Gen to Dolibarr ERP data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Context on both ends of the pair

ABRA Gen logo

ABRA Gen

Source

Strengths

  • Purpose-built for Central European accounting and tax compliance including Czech and Slovak statutory requirements.
  • Comprehensive stock, warehouse, and production management with full BOM support for manufacturing.
  • Deep customization at module and field level for industry-specific process adaptation.
  • On-premise deployment option provides data residency and sovereignty control preferred in regulated industries.
  • Tens of thousands of users across 50+ countries with established regional partner network.

Weaknesses

  • Desktop-client architecture lags modern cloud-native ERP platforms in UX and accessibility.
  • Limited international reporting and multi-entity consolidation features compared to SAP or Oracle.
  • Sparse API documentation and third-party integration ecosystem restricts connectivity to modern platforms.
  • G2 rating of 3.0/5 reflects ongoing complaints about ease of use and outdated interface.
  • Cloud-first competitors have outpaced ABRA Gen in AI, automation, and real-time analytics capabilities.
Dolibarr ERP logo

Dolibarr ERP

Destination

Strengths

  • Free core software with AGPL license and no per-user mandatory fee for self-hosted deployments.
  • Modular architecture lets teams activate only needed features, keeping the interface focused and the database lean.
  • Self-hosted option provides full data sovereignty and avoids recurring SaaS subscription costs.
  • Built-in CSV/Excel import and export wizard with saved profiles simplifies recurring data operations.
  • Low-code Module Builder allows functional extensions without writing PHP code.

Weaknesses

  • No native documented REST API for programmatic bulk operations — all migrations depend on the import/export wizard or direct database access.
  • Reporting and analytics are weak without paid add-ons, and built-in charts are limited compared to modern SaaS platforms.
  • UI design is described as dated by multiple reviewers, with infrequent visual updates to the default theme.
  • Community-only support for self-hosted deployments means no SLA or guaranteed response time for issues.
  • Security vulnerabilities (CVE-2024-5314, CVE-2024-5315) in version 9.0.1 with no immediate patch reported.

Complexity grading

How hard is this migration?

Standard ERP migration. All 8 core objects map 1:1 between ABRA Gen and Dolibarr ERP.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across ABRA Gen and Dolibarr ERP.

  • Object compatibility

    A

    All 8 core objects map 1:1 between ABRA Gen and Dolibarr ERP.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    ABRA Gen: Not publicly documented.

  • Data volume sensitivity

    B

    ABRA Gen doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your ABRA Gen to Dolibarr ERP migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about ABRA Gen to Dolibarr ERP data migrations

Answers to the questions buyers ask most during ABRA Gen to Dolibarr ERP migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most migrations land between three and five weeks for accounts with up to 10,000 company records, 20,000 products, and one active warehouse with no complex BOM structures. Migrations with multi-entity accounting, five or more active warehouses, large journal-entry histories exceeding 100,000 posting rows, or complex production/BOM data requiring Dolibarr MRP module configuration move to eight to fourteen weeks because of chart-of-accounts mapping, COA validation, and production order scoping. Custom ABRA Gen modules add discovery and mapping time because they require schema comparison against the standard ABRA Gen data dictionary before any load begins.

Adjacent paths

Related migrations to explore

Ready when you are

Move from ABRA Gen.
Land in Dolibarr ERP, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day