ERP migration

Migrate from SAP S/4HANA Cloud to Dolibarr ERP

Field-level mapping, validation, and rollback between SAP S/4HANA Cloud and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.

SAP S/4HANA Cloud logo

SAP S/4HANA Cloud

Source

Dolibarr ERP

Destination

Dolibarr ERP logo

Compatibility

67%

8 of 12

objects map 1:1 between SAP S/4HANA Cloud and Dolibarr ERP.

Complexity

BStandard

Timeline

5-8 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from SAP S/4HANA Cloud to Dolibarr is a platform-shrinking migration, not a lateral move. SAP S/4HANA Cloud uses a highly normalized Business Partner model (unifying customer and vendor under a single BP key), a three-line item GL account structure (GL Account plus Company Code plus Operating Concern), and embedded analytics on in-memory HANA. Dolibarr is an open-source, self-hosted ERP/CRM for SMBs with a simpler third-party model, flat product catalog, and modular accounting that supports single-entity or multi-entity configurations. We extract SAP data through the OData API using migration objects scoped to the Migration Cockpit structure, handle parent-record lookup resolution across companies, and load through Dolibarr's REST API or direct database inserts for bulk operations. We do not migrate SAP workflows, BTP extensions, RISE contracts, or custom ABAP as code. We deliver a written inventory of every SAP automation, Fiori tile, and BTP service requiring rebuild or replacement in Dolibarr.

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

SAP S/4HANA Cloud logo

SAP S/4HANA Cloud

What's pushing teams away

  • Steep learning curve and complex navigation require extensive user training; simple tasks like checking PO receipt status can take too many clicks, frustrating day-to-day users.
  • High total cost of ownership including $100K+ annual subscriptions and $400K-$1M implementation fees creates a significant budget commitment that smaller organizations cannot sustain.
  • Limited customization in Public Cloud Edition forces organizations to adopt SAP's standard processes rather than accommodate existing workflows, causing friction during fit-to-standard workshops.
  • Integration with non-SAP or legacy systems requires additional tools and expertise, increasing migration complexity and overall project cost beyond initial estimates.
  • Vendor lock-in through RISE contracts wraps multiple services into a single agreement that is very difficult to unbundle, reducing flexibility for future platform changes.

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 SAP S/4HANA Cloud objects map to Dolibarr ERP

Each row shows how a SAP S/4HANA Cloud 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.

SAP S/4HANA Cloud

Business Partner (Customer and Vendor)

maps to

Dolibarr ERP

Third Party

1:1
Fully supported

SAP Business Partners (unified customer/vendor under a single BP number) map to Dolibarr Third Parties. In Dolibarr, a Third Party is created as either a customer, a supplier, or both. The SAP BP number becomes the Dolibarr ref_int field for cross-reference. SAP address roles (plant, sold-to, ship-to, bill-to) map to Dolibarr contact addresses with type labels. SAP payment terms from the BP master record become Dolibarr_cond_reglement entries. We split the unified BP into separate customer and supplier Dolibarr records if the source BP carries both roles and the destination requires separate tracking.

SAP S/4HANA Cloud

Business Partner Contact

maps to

Dolibarr ERP

Contact

1:1
Fully supported

SAP contact persons attached to a Business Partner (BUT000/BUT050) map to Dolibarr contacts linked to the corresponding Third Party via the socpeople FK. SAP roles (contact person, employee responsible, partner function) become Dolibarr contact roles. We preserve the SAP contact's email, phone, and functional title in Dolibarr's contact fields. Any BP contact without an email address is flagged for manual enrichment during migration.

SAP S/4HANA Cloud

Material / Product

maps to

Dolibarr ERP

Product

1:1
Fully supported

SAP Materials (MARAs) map to Dolibarr Products. SAP material type (HAWA for finished goods, HALB for semi-finished, ROH for raw material, VERP for packaging) maps to Dolibarr product type (0=product, 1=service). SAP units of measure from MARM map to Dolibarr unit_of_measure entries. The material number becomes Dolibarr's ref (with a length check; SAP 18-character keys are truncated to Dolibarr's 30-character limit without issue). Plant-specific stock data from MARD maps to Dolibarr stock_warehouse entries per warehouse.

