Migrate from TechnologyOne to Microsoft Dynamics 365 Business Central

TechnologyOne's general ledger structure extracts from the Business View API as a full account hierarchy with account codes, descriptions, account types, and balance mappings. We map each TechnologyOne account to a Microsoft Dynamics 365 Finance & Operations Main Account (AccountNum) or Business Central G/L Account, preserving the full hierarchy as dimension values or segment codes. For OneCouncil and OneEducation customers, we verify whether specialised account structures are in use and map them to the destination legal entity chart of accounts. Parent-account relationships resolve via the hierarchy mapping during import. This is always the first object migrated because all financial transactions depend on it.

TechnologyOne stores customer and supplier master records in the financials module. We extract contact details, payment terms, credit limits, ABN (for Australian organisations), and bank account details via Business View API. Customers map to Dynamics 365 Customer (CustTable in Finance & Operations; Customer in Business Central), and suppliers map to Vendor (VendTable / Vendor). Custom fields on customer or supplier records require discovery-phase field auditing against the dataset because TechnologyOne stores custom properties as dataset-level additions with no unified registry. Payment terms map by code; credit limit maps to the CreditMax field.

Open accounts payable and accounts receivable with payment arrangements, direct debits, and prepayments are supported with careful sequencing. We extract open items from the financials module including invoice numbers, due dates, amounts, and payment method. The import sequence is designed to avoid triggering duplicate payment runs in Dynamics 365: vendor payment journals and customer billing journals are created as open items rather than posted invoices, allowing the AP/AR team to review before completing payment setup. Payment arrangement records with scheduled instalment plans map to the Dynamics 365 payment schedule feature.

Asset registers including acquisition dates, depreciation methods, book values, asset classifications, locations, and insurance values extract from the Assets module API. We map TechnologyOne depreciation methods (straight-line, diminishing value, sum-of-years digits) to Dynamics 365 depreciation conventions (straight-line service life, reducing balance). Accumulated depreciation and net book value transfer as separate financial dimensions. Asset tags and custom fields map to Fixed Asset dimensions and user-defined fields in the destination. Government customers with grant-funded assets need fund-code tracking, which requires a custom financial dimension in the destination.

HR and payroll records including job titles, department assignments, employment status, compensation history, and effective-dated changes extract from the HR module. We map to Dynamics 365 Human Resources Worker (HcmWorker) in Finance & Operations or Business Central. Effective-dated employment history is preserved as position assignment records with valid-from and valid-to dates. Compensation history maps to the HR compensation fixed and variable plans. Custom HR fields (leave entitlements, union memberships, government clearance levels) require field-level discovery during the audit phase because they vary by customer configuration.

Purchase orders, purchase requisitions, and receipt records extract via the Business View API for procurement. Workflow states and approval histories from TechnologyOne require mapping to the destination purchase workflow configuration. Open purchase orders migrate with line details, delivery addresses, and item quantities; completed POs migrate as history only. Approval chain mapping requires the customer to confirm which approval thresholds apply in Dynamics 365, as TechnologyOne approval rules are often embedded in the workflow configuration and must be rebuilt rather than transferred.

TechnologyOne ECM stores documents, document sets, compound documents, and custom document fields accessed via the EzeScan CMIS-compatible connector. We extract document metadata, relationships, and binary content, then link documents to the corresponding record in Dynamics 365 via SharePoint integration or Dataverse. Custom document fields require pre-migration auditing against the live ECM environment because no self-documenting schema endpoint exists; any missed custom fields result in blank values in the destination. We use the EzeScan CMIS endpoints to enumerate all custom field definitions before extraction begins.

Property and Rating module data — rate assessments, charge runs, fee schedules, and ratepayer records — is specific to local government customers using TechnologyOne OneCouncil. We extract assessments, rating categories, property addresses, valuation data, and outstanding balance records. The TechnologyOne billing engine uses custom calculation rules that require transformation to Dynamics 365 because no direct equivalent exists in the standard Finance & Operations or Business Central data model. We create custom rate and assessment entities in the destination and build a transformation specification covering charge run logic, rate category mapping, and arrears handling. Business rules for rate exemptions and concessions are documented separately for the customer to configure.

Organisations using XlOne for financial reporting have built complex spreadsheet and report definitions tied to TechnologyOne GL account codes and dataset IDs. We do not migrate XlOne reports directly because the field names and dataset identifiers are TechnologyOne-specific and do not resolve in Dynamics 365. We deliver a written XlOne inventory during discovery, cataloguing every report's structure, parameters, and GL account references. The finance team uses this inventory to recreate reports in Power BI or Dynamics 365 Financial Reporting. The underlying GL data — chart of accounts, transaction history, and balance information — migrates in full.

Custom fields added to any standard TechnologyOne object are stored in the dataset without a unified custom field registry. We discover all custom properties during the discovery phase by querying the dataset directly or via EzeScan for ECM custom fields. Each custom field is mapped to the equivalent Dynamics 365 field type (text, number, date, picklist, checkbox) and applied to the target object. Custom field discovery is iterative: we run a field-level audit against the live dataset, produce a custom field manifest, and map each entry before data extraction begins. Any custom fields not discovered before extraction result in data loss in the destination.

GL transaction history including journal entries, posting dates, amounts, and account assignments extracts from the Business View API. We migrate the full balance history for reconciliation purposes and all open financial periods as open journal lines. Closed periods from TechnologyOne migrate as posted journal batches in Dynamics 365. Multi-currency transactions require exchange rate mapping from TechnologyOne's currency settings to the destination exchange rate table. Government customers with fund-accounting requirements need financial dimension setup for fund codes, which is configured before GL migration begins.

User accounts and role-based security profiles in TechnologyOne are tied to the internal CiA identity layer and role/user interface configuration. We do not migrate user accounts because they must be provisioned directly in Dynamics 365 using Entra ID or the customer's identity provider. We deliver a role-mapping guide that pairs each TechnologyOne role with the equivalent Dynamics 365 security role, page-level security duty, and team structure, enabling the customer's admin to provision users post-migration. Active versus inactive status from TechnologyOne maps to the enabled/disabled user state in Dynamics 365.