ERP migration
Field-level mapping, validation, and rollback between VAIL-ERP and Dolibarr ERP. We move data and schema; workflows are rebuilt natively in Dolibarr ERP.
VAIL-ERP
Source
Dolibarr ERP
Destination
Compatibility
9 of 12
objects map 1:1 between VAIL-ERP and Dolibarr ERP.
Complexity
BStandard
Timeline
5-8 weeks
Overview
Moving from VAIL-ERP to Dolibarr is a structural migration that requires extracting data from a proprietary platform with no public API into an open-source modular system where every module must be explicitly enabled and configured. VAIL-ERP organizes data across patients, encounters, employees, suppliers, inventory items, financial transactions, and departments; Dolibarr uses ThirdParty (split by type), Product, User, and accounting module records with a chart-of-accounts structure that must be designed before data arrives. We coordinate with Velosi to obtain database-level exports or CSV dumps for each module, enumerate VAIL-ERP's custom field definitions during discovery, and configure Dolibarr's HRM, accounting, stock, and third-party modules to receive the migrated records with their foreign-key relationships preserved. Healthcare-specific fields such as insurance codes, referral sources, and clinical flags map to Dolibarr ExtraFields that must be provisioned before import. Workflows, automations, and portal configurations do not migrate; we deliver a written inventory of these for the customer's admin to rebuild in Dolibarr or configure via Dolibarr's built-in workflow engine.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a VAIL-ERP 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.
VAIL-ERP
Patient
Dolibarr ERP
ThirdParty (type=Customer) + Contact
1:1VAIL-ERP patient records include demographics, insurance details, and clinical identifiers across modules. We map patient demographics to Dolibarr ThirdParty with type set to Customer, and clinical attributes (insurance codes, referral sources, referral provider IDs) to Dolibarr ExtraFields on the ThirdParty record. Encounter-linked identifiers migrate as contact associations. Dolibarr's ThirdParty object does not natively support clinical encounter linking, so we use Projects or a dedicated ExtraFields structure to maintain the patient-to-encounter relationship post-migration.
VAIL-ERP
Encounter
Dolibarr ERP
Project or ExtraFields on ThirdParty
lossyVAIL-ERP encounters carry provider assignments, encounter-type codes, timestamps, and clinical notes linked to patient records. Dolibarr has no native clinical encounter object. We map encounters to Dolibarr Projects with a custom project type (Encounter) and link each project to the patient ThirdParty via the Project contact association. Encounter-type codes and provider references become project ExtraFields. Historical encounter notes migrate as Project notes. This approach preserves the patient-encounter relationship but requires the customer to enable the Projects module before migration.
VAIL-ERP
Employee
Dolibarr ERP
User + HRM module
1:1VAIL-ERP employee profiles include job titles, department assignments, compensation history, and effective-dated changes across HR and finance modules. We map employee records to Dolibarr User records for system access and to HRM module Employee records for HR attributes (contract type, salary, start date, department). Department assignments resolve via the Departments mapping. Compensation history migrates as HRM salary records linked to each Employee.
VAIL-ERP
Supplier
Dolibarr ERP
ThirdParty (type=Supplier)
1:1VAIL-ERP supplier records carry contact details, agreed pricing agreements, and contract references from the procurement module. We map suppliers to Dolibarr ThirdParty with type set to Supplier. Agreed pricing and contract references migrate as supplier ExtraFields or as entries in Dolibarr's supplier price module. Supplier contact persons map to Dolibarr Contacts linked to the supplier ThirdParty.
VAIL-ERP
Inventory Item
Dolibarr ERP
Product (type=Stock)
1:1VAIL-ERP inventory items include part numbers, descriptions, stock levels, reorder points, and multi-site location assignments. We map these to Dolibarr Product records with type=Stock. Stock levels and warehouse locations migrate into Dolibarr's Stock module with warehouse records created per VAIL-ERP location. Reorder points become ExtraFields on Product. Multi-site deployments require warehouse records in Dolibarr before stock data imports.
VAIL-ERP
Department
Dolibarr ERP
Project (category=Department) or ExtraFields category
1:1VAIL-ERP departments and cost centers are referenced across HR (employee assignments), finance (budget allocation), and inventory (multi-site warehouse linkage) modules. We map department records to Dolibarr Projects with a Department category or as a dedicated category in ExtraFields, and create these first as reference data so that all downstream foreign-key references in employee, transaction, and inventory imports resolve correctly.
VAIL-ERP
Chart of Accounts
Dolibarr ERP
Accounting Account
1:1VAIL-ERP chart-of-accounts structure defines account codes used across all financial transactions. We extract the full account list from the finance module and map each account code to a corresponding Dolibarr Accounting Account record, preserving account type (asset, liability, equity, income, expense), parent account hierarchy, and active/archived status. Inactive or archived accounts in VAIL-ERP are flagged in the mapping for the customer's admin to review before final import.
VAIL-ERP
Financial Transaction
Dolibarr ERP
Accounting Entry (EcritureComptable) or Invoice/Supplier Invoice
1:manyVAIL-ERP AP/AR ledger entries and journal transactions carry account codes, transaction dates, amounts, and currency. Open AP/AR items migrate as Dolibarr Customer Invoices or Supplier Invoices. Historical journal entries migrate as Dolibarr Accounting Entries with debit and credit lines mapped to the chart-of-accounts mapping. Open-item status (paid, unpaid, partially paid) is preserved from VAIL-ERP. Currency amounts migrate as-is; multi-currency requires enabling Dolibarr's multi-currency module before migration.
VAIL-ERP
Tax Code
Dolibarr ERP
Accounting Tax
1:1VAIL-ERP tax codes apply rate, jurisdiction, and applicability flags to financial transactions and inventory items. We map tax code definitions to Dolibarr Accounting Tax records with rate, account assignment, and applicable module flags. Tax codes used in open transactions are flagged for the customer's admin to verify jurisdiction mapping before close-out. Dolibarr's tax module must be configured before transaction imports begin.
VAIL-ERP
User Account
Dolibarr ERP
User
1:1VAIL-ERP user accounts carry role assignments tied to module access and active/inactive status. We map user records to Dolibarr User with login, email, and status preserved. Role mappings from VAIL-ERP become Dolibarr permission profiles assigned to each User. Users without email addresses in VAIL-ERP require an email field populated before migration or an alternate login identifier configured.
VAIL-ERP
Custom Field (per-module)
Dolibarr ERP
ExtraFields (per-entity)
lossyVAIL-ERP custom fields for healthcare-specific attributes (insurance codes, referral sources, clinical flags, patient status codes) are enumerated during the discovery phase by reviewing sample records since no schema export is available. Each discovered custom field maps to a corresponding Dolibarr ExtraFields definition on the target entity (ThirdParty, Product, Project, User) with equivalent datatype (string, integer, select, checkbox, date). Custom fields discovered after the import mapping is finalized require a re-run of the affected module's import. We document every ExtraFields definition in the migration spec before any data loads begin.
VAIL-ERP
Document
Dolibarr ERP
Document (linked to entity)
1:1VAIL-ERP attaches documents to patients, encounters, suppliers, and HR records with file name, type, attached entity reference, and date. We export document metadata and the file binaries, then reattach them in Dolibarr to the corresponding entity (ThirdParty, Project, Product, User) via Dolibarr's document management linking. File type and original upload date are preserved in the Dolibarr document record. Binary files are stored in Dolibarr's designated document directory structure.
| VAIL-ERP | Dolibarr ERP | Compatibility | |
|---|---|---|---|
| Patient | ThirdParty (type=Customer) + Contact1:1 | Fully supported | |
| Encounter | Project or ExtraFields on ThirdPartylossy | Fully supported | |
| Employee | User + HRM module1:1 | Fully supported | |
| Supplier | ThirdParty (type=Supplier)1:1 | Fully supported | |
| Inventory Item | Product (type=Stock)1:1 | Fully supported | |
| Department | Project (category=Department) or ExtraFields category1:1 | Fully supported | |
| Chart of Accounts | Accounting Account1:1 | Mapping required | |
| Financial Transaction | Accounting Entry (EcritureComptable) or Invoice/Supplier Invoice1:many | Fully supported | |
| Tax Code | Accounting Tax1:1 | Fully supported | |
| User Account | User1:1 | Fully supported | |
| Custom Field (per-module) | ExtraFields (per-entity)lossy | Fully supported | |
| Document | Document (linked to entity)1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
VAIL-ERP gotchas
No publicly documented API for programmatic data export
Module-specific custom fields lack a published schema reference
Direct database access requires Velosi cooperation
Dolibarr ERP gotchas
Foreign key constraint errors on cross-distribution database restore
SQL injection vulnerabilities in version 9.0.1
Custom fields stored as JSON in extraoptions require field-by-field deserialization
Decimal precision and rounding configuration affects price fields
No native iOS/Android app forces reliance on browser
Pair-specific challenges
Migration approach
Discovery and Velosi extraction coordination
We audit the VAIL-ERP deployment across all active modules (patients, encounters, employees, suppliers, inventory, finance, departments, users) and enumerate custom field definitions by reviewing sample records. In parallel, we open a coordination request with Velosi to arrange database-level exports or structured CSV packages for each module. The discovery output is a written migration scope, a data volume estimate per module, and a Velosi extraction timeline. If Velosi extraction is delayed, we explore admin-portal CSV export as a fallback with contingency time added to the schedule.
Dolibarr environment setup and module configuration
We configure the destination Dolibarr instance: enabling required modules (ThirdParty, Contact, Product, User, HRM, Accounting, Stock, Projects), designing the chart of accounts based on the VAIL-ERP account structure, provisioning ExtraFields to match VAIL-ERP custom fields, and creating warehouse records for each VAIL-ERP inventory location. We deploy this configuration in a staging environment first for validation against the extracted data.
Sandbox migration and reconciliation
We run a full migration into the Dolibarr staging environment using production-like data volume from the Velosi extraction. The customer's admin reconciles record counts (patients in, employees in, suppliers in, inventory items in, transactions in) and spot-checks 25-50 random records against the VAIL-ERP source. Special attention is given to encounter-to-patient linkage and financial transaction-to-account mapping. The customer signs off the schema and mapping before production migration begins.
Department and reference data migration first
We migrate reference data first because it is referenced by downstream records: departments (resolved as Projects or categories), chart of accounts, tax codes, and warehouse records. These establish the lookup keys used by all subsequent imports. Migration cannot proceed past this step until reference data reconciliation is complete.
Production migration in dependency order
We run production migration in record-dependency order: reference data (departments, accounts, tax codes, warehouses), users and employees, third parties (patients and suppliers), inventory items, encounter history (as Projects), financial transactions (invoices, AP/AR, journal entries), and documents. Each phase emits a row-count reconciliation report before the next phase begins. We use Dolibarr's native CSV import wizard for flat-file ingestion and the REST API for programmatic record creation where batch loading improves performance.
Cutover, validation, and workflow inventory handoff
We freeze VAIL-ERP writes during cutover, run a final delta migration of any records modified during the migration window, then enable Dolibarr as the system of record. We deliver a written inventory of VAIL-ERP workflows, automations, and portal configurations with recommended Dolibarr equivalents (Dolibarr's built-in workflow engine, module-specific triggers, or community modules such as Workstation or ModuleBuilder for custom automation). We support a one-week hypercare window where we resolve reconciliation issues. Workflow and automation rebuilds are outside standard migration scope and require a separate engagement.
Platform deep dives
VAIL-ERP
Source
Strengths
Weaknesses
Dolibarr ERP
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. 1 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across VAIL-ERP and Dolibarr ERP.
Object compatibility
1 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
VAIL-ERP: Not publicly documented — typical SaaS limits assumed and confirmed during scoping..
Data volume sensitivity
VAIL-ERP doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during VAIL-ERP to Dolibarr ERP migration scoping. Not seeing yours? Book a call.
Walk through your VAIL-ERP to Dolibarr ERP migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave VAIL-ERP
Other ways to arrive at Dolibarr ERP
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.