SAP S/4HANA Cloud

Chart of Accounts

maps to

Dolibarr ERP

Accountancy Account

lossy
Fully supported

SAP's three-line GL account structure (GL Account key plus Company Code plus Operating Concern) requires flattening for Dolibarr's simple chart of accounts. We extract the SAP COA using the Company Code as the primary segment, preserving account number and description. Dolibarr uses a flat account number scheme (the 'pcg_version' structure). We map the most-used SAP account types (assets, liabilities, expenses, revenues) to the nearest Dolibarr chart of accounts template (PCMN standard French plan or a custom export from SAP). Country-specific tax codes from SKA1/KNT1 map to Dolibarr tax categories.

SAP S/4HANA Cloud

Journal Entry (Financial Document)

maps to

Dolibarr ERP

Accountancy Record (Bookkeeping Entry)

1:1
Fully supported

SAP journal entries (BKPF/BSEG) map to Dolibarr accounting entries (accounting_bookkeeping table). Each SAP document header (BKPF) becomes a Dolibarr piece_comptable with document_date, doc_ref, and label preserved. Each SAP line item (BSEG) becomes a Dolibarr tab_accounting_accounting. We map SAP posting keys (BSCHL) to Dolibarr debit/credit amounts. Historical entries are loaded in date-order with validated date ranges. Entries with uncleared open items (BSEG-AUGBL not populated) are flagged as open and require subsequent clearing in Dolibarr.

SAP S/4HANA Cloud

Open AR / Customer Invoice

maps to

Dolibarr ERP

Third Party (customer) + Invoice

1:many
Fully supported

SAP open receivables (BSEG with BUKRS=AR company code, KOART=K) map to Dolibarr customer invoices. The SAP customer BP becomes the Dolibarr Third Party; the invoice document number, amount, currency, and due date migrate. Open AR status is preserved as an unpaid Dolibarr invoice; partially cleared AR with partial payment history requires a payment record linked to the invoice. SAP's payment terms (ZTERM) map to Dolibarrcond_reglement.

SAP S/4HANA Cloud

Open AP / Vendor Invoice

maps to

Dolibarr ERP

Third Party (supplier) + Invoice

1:many
Fully supported

SAP open payables (BSEG with BUKRS=AP company code, KOART=K) map to Dolibarr supplier invoices. The SAP vendor BP becomes the Dolibarr Third Party; invoice number, amount, currency, and due date migrate. Open AP status is preserved as an unpaid Dolibarr supplier invoice. SAP's payment block indicator (SPERZ) and release reason (FRGZU) are stored in Dolibarr custom fields because the standard Dolibarr invoice model does not include these SAP-specific flags.

SAP S/4HANA Cloud

Sales Order

maps to

Dolibarr ERP

Proposal + Order

1:1
Fully supported

SAP Sales Documents (VBAK/VBAP) map to Dolibarr commercial proposals (for quotations in status QUOT, ORD) or directly to Dolibarr orders for firm orders (status OB). SAP header conditions (KONV) map to Dolibarr total and subtotal lines. SAP line-item pricing, quantity, and delivery dates migrate as line items with discount information. SAP's schedule lines (VBEP) are consolidated into a single delivery date per line item because Dolibarr does not support multi-schedule-line sales orders natively.

SAP S/4HANA Cloud

Purchase Order

maps to

Dolibarr ERP

Supplier Proposal + Order

1:1
Fully supported

SAP Purchase Orders (EKKO/EKPO) map to Dolibarr supplier orders (ask for quotation or purchase order depending on status). The SAP vendor BP becomes the Dolibarr Third Party; the PO number, currency, and incoterms (INCO1) migrate. Line items with material number, quantity, and net price migrate to Dolibarr purchase order lines. Delivery address from the SAP PO (ADRFP) maps to a Dolibarr contact address on the order. Confirmation control (BSTYP) and ordering party assignments are preserved in custom fields.

