ERP migration

Migrate from Tryton to Dolibarr ERP

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

Tryton logo

Tryton

Source

Dolibarr ERP

Destination

Dolibarr ERP logo

Compatibility

92%

12 of 13

objects map 1:1 between Tryton and Dolibarr ERP.

Complexity

BStandard

Timeline

3-5 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Migrating from Tryton to Dolibarr is a move from a developer-oriented relational framework to a PHP-based SME ERP with a flatter data model. Tryton's PostgreSQL backend enforces referential integrity through its ORM, meaning every import must route through Tryton's Proteus library or server API rather than direct SQL. Dolibarr receives data via its CSV import module and REST API, which requires pre-formatting Tryton's relational Party, Order, and Invoice records into Dolibarr's denormalized third-party and document structures. The most consequential differences are Tryton's multi-company and OHADA accounting model versus Dolibarr's simpler single-company accounting, and the absence of an equivalent Analytic Accounting axis in standard Dolibarr. We pre-build the Dolibarr chart of accounts matching Tryton's account hierarchy, resolve currency and tax codes explicitly, and deliver a written accounting reconstruction plan for any OHADA configurations. Dolibarr's community-based support model mirrors Tryton's, but its PHP stack and larger SME user base make it more accessible to non-technical administrators managing day-to-day configuration.

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

Tryton logo

Tryton

What's pushing teams away

  • Steep developer learning curve—building custom modules and data import scripts requires Python and Tryton model knowledge that non-technical teams lack.
  • Search and UX performance frustrations—users report slow or unreliable search algorithms and a desktop-first interface that feels dated compared to modern SaaS ERP.
  • Limited turnkey support options—without a commercial vendor, companies without Python developers struggle to get timely help when issues arise.
  • Lack of native integrations with popular third-party tools forces custom API work to connect with e-commerce, payments, or BI platforms.

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 Tryton objects map to Dolibarr ERP

Each row shows how a Tryton 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.

Tryton

Party

maps to

Dolibarr ERP

Third Party

1:1
Fully supported

Tryton Parties (Customer, Supplier, Employee types) map to Dolibarr Third Parties with type toggling and category assignments. We extract address records, contact info, and fiscal identification numbers from Tryton's party_address and party_identifier tables and map them to Dolibarr's societe and contact tables. Party-specific fiscal identifiers (tax IDs, DUNS, SIREN) migrate as extrafields if configured in Dolibarr's extrafields table.

Tryton

Sale Quotation

maps to

Dolibarr ERP

Proposal (Customer Proposal)

1:1
Fully supported

Tryton Sale Quotations map to Dolibarr proposals. We preserve quotation state (quotation, confirmed, done, cancelled), all line-level pricing and taxes, and the party link via the third-party reference. Tryton Sale Line descriptions and product references map to Dolibarr propaldet lines with product and service association resolved via SKU lookup.

Tryton

Sale Order

maps to

Dolibarr ERP

Order (Customer Order)

1:1
Fully supported

Confirmed Tryton Sale Orders map to Dolibarr customer orders. Order states (processing, done, cancelled) migrate directly. Line-level taxes, discounts, and descriptions transfer as Dolibarr commandedet rows. Party linkage is resolved via the third-party mapping. Invoicing state is preserved by matching Tryton invoice references to the corresponding Dolibarr linked invoice record after invoice migration.

Tryton

Purchase Order

maps to

Dolibarr ERP

Order (Supplier Order)

1:1
Fully supported

Tryton Purchase Orders map to Dolibarr supplier orders. Supplier party references resolve via the third-party mapping. Expected delivery dates, line-level quantities, and prices transfer directly. Cancelled and done states migrate with the order header. We flag any Tryton purchase orders with unreceived quantities for manual reconciliation in Dolibarr.

Tryton

Invoice (Account Invoice)

maps to

Dolibarr ERP

Invoice (Customer or Supplier)

