ERP migration

Migrate from Sage 100cloud to Dolibarr ERP

Field-level mapping, validation, and rollback between Sage 100cloud and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.

Sage 100cloud logo

Sage 100cloud

Source

Dolibarr ERP

Destination

Dolibarr ERP logo

Compatibility

83%

10 of 12

objects map 1:1 between Sage 100cloud and Dolibarr ERP.

Complexity

BStandard

Timeline

4-8 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from Sage 100cloud to Dolibarr is a migration from a legacy on-premise-plus-cloud-connected ERP with no public REST API to an open-source modular ERP/CRM with a documented REST API and MySQL/PostgreSQL backend. The core challenge is that Sage 100cloud exposes no live transactional export endpoint — all extraction requires read-only SQL access to Pervasive SQL or Microsoft SQL Server, either on the customer's network or via VPN. We establish that connection during discovery, extract the full account master, customer and vendor records, inventory with BOM hierarchies, open invoice registers, and job costing phases and transactions, then transform and load into Dolibarr's corresponding tables. We flag custom UDFs as a manual re-entry step, preserve fiscal-year locked-period status, and deliver a written inventory of any Sage workflows or job-costing schedules that require admin rebuild in Dolibarr Projects and Contracts. Open AR/AP balances transfer as open invoices and supplier invoices respectively; historical GL transactions transfer as journal entries if the target fiscal periods are unlocked.

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

Sage 100cloud logo

Sage 100cloud

What's pushing teams away

  • Escalating subscription costs combined with module-specific licensing fees produce bills that grow faster than the business, driving mid-market customers toward flat-rate or unlimited-user platforms.
  • Persistent software glitches and performance slowdowns in database-heavy operations frustrate finance teams running month-end close under tight deadlines.
  • Limited automation and inability to configure workflow preferences force staff into repetitive manual tasks that modern cloud ERPs handle natively.
  • No modern REST API for live transactional data means integrations with CRMs, e-commerce platforms, and analytics warehouses require fragile workarounds or third-party middleware.
  • The underlying MAS 90/200 codebase shows its age in UI/UX, creating a steep learning curve for new employees and contributing to staff turnover.

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 Sage 100cloud objects map to Dolibarr ERP

Each row shows how a Sage 100cloud 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.

Sage 100cloud

GL Account (Chart of Accounts)

maps to

Dolibarr ERP

Plan Comptable / Account

1:1
Fully supported

Sage 100cloud stores the chart of accounts as a flat list of account codes with optional Type, Division, and Department segments in the GL_Account master table. Dolibarr uses a plan comptable with up to 8 segment positions (configurable under Home > Setup > Chart of Accounts). We parse the Sage account code structure, split segments based on the customer's account mask (e.g., 4-2-2-4), and write each segment into the corresponding Dolibarr account_code_devise and account_parent fields. Account type (A for Asset, L for Liability, R for Revenue, E for Expense) maps directly to Dolibarr's account_type field. Account descriptions and active/inactive status migrate as-is.

Sage 100cloud

Customer (AR_Customer master)

maps to

Dolibarr ERP

Third Party (mode = Customer)

1:1
Fully supported

Sage AR_Customer records include billing/shipping addresses, payment terms, credit limits, salesperson assignments, and 1099 settings. We map these to Dolibarr's societe table with a thirdparty_type of 'Customer' and populate address fields via the societe_address table. Payment terms reference the Sage terms_code mapped to Dolibarr's condicionesreglement table. Credit limit and salesperson assignment become custom extrafields or native Dolibarr fields depending on whether the customer enables the corresponding module. Email, phone, and website from Sage map to Dolibarr's phone, fax, mail, and url fields.

Sage 100cloud

Vendor (AP_Vendor master)

maps to

Dolibarr ERP

Third Party (mode = Supplier)

1:1
Fully supported