SAP S/4HANA Cloud

Project (PS Module)

maps to

Dolibarr ERP

Project

1:1
Fully supported

SAP PS module projects (PRPS) with WBS elements (PROJ/PRPS) map to Dolibarr Projects. The top-level WBS element becomes the Dolibarr Project; child WBS elements become sub-projects or tasks depending on nesting depth. SAP network activities (AFVC/AFVU) map to Dolibarr tasks with assigned resources and durations. SAP cost planning data (COSP/COVP) can be stored as Dolibarr expense entries linked to the project if the project's financial tracking is required. Projects without financial elements are migrated as operational Dolibarr projects only.

SAP S/4HANA Cloud

Custom Fields (EEWC)

maps to

Dolibarr ERP

Custom Fields

lossy
Mapping required

SAP S/4HANA Cloud custom fields created via the EEWC framework and exposed in the UI via Adapt UI map to Dolibarr extrafields. We audit the full list of active custom fields in SAP, map their data types to Dolibarr field types (varchar, int, datetime, select, chkbx, etc.), and pre-create the extrafields schema in Dolibarr before data migration. Fields that reference SAP-specific domain values (plant lists, company-code-specific picklists) may require a Dolibarr dictionary entry as the replacement lookup table. Custom fields on custom business objects follow the same pattern with the additional step of creating the corresponding Dolibarr module and table if the underlying module does not exist.

SAP S/4HANA Cloud

User / Business Role

maps to

Dolibarr ERP

User

1:1
Fully supported

SAP users with assigned business roles map to Dolibarr users. We extract the SAP user ID, email, first name, and last name from USR02/BAGR. The SAP user type (dialog, system, communication) determines whether a Dolibarr internal user or external user is provisioned. SAP role assignments (AGR_USERS) are preserved in a migration note because Dolibarr's permission model (PERMS) is structured differently. The customer's admin rebuilds role-based permissions in Dolibarr's home / admin / rights.php based on the exported SAP role inventory.

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.

SAP S/4HANA Cloud logo

SAP S/4HANA Cloud gotchas

High

Clean Core blocks in-app customizations on Public Cloud

Medium

OData API rate limits are per-endpoint, not tenant-wide

High

RISE/GROW contracts are nearly impossible to unbundle

High

In-memory data quality problems surface immediately post-go-live

Medium

Quarterly forced updates can break custom integrations

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

  • Dolibarr's REST API lacks bulk operations for large-volume loads

    Dolibarr's REST API (stable from v12 onward) supports individual record create, read, update, and delete operations but does not offer a bulk/batch endpoint comparable to SAP's OData with $top/$skiptoken pagination or a migration-cockpit object. For large-volume migrations (over 50,000 records of any object type), we fall back to direct SQL inserts into the Dolibarr database using a staging schema. This requires read access to the SAP source export and write access to the Dolibarr MySQL/PostgreSQL database. We validate all foreign key constraints (socid, fk_product, etc.) before each insert pass and lock the Dolibarr application during the migration window to prevent write conflicts.

  • SAP's multi-company structure has no native Dolibarr equivalent

    SAP S/4HANA Cloud typically operates across multiple company codes with inter-company transactions, consolidation ledgers, and company-code-specific chart of accounts segments. Dolibarr does not natively support multi-company posting within a single instance; each company requires either a separate Dolibarr instance or a manual consolidation outside the system. We scope the company code mapping during discovery, identifying which company codes represent separate legal entities versus profit centers within a single legal entity. Inter-company transactions (SAP R/3-style posting between BUKRS) cannot be natively migrated into Dolibarr and are flagged for manual re-entry or elimination in the consolidation workbook we deliver.

  • Custom fields in SAP's EEWC framework need explicit activation before export

    SAP S/4HANA Cloud requires custom fields to be explicitly enabled for use in relevant applications or APIs within their business context using the Custom Fields app before they appear in OData API responses or Migration Cockpit migration objects. We audit all EEWC custom fields in the SAP tenant before extraction and activate any fields that exist in the metadata but are not exposed to the API layer. Fields that have been created but never activated in their relevant business context may have no data in the OData extract even if they are populated in the SAP UI. We cross-reference the custom field list against the OData field list before migration begins and raise a discrepancy report if any expected fields are missing.

  • Dolibarr does not support SAP's batch-process document workflow

    SAP Sales and Purchasing documents use a release and approval workflow chain (bestellobligo for purchase requisitions, release strategies for POs, and output determination for sales orders) that Dolibarr does not natively replicate. Purchase orders in Dolibarr are created directly without a requisition-to-PO approval chain. We document every SAP release code, strategy, and workflow indicator and deliver it as a written workflow inventory. Rebuilding these approval chains in Dolibarr requires either a community module (workflow or approval) or custom PHP development and falls outside the standard migration scope.

  • SAP's tax codes and fiscal year variants require manual re-creation

    SAP tax codes (MWST, MWSK) and fiscal year variants (per BUKRS/T009) map to Dolibarr's tax system and fiscal year configuration. Each SAP tax code definition (MWSK) must be manually re-created in Dolibarr as a tax rate in the accounting setup because Dolibarr does not import tax code definitions. Similarly, SAP's special GL transactions (manual postings, down payments, bill-of-exchange processing) require manual configuration in Dolibarr. We deliver a complete tax code inventory extracted from SAP and a step-by-step guide for re-creating each one in Dolibarr / accounting / tax setup.

