Migrate from TechnologyOne to Odoo ERP

TechnologyOne's GL account hierarchy with fund accounting and account codes maps to Odoo's Accounting > Chart of Accounts structure. We extract the full account tree via Business View API or direct dataset access, preserving parent-child relationships and account type classifications. Fund ledger splits in TechnologyOne map to separate Odoo account groups or analytic accounts depending on the customer's reporting requirements. Odoo's country-specific chart of accounts templates (AU, NZ) provide a baseline; the customer's custom account codes and fund structures are added during import.

TechnologyOne customer master records including contact details, payment terms, credit limits, and custom fields map to Odoo Contact records with the Customer flag enabled. Payment terms (Net 30, EOM) migrate to Odoo's Payment Term lines. Credit limits and custom debtor fields transfer to custom fields on the Contact model. We deduplicate by customer code or ABN where applicable.

TechnologyOne supplier master records map to Odoo Contact records with the Vendor flag enabled. Payment terms, bank details, and custom fields migrate similarly to the customer mapping. Tax registration numbers (ABN for AU) transfer to the Contact's Tax ID field.

Open accounts payable records with payment arrangements, direct debit mandates, and prepayment schedules migrate as Odoo Vendor Bills (account.move records with move_type = 'in_invoice'). We sequence open items carefully to avoid triggering duplicate payment runs during import. Bulk transaction histories that span multiple fiscal periods are split into separate Vendor Bills by invoice date.

Open accounts receivable records migrate as Odoo Customer Invoices (account.move with move_type = 'out_invoice'). Payment arrangements and direct debit schedules transfer to Odoo's Account Payment model. Historical invoice aging reports are preserved as analytic line entries for reporting continuity.

TechnologyOne asset registers with acquisition dates, depreciation schedules, and asset classifications map to Odoo Asset records. Depreciation methods (straight-line, reducing balance, units of production) require value-mapping reconciliation because Odoo's asset depreciation methods have specific configuration requirements. We extract the asset's NBV at the point of migration and set Odoo's asset value accordingly.

TechnologyOne HR module employee records including job titles, department assignments, compensation history, and effective-dated changes migrate to Odoo HR Employee records. Effective-dated changes require sequencing to preserve history in Odoo's employee activity log. We do not migrate payroll processing data that sits in a separate payroll system unless it is part of the HR module dataset.

TechnologyOne purchase orders and purchase requisitions with workflow states and approval histories map to Odoo Purchase Orders. Approval history migrates as internal notes or a custom activity log. Open Purchase Orders at cutover migrate with their current state; closed POs are documented for reporting continuity. Odoo requires the vendor Contact to exist before PO creation, so vendor import precedes PO import.

TechnologyOne ECM stores documents, document sets, compound documents, and custom document fields accessible via EzeScan CMIS-compatible endpoints. We extract document metadata and relationships, preserving the document's folder path as Odoo Tags or a custom Folder model. Custom ECM fields require pre-migration field-level audit against the live ECM environment because there is no self-documenting schema endpoint for custom fields. Document binary files migrate as attachments to the related Odoo record (Contact, Asset, PO, Invoice) where a relationship is identifiable.

TechnologyOne's Property and Rating module (specific to local government customers) stores assessments, charge runs, and fee schedules. The billing engine uses custom calculation rules that require transformation logic specific to each customer's rate schedule. We map ratepayer records to Odoo Contact, assessment balances to Account Move lines, and document the charge run structure for the customer's admin to configure in Odoo Accounting or a custom module.

TechnologyOne custom fields added to any standard object are discovered during the discovery phase via dataset query or EzeScan field audit. Each custom field is mapped individually to an Odoo custom field (via Studio on Enterprise, or Python ir.model.fields definition on Community/Standard). Field type mapping must be explicit: TechnologyOne string fields map to Odoo char or text; date fields map to Odoo date; lookup fields map to Odoo many2one or selection depending on the target model.

TechnologyOne user accounts and role-based security profiles are tied to the internal CiA identity layer and CI-role UI configuration. These do not migrate because they must be recreated in Odoo with Odoo's own user management, access rights groups, and multi-company setup. We document the TechnologyOne role hierarchy during discovery so the customer's Odoo administrator can rebuild access groups in Odoo Studio or via system configuration.