1:1
Fully supported

Tryton posted and paid invoices map to Dolibarr invoices with full line detail. Invoice state (draft, validated, posted, paid, cancelled) transfers through Dolibarr's document status workflow. We recompute tax and total amounts during import rather than relying on cached Tryton values, and flag any records where the migrated cached total deviates from the recomputed total by more than a rounding threshold. Open AR/AP balances migrate as move lines attached to the correct third-party account.

Tryton

Inventory and Stock Move

maps to

Dolibarr ERP

Product Stock

1:1
Fully supported

Tryton stock moves track goods from receipt to delivery with shipment states, warehouse assignments, and quantities. We map warehouse locations to Dolibarr entrepots, and lot numbers to Dolibarr's lot tracking where the Lot module is enabled. Inventory values at the point of migration transfer as Dolibarr stock value records. We flag any negative stock situations in Tryton for manual resolution before import.

Tryton

Chart of Accounts

maps to

Dolibarr ERP

Accounting Account

lossy
Fully supported

Tryton's account_chart model with account codes, names, and type hierarchy maps to Dolibarr's compta_account_general table. We preserve the full account code structure, account type (expense, revenue, receivable, payable, view), and parent hierarchy. Each Dolibarr account is created before any invoice or move line import to satisfy foreign-key constraints. OHADA-specific account charts require a dedicated mapping pass that respects the OHADA account classification scheme.

Tryton

Analytic Accounting

maps to

Dolibarr ERP

Analytic Account (optional module)

1:1
Mapping required

Tryton's AnalyticAccount model stores separate analytic axes against moves and invoices. Dolibarr's Analytic Accounting module (optional) uses a simpler flat account structure rather than Tryton's multi-axis model. We migrate analytic lines as Dolibarr analytic accounts, and where Tryton uses multiple analytic axes, we concatenate or prefix the axes in the Dolibarr analytic account name. The customer must enable the Analytic Accounting module before migration.

Tryton

Project and Work

maps to

Dolibarr ERP

Project

1:1
Fully supported

Tryton Project and Work entries with task hierarchy and time recording map to Dolibarr Projects. Project status (open, closed), assigned parties, and durations transfer directly. Task structure maps to Dolibarr subtasks within the project hierarchy. Active versus closed status is preserved on the project record.

Tryton

Bank Account and Cash Account

maps to

Dolibarr ERP

Bank Account

1:1
Fully supported

Tryton financial accounts for payments and cash migrate to Dolibarr bank accounts with their journal assignments and reconciliation settings. Open AP/AR balances transfer as move lines linked to the correct third-party account. Journal codes from Tryton map to Dolibarr's compta_account_journal table, and we flag any unsupported journal types for manual configuration.

Tryton

Document and Attachment

maps to

Dolibarr ERP

Document (Linked Files)

1:1
Fully supported

Tryton stores binary attachments as file_id references in ir_attachment. We run a pre-export pass that extracts file content by file_id, bundles attachments as a parallel export set, and re-attaches them in Dolibarr by matching the original file_id to the newly created record ID. Large attachments are chunked and validated against Dolibarr's file size limits. We flag any attachments exceeding PHP upload limits for pre-import configuration of the target server.

Tryton

User and Employee

maps to

Dolibarr ERP

User

1:1
Fully supported

Tryton Users and Employees are separate models with role-based access control. We migrate active users and their employee records to Dolibarr Users, remapping group memberships to Dolibarr permission groups (admin, user, readonly). The migration user's Dolibarr permissions must be set before employee records import. We do not migrate Tryton RBAC configurations directly; we deliver a written permission matrix for the Dolibarr admin to assign.

Tryton

Custom Fields and Properties

maps to

Dolibarr ERP

Extrafields

1:1
Mapping required