Migration approach

Six steps for a successful SAP S/4HANA Cloud to Dolibarr ERP data migration

  1. Discovery and Dolibarr edition selection

    We audit the source SAP S/4HANA Cloud tenant across deployment variant (Public, Private, RISE), enabled modules, company code count, active Business Partner roles, material type distribution, and GL account structure. We pair this with a Dolibarr edition and version decision: Dolibarr Community (free, self-hosted) covers most migrations; Dolibarr ERP Official Service ($600-$2,000/year) provides paid support for production environments. We also identify whether the migration uses Dolibarr's REST API (requires v12+ with MySQL 5.7+ or PostgreSQL) or requires direct database inserts for bulk operations. The discovery output is a written migration scope document covering all objects, estimated row counts, and the recommended API approach.

  2. Source SAP data extraction via OData and Migration Cockpit

    We extract data from SAP S/4HANA Cloud using the OData API scoped to Migration Cockpit migration objects. We configure endpoint-specific pagination (using $skiptoken for Product APIs, $top=5000 for Custom OData APIs, and $top=1000 for Purchase Order APIs) and implement exponential backoff on 429 responses. We extract Business Partners using the BusinessPartner OData API with address and role navigation properties resolved in a single batch request per BP to minimize API calls. We run a pre-extraction data quality scan that flags duplicate BPs, missing tax numbers, inconsistent GL account assignments, and orphaned open items before any data is pulled into the migration staging environment.

  3. Multi-entity architecture mapping and schema pre-creation in Dolibarr

    We map the SAP company code structure to the target Dolibarr deployment model. If the migration involves a single legal entity, we configure one Dolibarr instance with the company's chart of accounts and fiscal year. If multiple separate legal entities are involved, we either recommend separate Dolibarr instances per entity (for full isolation) or a single instance with third-party consolidation outside Dolibarr. We pre-create all Dolibarr extrafields for SAP custom fields, configure the chart of accounts using the PCMN template or a custom SAP export, and set up the tax rate table from the SAP tax code inventory. This step is validated in a Dolibarr sandbox before any production data is loaded.

  4. Third-party and product master migration

    We migrate SAP Business Partners as Dolibarr Third Parties (splitting customer and vendor roles where a BP carries both), then migrate materials as Dolibarr Products. Third-party records are loaded first because they are referenced by every downstream document (invoices, orders, projects). We resolve the SAP BP number as the Dolibarr ref_int cross-reference. Product records follow, with SAP material type mapped to Dolibarr product type. We cross-reference the SAP warehouse/plant codes from MARD against Dolibarr warehouse definitions and create any missing warehouse records before stock data is loaded.

  5. Open AP/AR and historical document migration

    We migrate open payables and receivables as Dolibarr supplier and customer invoices with unpaid status preserved. Each SAP open item (BSEG with AUGBL blank) generates a Dolibarr invoice record; the payment terms from the SAP vendor/customer master (ZTERM) are mapped to a Dolibarr payment condition. Historical sales orders and purchase orders are migrated next, followed by journal entries in chronological order. SAP journal entries with multi-line-item headers are decomposed into individual line records matching Dolibarr's bookkeeping table structure. Any SAP document with a payment block (SPERZ) is flagged with a custom note requiring manual review in Dolibarr.

  6. Cutover, validation, and workflow rebuild handoff

    We freeze SAP writes during the cutover window, run a final delta migration of any records modified during the migration process, then set Dolibarr as the system of record. We deliver the workflow inventory document (covering SAP release strategies, approval chains, and batch-process workflows), the tax code recreation guide, and the SAP-to-Dolibarr role mapping inventory for the customer's admin team to rebuild in Dolibarr. We support a one-week hypercare window where we resolve any reconciliation issues. We do not rebuild SAP workflows, BTP extensions, or Fiori tiles as code inside the migration scope; those are separate engagements for a Dolibarr partner or the customer's PHP developer.

