Migrate from TechnologyOne to Dolibarr ERP

TechnologyOne's general ledger account hierarchy (account codes, account names, classification, balance type) maps directly to Dolibarr's accounting chart of accounts. We extract the full account structure via the Business View API or direct dataset query, preserving parent-child relationships as account groupings. Active and inactive account flags transfer. Balance-mapping rules require attention when organisations carry forward GL balances rather than starting from a clean ledger.

TechnologyOne supplier records (supplier code, name, address, payment terms, bank details, tax registration) map to Dolibarr Third-Party records with the Supplier flag enabled. Custom fields added to supplier records in TechnologyOne require field-level discovery during the scoping phase because there is no unified custom field registry. Payment terms migrate as Dolibarr code and label pairs.

TechnologyOne customer records map to Dolibarr Third-Party records with the Customer flag enabled. Contact details, billing addresses, and credit limits transfer. Customer-specific pricing rules require mapping to Dolibarr's price list system. Historical payment behaviour recorded in TechnologyOne's debtors module does not transfer as a behavioural score; the finance team recreates this assessment in Dolibarr manually.

Outstanding accounts payable records with payment arrangements, direct debit mandates, and prepayment schedules require careful sequencing to avoid triggering duplicate payment runs during import. We extract open AP items with their original invoice dates, amounts, due dates, and payment method references, then import them into Dolibarr as supplier invoices in unpaid status. Payment method mappings (BPAY, direct credit, cheque) must be configured in Dolibarr before AP import.

Outstanding accounts receivable with payment arrangements and bulk transaction histories migrate to Dolibarr customer invoices in unpaid status. We preserve original invoice numbers, invoice dates, due dates, and amount outstanding. Historical payment receipts linked to AR records are migrated as Dolibarr payment records after the parent invoice is imported. Credit notes and debit notes map to Dolibarr's credit note and reposition invoice types.

TechnologyOne HR module records (employee number, name, job title, department, compensation history, effective-dated changes) map to Dolibarr User records for system access and to HR/Payroll module records for employment details. Dolibarr's HR module stores hire date, position, salary, and leave balances. Compensation history requires mapping to Dolibarr's salary history feature if the module is activated. Effective-dated changes require careful sequencing to preserve the correct historical record.

TechnologyOne asset records with acquisition dates, acquisition cost, depreciation method, useful life, accumulated depreciation, and asset classification map to Dolibarr Asset records. Depreciation method mapping (straight-line, reducing balance, units of production) requires value-mapping between the two systems because terminology differs. Residual value and capital gain tracking fields migrate as Dolibarr custom fields if the standard asset record does not cover the requirement.

Purchase orders and purchase requisitions in TechnologyOne's procurement module map to Dolibarr Supplier Orders. We extract PO number, line items, quantities, unit costs, and approval status. Workflow state and approval history from TechnologyOne requires mapping to Dolibarr's validation workflow or manual re-approval after import. Partially received purchase orders map to Dolibarr reception records linked to the supplier order.

TechnologyOne ECM stores documents, document sets, compound documents, and custom document fields accessible via EzeScan CMIS-compatible endpoints. We extract document metadata (filename, classification, version, custom fields) and the document binary where accessible. Custom ECM fields require manual discovery by querying the source dataset directly because there is no self-documenting schema endpoint. Any missed custom fields result in blank values in migrated document records.

TechnologyOne's Property and Rating module (specific to local government customers) stores assessments, charge runs, and fee schedules. These do not have a direct Dolibarr equivalent. We map property records to Third-Parties with a custom type flag, rate assessments to Contract records, and charge runs to Dolibarr invoice generation templates. The billing engine's custom calculation rules require transformation logic built during the migration because Dolibarr's billing engine is general-purpose rather than rating-engine-specific.

TechnologyOne user accounts and role-based security profiles are tied to the CiA internal identity layer and UI configuration. We do not migrate user accounts because these must be recreated in Dolibarr as new User records with appropriate permissions configured by the customer's admin. Role mappings from TechnologyOne's security profiles do not transfer because Dolibarr's permission model is module-based rather than profile-based.

XlOne financial reports built against TechnologyOne's GL structure do not migrate directly because they reference TechnologyOne-specific field names and dataset IDs. We document every XlOne report during discovery with its data sources, filters, and calculation logic. The finance team receives a report remapping guide for Dolibarr's built-in report writer and ODT-based document templates. The underlying GL data migrates cleanly; only the reporting layer requires rebuild.