Sage AP_Vendor records mirror the customer schema with the addition of 1099 settings and W-9 status flags. We map to Dolibarr's societe table with thirdparty_type = 'Supplier'. The 1099 flag from Sage maps to a Dolibarr extrafield since standard Dolibarr does not include 1099-specific fields. Vendor address and payment terms migrate identically to the customer path. We flag any vendor with an outstanding W-9 status of Pending or Expired in a sidecar CSV for the customer's admin to resolve in Dolibarr's document management module.

Sage 100cloud

Inventory Item (IC_Item, IC_BOM)

maps to

Dolibarr ERP

Product (with BOM where applicable)

1:1
Fully supported

Sage IC_Item stores SKU, description, unit of measure, cost method (FIFO, Average, Standard), minimum stock levels, and warehouse/bin assignments. Multi-warehouse and multi-bin records in IC_BinDetail map to Dolibarr's stock warehouses and product_stock tables. Lot/serial tracking data from IC_Lot and IC_Serial map to Dolibarr's batch_number and serie_number fields if the Lot/Serial module is enabled. Bill of Materials from IC_BOM and IC_BOMDetail migrate as Dolibarr product-bom entries with the Manufacturing / MPR module. We preserve the Sage cost_method as a Dolibarr extrafield since Dolibarr's default costing is average cost.

Sage 100cloud

Open AR Invoice (AR_Invoice header + lines)

maps to

Dolibarr ERP

Invoice / Facture

1:1
Fully supported

Open accounts receivable are exported as Dolibarr Facture records with type = 'Invoice' and status = 'Unpaid'. Sage invoice header fields (invoice number, invoice date, due date, amount, balance) map directly. Invoice line items map to Dolibarr's facturedet table with product reference, description, quantity, unit price, and VAT code resolved from the Sage tax table. Sage invoice-level discounts and freight charges become separate Dolibarr invoice line entries. We preserve the original Sage invoice number in Dolibarr's ref_supplier field for audit traceability. Invoices with a status of Paid are migrated as Facture with status = 'Paid' and payment date set from AR_Payment.

Sage 100cloud

Open AP Invoice (AP_Invoice header + lines)

maps to

Dolibarr ERP

Supplier Invoice / Facture Fournisseur

1:1
Fully supported

Open accounts payable records from Sage AP_Invoice and AP_Payment tables migrate as Dolibarr Facture (type = 'SupplierInvoice') linked to the vendor Third Party record. Invoice date, due date, vendor invoice number, and amount remaining map to the corresponding Dolibarr fields. We also export Sage payment records to create Dolibarr PaiementFournisseur entries with the payment amount and date. Historical AP checks that have been issued but not cleared are migrated as open AP with a payment status flag, and the customer reconciles the payment method in Dolibarr's bank reconciliation module post-migration.

Sage 100cloud

Fixed Assets (FA_Asset register)

maps to

Dolibarr ERP

Asset / Immobilisation

1:1
Fully supported

Sage FA_Asset records include acquisition date, acquisition cost, depreciation method (straight-line, declining balance, sum-of-years), accumulated depreciation, net book value, useful life, and asset category. We map these to Dolibarr's Asset module if the Immobilisation module is enabled. Sage depreciation methods are translated to Dolibarr's amortization_type and amortization_rate fields. FA_Asset category codes map to Dolibarr's asset_type classification. Depreciation schedules are reconstructed as Dolibarr amortization lines with the original Sage journal entry dates. If the Dolibarr Immobilisation module is not active at migration time, we deliver the asset register as a structured CSV with a mapping guide for manual entry.

Sage 100cloud

Sales Order (SO_SalesOrder header + lines)

maps to

Dolibarr ERP

Commercial Proposal or Order (Commande)

1:1
Fully supported

Sage open sales orders migrate to Dolibarr's Commande table with status = 'Draft' or 'Validated' depending on whether fulfillment has begun. The sales order number maps to Dolibarr's ref field. Line items map to Dolibarr's commandedet table with product reference, quantity ordered, unit price, and warehouse assignment. Sage order total, tax amount, and discount percentage recalculate against the Dolibarr line entries during the transform step to ensure totals match. Orders that are fully shipped in Sage map to Dolibarr shipments ( Expedition ) rather than Orders.

Sage 100cloud