Platform deep dives

Context on both ends of the pair

SAP S/4HANA Cloud logo

SAP S/4HANA Cloud

Source

Strengths

  • True real-time analytics on transactional data using the SAP HANA in-memory columnar database without pre-aggregation.
  • Unified data model eliminates traditional SAP ECC clustering tables, enabling simplified reporting and faster close cycles.
  • Quarterly auto-upgrades in Public Cloud deliver continuous innovation including embedded generative AI via Joule.
  • SAP Business Technology Platform (BTP) enables side-by-side extensibility without modifying the ERP core.
  • Industry-specific line-of-business products extend the core S/4HANA model for manufacturing, retail, and professional services.

Weaknesses

  • Implementation timelines range from 6 to 18 months with fixed-fee costs that can exceed the software subscription cost by 3-5x.
  • RISE with SAP contracts bundle S/4HANA, BTP credits, and Enterprise Support into a single agreement with significant exit barriers.
  • Public Cloud Edition enforces a Clean Core philosophy, restricting in-app customizations and requiring side-extensions on BTP instead.
  • Quarterly forced updates can disrupt custom integrations and reports written against specific S/4HANA versions.
  • Limited mobile support for dashboards and analytics features creates accessibility constraints for field and executive users.
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 SAP S/4HANA Cloud and Dolibarr ERP.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across SAP S/4HANA Cloud and Dolibarr ERP.

  • Object compatibility

    A

    All 8 core objects map 1:1 between SAP S/4HANA Cloud 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

    SAP S/4HANA Cloud: API-specific limits published per endpoint; Journal Entry API recommends max 15 parallel sync calls, 30 async; no tenant-wide X req/sec figure is published.

  • Data volume sensitivity

    A

    SAP S/4HANA Cloud exposes a bulk API — large-volume migrations stream efficiently.

Estimator

Estimate your SAP S/4HANA Cloud 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 SAP S/4HANA Cloud to Dolibarr ERP data migrations

Answers to the questions buyers ask most during SAP S/4HANA Cloud to Dolibarr ERP migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your SAP S/4HANA Cloud to Dolibarr ERP migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Migrations under five SAP company codes with no multi-entity consolidation and under 100,000 GL lines land between five and eight weeks. Migrations with multi-company structures, large historical transaction volumes (over one million journal entry lines), extensive SAP custom fields, or Dolibarr version upgrades (if the source data comes from an older SAP system) move to twelve to twenty weeks because of schema redesign, multi-entity boundary analysis, and custom field mapping work. Dolibarr version selection (v12+ for REST API versus direct database insert for older versions) is confirmed during discovery and affects the data-loading approach.

Adjacent paths

Related migrations to explore

Ready when you are

Move from SAP S/4HANA Cloud.
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