Migrate from Priority ERP to Dolibarr ERP

Priority Customers map to Dolibarr Third Parties with the Tiers type flag set to Customer. Priority's multi-address hierarchies (billing and shipping) map to Dolibarr's address contact fields, with the primary address stored on the Third Party record and secondary addresses stored as Dolibarr contact records linked to the parent societe. Price lists and credit limits from Priority's customer record migrate as Dolibarr custom fields; the customer approves these during scoping.

Priority Vendors map to Dolibarr Third Parties with the Fournisseur type flag set. Purchasing terms, payment days, and bank details from the Priority vendor record map to Dolibarr's supplier-specific fields. Pay-to and ship-from address hierarchies decompose into Dolibarr contact records under the supplier Third Party in the same manner as customer address handling.

Priority Items with stocking dimensions and BOM links map to Dolibarr Products. Items flagged as sellable map to Product type=M(Product), purchasable items map to type=M(Product) with supplier refs, and non-stocked items map to type=S(Service). Multi-warehouse quantities in Priority map to Dolibarr warehouse stock lines (stock_warehouse table), one row per warehouse per product. BOM relationships do not migrate as linked structures; we document each Priority BOM as a written product assembly record for manual entry in Dolibarr's Manufacturing module if activated.

Priority Sales Order headers (customer reference, terms, freight, order date) map to Dolibarr commandeclient. Priority multi-line order details map to commande_fournisseurdet (Dolibarr's order line object) with pricing, discounts, and tax allocation preserved. The customer reference from Priority becomes the ref_customer field in Dolibarr, and the Priority order number becomes the ref field. Line status (fulfilled, backordered, cancelled) maps to the Dolibarr line status enum.

Priority Purchase Orders follow a mirror structure to Sales Orders but belong to the Vendor dimension. We extract PO headers and lines, mapping them to Dolibarr commandefournisseur and its line table (commandefournisseurdet), with attention to the vend.accounting account mapping for cost of goods sold. Any Priority PO linked to a Goods Receipt (receipt) creates a Dolibarr supplier order in ordered or received status based on receipt date.

Priority's multi-segment account codes (for example, 01-100-320 representing company-department-cost center) require structural decomposition into Dolibarr's flat account model. We extract the full Priority account tree, then map each segment into separate Dolibarr fields: the primary segment becomes the account number, and secondary segments are stored in auxiliary dimension fields or as tags on the account record. The customer approves the decomposition strategy during scoping. Any Priority accounts where segment semantics cannot be cleanly represented in Dolibarr's flat model are flagged explicitly.

Outstanding Priority invoices and credit memos map to Dolibarr factureclient (for AR) and facturefournisseur (for AP) in open status. Due dates and aging buckets migrate as-is; Dolibarr calculates aging at query time using the due date. We sequence the load order so that Third Parties (Customers and Vendors) are inserted before any open invoice records, preventing orphaned aging entries. Aging totals are validated post-load against Priority's open invoice aging report.

Priority Projects with budgets, milestones, and WBS rows map to Dolibarr projet. We extract project headers and associated task rows (WBS), time entries, and billing records, mapping them to Dolibarr projet and task tables. Priority's project status enum maps to Dolibarr's fk_status values. Any Priority project-level custom fields migrate as Dolibarr extrafields on the projet table, subject to the same approval process as other custom fields.

Priority Employee records map to Dolibarr Users (user table) with organizational assignment and role mapping. Salary, compensation history, and benefits data require explicit customer sign-off before migration; we treat this as sensitive personal data and do not include it in the standard migration package unless specifically authorized. Role-based permissions from Priority map to Dolibarr's profile-based security model.

Priority GL Journal Entries with debit and credit lines map to Dolibarr's accounting module entries (accounting Journal objects). Each Priority journal line maps to an eCompt一支 or Bank record with the account number resolved to the decomposed Dolibarr account. Reversing entries and recurring templates from Priority are documented as written records for manual configuration in Dolibarr. Posting date, period, and source reference migrate as-is to preserve the GL audit trail.

Priority document attachments stored as file references linked to parent records (Customers, Orders, Projects) are exported to a file store and imported into Dolibarr's document management system (llx_document or the document directory structure). We create link records in Dolibarr pointing to the stored files, preserving the association to the parent Third Party, Order, or Project. We validate attachment integrity during extraction and log any files that cannot be retrieved, excluding them from the migration package with an explicit count in the final validation report.

Priority's form generator and workflow builder create business logic embedded in the UI layer that does not export via API. This includes conditional field validations, approval chains, and form-level calculations. We document every active custom form and workflow during the discovery phase and deliver a written inventory with the migration package. The customer's admin rebuilds these rules manually in Dolibarr using Dolibarr's workflow module, third-party workflow plugins, or custom PHP modules. This rebuild work is outside the standard migration scope and is handled as a separate engagement.