Tryton's dynamic field extension via ir.model.field migrates to Dolibarr's extrafields per-entity tables. We query the Tryton ir_model_field table during scoping, extract custom field definitions with their types and constraints, and create equivalent Dolibarr extrafields before data import. Fields referencing lookups to other models require pre-creation of the target extrafield and resolution of the foreign key during data migration.

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.

Tryton logo

Tryton gotchas

High

PostgreSQL-only deployment with strict foreign-key constraints

High

Series-skip migration requires sequential manual steps

Medium

OHADA accounting context changes account schema

Medium

Invoice amount caches must be recomputed post-import

Low

Binary attachment storage via file_id requires separate file export

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

  • Tryton ORM prohibits direct SQL import

    Tryton enforces referential integrity and business logic validation at the ORM layer. Direct PostgreSQL INSERT statements risk violating constraints in ir_ui_view, ir_action_act_window, and ir_translation tables, and may leave invoice amount caches stale. We route all Tryton exports through the Proteus Python library to invoke model methods directly, ensuring that state transitions, party assignments, and tax computations fire correctly. This means the export phase requires a running Tryton server environment with appropriate module activation.

  • Dolibarr third-party model flattens Tryton party types

    Tryton separates Customer, Supplier, and Employee as distinct party type assignments on a single Party record. Dolibarr uses a single Third Party entity with type toggles and category assignments to distinguish customer from supplier roles. When a Tryton party serves both as customer and supplier, it creates two Dolibarr third-party records (one customer, one supplier) that must be linked via the foreign key or a shared identifier. We generate a party-type decision matrix during scoping to resolve which records need duplication and which can be single-typed.

  • OHADA accounting requires manual reconstruction in Dolibarr

    Tryton's OHADA-compliant accounting module uses a structured account classification scheme with account types, sub-types, and legal numbering not natively replicated in Dolibarr's standard accounting chart. Companies using OHADA in Tryton must manually rebuild the chart of accounts in Dolibarr or engage a partner with OHADA localization experience. We flag OHADA accounts separately during scoping, export the complete account hierarchy with OHADA codes, and deliver a written chart-of-accounts reconstruction guide with the equivalent Dolibarr account structure.

  • Dolibarr CSV import does not preserve move line relationships

    Tryton's accounting moves carry detailed debit/credit line records with account, party, and reconciliation references. Dolibarr's CSV import module ingests documents at the header level but does not natively reconstruct complex move-line structures with partial reconciliations. We handle this by pre-formatting Tryton move lines into Dolibarr-compatible accounting entries via the Dolibarr API or direct SQL, bypassing the CSV module for accounting data. Any partial payment reconciliations from Tryton must be manually re-established in Dolibarr's reconciliation tool post-import.

  • Binary attachments depend on PHP server configuration

    Dolibarr stores attachments in the filesystem or database depending on the Dolibarr configuration (MAIN_UPLOAD_DOCUMENT constant). Tryton stores attachments as file_id references requiring a separate file export pass. We validate the target Dolibarr server's PHP upload limits (upload_max_filesize, post_max_size) and Dolibarr's document storage configuration before migration. Attachments exceeding configured limits require server-side configuration changes before import begins.

Migration approach