Purchase Order (PO_PurchaseOrder header + lines)

maps to

Dolibarr ERP

Supplier Order (CommandeFournisseur)

1:1
Fully supported

Sage PO records migrate to Dolibarr's CommandeFournisseur table. We flag partially-received POs during discovery because Sage inventory receipts may have already been applied in IC_InventoryReceipt without closing the PO. The customer decides whether to migrate the PO as an open order with remaining receipts pending or to close the PO and enter receipts as separate Dolibarr incoming shipment records. PO line items map to Dolibarr's commandedetfourn with product reference, quantity ordered, quantity received, and unit cost. Unit cost from Sage becomes Dolibarr's purchase_price field.

Sage 100cloud

Job Costing Records (JC_Job, JC_Transaction)

maps to

Dolibarr ERP

Project and Task

1:many
Fully supported

Sage JC_Job tables hold project structures with phases, cost codes, and budget vs. actual tracking at the JC_Transaction level. Dolibarr has no native cost-code structure — we map each Sage JC_Job to a Dolibarr Project with Phase mapped to a Task at the top level, and Sage cost codes mapped to Task notes or custom extrafields. Budget vs. actual amounts migrate as Task-level custom extrafields (budget_amount, actual_amount, variance). The customer activates Dolibarr's Project module before migration. We note that Sage job costing workflows (approval routing, cost-code validation) have no Dolibarr equivalent and document the rebuild scope in the automation inventory deliverable.

Sage 100cloud

Payroll History (PR_Payroll, PR_Employee)

maps to

Dolibarr ERP

HR Module: Employee and Salary

1:1
Fully supported

Sage payroll tables (PR_Payroll and PR_Employee) contain employee records with year-to-date earnings, tax withholdings, and benefit deductions. We map active employees to Dolibarr's llx_societe_per_user table and payroll registers to llx_salary. Garnishment setups and deduction codes require manual mapping to Dolibarr's salary withholding configuration. If the customer has enabled the HR module, we also map employee addresses, emergency contacts, and employment status. Note that Sage payroll configurations (tax table setups, deduction rules, garnishment logic) are not migratable to Dolibarr and require manual reconfiguration by the customer's HR administrator.

Sage 100cloud

Custom UDFs / Extension Tables

maps to

Dolibarr ERP

Extrafields (sidecar CSV for manual re-entry)

lossy
Fully supported

Sage 100cloud stores user-defined fields in module-specific extension tables (IC_Item_UDF, AR_Customer_UDF, etc.) whose schema varies by company database. There is no standardized export path for these. We identify every UDF column during discovery by querying the SQL schema for non-standard columns per module, export them to a sidecar CSV named per module (e.g., customer_udfs.csv, vendor_udfs.csv, item_udfs.csv), and deliver a mapping guide showing each UDF column name, data type, and the corresponding Dolibarr extrafields module field creation steps. The customer's admin creates the extrafields in Dolibarr and imports the sidecar CSV manually after migration. This is a customer-visible step that must be planned and budgeted separately.

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.

Sage 100cloud logo

Sage 100cloud gotchas

High

No native REST API exposes live transactional data

High

Rate limits and login attempt thresholds block API access

Medium

Parallel Migration Wizard breaks after moving to a new installation

Medium

Custom UDFs and custom fields have no standardized export path

Low