Six steps for a successful Tryton to Dolibarr ERP data migration

  1. Scoping and dependency audit

    We audit the Tryton deployment across series version, active modules, and custom field extensions. We identify all Party types, order states, invoice states, stock move volumes, account codes, and attachment counts. We validate OHADA configuration presence, multi-company setup, and analytic accounting axis usage. We confirm the Dolibarr target version, enabled modules, and PHP/database configuration. The scoping output is a written migration scope document with a per-object row count, a party-type decision matrix, and a chart-of-accounts reconstruction flag for OHADA cases.

  2. Tryton export via Proteus and data transformation

    We run a pre-export validation pass on the Tryton PostgreSQL database to confirm ir_module_module and ir_module_dependency table names match the target series. We execute the Proteus Python library against the Tryton server to export Parties, Orders, Invoices, Inventory, and Account records in dependency order. We transform each record set into Dolibarr-compatible CSV format, mapping Tryton field names and types to Dolibarr field names and types, resolving party-type duplication decisions, and flattening analytic accounting axes into Dolibarr analytic account names.

  3. Dolibarr schema pre-configuration

    Before any data import, we configure the Dolibarr target: we enable required modules (Third Party, Product, Proposal, Order, Invoice, Stock, Accounting, Project, Bank), create extrafields matching Tryton custom fields, create the chart of accounts via Dolibarr's account import with codes and hierarchy matching Tryton, configure the OHADA or standard chart-of-accounts structure based on the scoping flag, and set up warehouse locations, product categories, and sales and purchase tax rates.

  4. Sandbox import and reconciliation

    We run a full migration into a staging Dolibarr environment using production-like data volumes. We validate third-party record counts, order and invoice totals, account balance reconciliation against Tryton trial balance, and attachment linkage against the original Tryton ir_attachment file set. The customer reconciles key business records (10-20 randomly sampled orders, invoices, and third parties) and signs off before production migration. Mapping corrections are captured here.

  5. Production migration in dependency order

    We execute production migration in strict sequence: chart of accounts first (to satisfy foreign keys), then third parties, products, warehouse stock, proposals, customer orders, supplier orders, invoices, bank accounts, project records, and binary attachments. Each phase emits a row-count reconciliation report. We recompute invoice tax and total amounts post-import using Dolibarr's built-in recalculation where available, and flag any amounts deviating from the Tryton source beyond a rounding threshold.

  6. Cutover, validation, and accounting reconstruction handoff

    We freeze Tryton writes during a defined cutover window, run a delta migration of any records modified during the migration period, and switch the system of record to Dolibarr. We deliver the OHADA chart-of-accounts reconstruction guide, the Analytic Accounting mapping document, and a written permission matrix for the Dolibarr admin to assign. We do not rebuild Tryton workflows, alerts, or data export scripts as Dolibarr equivalents; that scope is documented separately for the customer's admin or implementation partner.

Platform deep dives

Context on both ends of the pair

Tryton logo

Tryton

Source

Strengths

  • Fully open-source with no per-user or per-transaction license fees, eliminating vendor lock-in at the infrastructure level.
  • Three-tier architecture with a clean Python codebase lets developers extend and integrate without proprietary tooling.
  • Modular design—companies activate only the modules (accounting, sales, inventory, manufacturing) relevant to their operations.
  • PostgreSQL backend provides transactional integrity and standard SQL tooling for reporting and backup.
  • Multi-company and multi-currency capabilities built into core modules, not add-ons.

Weaknesses

  • No commercial vendor behind the platform—support relies on community forums and third-party service providers.
  • Desktop-first UX and search performance lag behind modern SaaS ERP alternatives, according to user reviews.
  • Developer learning curve is steep; non-technical teams cannot self-serve configuration or data imports without Python expertise.
  • Limited pre-built integrations with modern SaaS tools; most require custom API or middleware work.
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 Tryton and Dolibarr ERP.

B

Overall complexity

Standard migration

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

  • Object compatibility

    A

    All 8 core objects map 1:1 between Tryton 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

    Tryton: Not publicly documented by the Tryton Foundation.

  • Data volume sensitivity

    A

    Tryton exposes a bulk API — large-volume migrations stream efficiently.

Estimator

Estimate your Tryton 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 Tryton to Dolibarr ERP data migrations

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

Can't find your answer?

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

Book a free 30 minute consultation

Migrations under 15,000 third parties, 5,000 orders, and 2,000 invoices with a standard accounting chart and no OHADA or multi-company complexity land between three and five weeks. Projects involving OHADA chart reconstruction, Analytic Accounting axis migration, multi-company structures, or large attachment sets move to eight to twelve weeks because of the manual chart-of-accounts work and file export validation.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Tryton.
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