Historical GL periods may be locked or archived

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

  • Sage 100cloud exposes no REST API — all extraction requires SQL access

    Sage 100cloud does not publish a public REST or GraphQL API for real-time export of transactional records. All data extraction requires read-only SQL queries against the underlying Pervasive SQL or Microsoft SQL Server database. This means migration tooling must run on the customer's network, connect via VPN, or use a remote SQL access method approved by the customer's IT security policy. We establish a secure SQL read-only connection during the discovery phase, extract data views that mirror the Sage Business Objects Information (BIE) layer, and validate row counts before beginning transformation. If the customer's Sage database is hosted on a Sage Partner Cloud instance, we coordinate with the hosting partner to obtain database credentials with read-only access.

  • Custom UDFs have no standardized export path and require manual re-entry in Dolibarr

    Sage 100cloud stores user-defined fields in module-specific extension tables that vary between company databases and are not exposed through any standard export utility or BIE data view. We identify every UDF during discovery by querying the SQL schema for non-standard column names per module, export them to a sidecar CSV, and deliver a step-by-step Dolibarr extrafields configuration guide. The customer's admin creates matching extrafields in Dolibarr and imports the sidecar CSV manually after migration. This step is excluded from standard migration scope and must be planned as a separate administrative task with its own timeline and resource allocation.

  • Job costing cost codes and budget structures require manual reconstruction in Dolibarr Projects

    Sage's JC_Job and JC_Transaction tables provide a structured cost-code hierarchy with phases, cost types, and budget vs. actual tracking. Dolibarr's Project module has no native cost-code structure — cost tracking is limited to Task-level time and expense entries. We map Sage JC_Job to Dolibarr Projects and JC_Transaction budget amounts to Task extrafields, but Sage-specific cost-code validation workflows (approval routing, code enforcement) have no Dolibarr equivalent. We deliver a written inventory of every Sage job costing workflow and recommend a Dolibarr Projects rebuild approach (using the Tasks and Expenses modules) for the customer's project management team.

  • Historical GL periods may be locked, preventing journal entry import

    Sage 100cloud allows period locking at the fiscal-year level, preventing new journal entry postings to closed periods. If the migration scope includes historical GL transactions (FY2023 and earlier, for example), we must verify during discovery that the source periods are not locked and that the year-end roll-forward has been completed in Sage. Locked periods can be unlocked by a Sage administrator before migration but require elevated access and a business decision about audit integrity. We recommend migrating open periods and the current fiscal year in full, with historical GL data transferred as an opening balance journal entry rather than line-by-line transactions if period locking cannot be resolved.

  • Partially-received POs require scoping decision before migration

    Sage purchase orders frequently contain partial receipts already applied in the IC_InventoryReceipt table without the PO being closed. Migrating the PO as-is into Dolibarr without flagging these partial receipts results in duplicate inventory entries. We identify every Sage PO with open receipts during discovery and present the customer with two options: migrate the PO as an open supplier order with remaining receipts tracked as Dolibarr incoming shipments, or close the Sage PO and re-enter remaining receipts as separate Dolibarr documents. The customer makes this decision before the PO migration phase begins.

Migration approach

Six steps for a successful Sage 100cloud to Dolibarr ERP data migration

  1. Discovery and SQL access provisioning

    We audit the source Sage 100cloud database via read-only SQL connection, cataloging record counts across GL_Account, AR_Customer, AP_Vendor, IC_Item, IC_BOM, AR_Invoice, AP_Invoice, FA_Asset, SO_SalesOrder, PO_PurchaseOrder, JC_Job, JC_Transaction, PR_Employee, and PR_Payroll. We identify custom UDF extension tables by querying sys.columns for non-standard column names per module. We check fiscal period lock status in GL_Period. We confirm the Sage database type (Pervasive SQL or Microsoft SQL Server) and obtain read-only credentials from the customer's IT team or Sage Partner Cloud host. The discovery output is a written migration scope with record counts per object and a UDF inventory CSV.

  2. Dolibarr environment provisioning and module activation

    We provision a clean Dolibarr installation (self-hosted on the customer's infrastructure or cloud VM) and activate the modules required by the migration scope: Third Parties, Products, Invoices, Orders, Suppliers, Projects, HR/Payroll, Assets, and any premium modules (MPR for BOM, Lot/Serial for inventory tracking). We configure the chart of accounts structure to match the Sage account code mask before any GL data loads. We create the warehouse and bin locations that correspond to Sage's IC_BinDetail records. We enable extrafields for any Sage UDFs that the customer's admin will re-create manually.

  3. Sandbox migration and reconciliation

    We run a full migration into the provisioned Dolibarr environment using production-equivalent data volumes. The customer's finance and operations leads reconcile record counts and spot-check 25-50 random records against the Sage source. GL account balances are verified against Sage's trial balance report. Open AR/AP totals in Dolibarr are matched to the Sage aged receivable and payable reports. Inventory quantities per warehouse are verified against Sage's IC_Inventory valuation report. Any mapping corrections are documented and applied before the production migration phase begins.

  4. Production migration in dependency order

    We run production migration in record-dependency order: Chart of Accounts (plan comptable), Third Parties (customers then vendors), Products (with BOM hierarchies reconstructed from IC_BOM/IC_BOMDetail), Fixed Assets, Open AR Invoices (with payment history), Open AP Invoices (with payment history), Sales Orders, Purchase Orders, and Job Costing Projects. GL opening balances post as journal entries if historical periods are locked. Payroll history loads last. Each phase emits a row-count reconciliation report before the next phase begins. We use Dolibarr's REST API for record inserts where supported and direct MySQL INSERT for bulk loads to maximize throughput.

  5. Custom UDF delivery and manual re-entry handoff

    We deliver the UDF sidecar CSVs (one per Sage module with custom fields) along with a Dolibarr extrafields configuration guide written for the customer's admin. The guide specifies the exact Dolibarr admin path (Home > Setup > Modules > Extrafields), the target table name, the field label, data type, and the import steps for the CSV. We do not create Dolibarr extrafields or import UDF data as part of standard migration scope because the schema changes require admin-level access and represent a business configuration decision. This step is tracked as a separate deliverable with a separate completion timeline.

  6. Cutover, validation, and automation rebuild inventory handoff

    We freeze Sage 100cloud writes during a cutover window, run a final delta migration of any records modified during the migration period, then mark Dolibarr as the system of record. We verify GL trial balance, open AR/AP aging, and inventory quantities one final time. We deliver a written inventory of Sage workflows, job-costing approval routing, and payroll deduction configurations requiring rebuild in Dolibarr's Project Tasks, Agenda, and HR modules. We support a one-week hypercare window for reconciliation issues. We do not rebuild Sage workflows or payroll configurations as part of standard migration scope.

Platform deep dives

Context on both ends of the pair

Sage 100cloud logo

Sage 100cloud

Source

Strengths

  • GAAP-compliant core accounting with integrated bank reconciliation and tax table automation.
  • Multi-warehouse inventory with multi-bin support, lot/serial tracking, and BOM management.
  • Flexible module selection allows businesses to adopt incrementally rather than deploying the full suite at once.
  • Job costing and project cost tracking built natively into the ERP for project-based businesses.
  • Strong partner ecosystem with certified Sage Business Partners offering implementation and support.

Weaknesses

  • No public REST API for live transactional data — all data extraction requires SQL access or third-party middleware.
  • Legacy MAS 90/200 codebase limits UI modernization and slows workflow automation improvements.
  • Frequent software glitches and performance degradation reported across G2 and Capterra reviews.
  • High and increasing subscription costs with module-gated features that inflate the total cost of ownership.
  • Limited native integrations with modern CRMs, e-commerce platforms, and analytics tools.
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. 1 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Sage 100cloud and Dolibarr ERP.

  • Object compatibility

    B

    1 of 8 objects need a mapping; the rest are 1:1.

  • 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

    Sage 100cloud: 100 req/min per company; 5,000 req/day per company; 20 failed login attempts per hour before 24-hour lockout.

  • Data volume sensitivity

    B

    Sage 100cloud doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Sage 100cloud 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 Sage 100cloud to Dolibarr ERP data migrations

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

Can't find your answer?

Walk through your Sage 100cloud to Dolibarr ERP migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Standard migrations covering GL accounts, customers, vendors, open AR/AP, and inventory under 15,000 total records complete in four to eight weeks. Migrations that include job costing with budget vs. actual phases, multi-warehouse inventory with BOM hierarchies, payroll history, or a partially-failed prior Sage migration move to ten to sixteen weeks because of schema reconciliation work, BOM hierarchy reconstruction, and GL period lock resolution. The primary timeline driver is data extraction readiness from the SQL database and the availability of the customer's finance team for reconciliation sign-off.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Sage 100cloud.
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