Migrate from TechnologyOne to Epicor Prophet 21

TechnologyOne's general ledger chart of accounts maps to Epicor ERP's COA structure with account segments. We extract the full account hierarchy (account code, description, account type, balance type) via the Business View API or direct dataset access. The mapping preserves account codes as Epicor Account fields and maps account types to Epicor financial series (Asset, Liability, Equity, Revenue, Expense). Multi-segment COAs in TechnologyOne map to Epicor's segment-enabled COA configuration. Balance carry-forward dates and opening balances are extracted as GL records for Epicor's first open period.

Historical GL journal entries from TechnologyOne Financials migrate as Epicor GL Trans records. We extract journal date, posting date, debit/credit amounts, account reference, source module, and reference number. The GL must be migrated before any AP, AR, or procurement records that reference accounts, because Epicor validates account existence at posting time. We sequence the GL import first and resolve any accounts that exist in transactions but not in the COA as part of the mapping. Fiscal period and year boundaries are mapped to Epicor's open accounting periods.

TechnologyOne customer and supplier master records live in the Financials module and map to Epicor Customer and Supplier (Vendor) records respectively. We extract contact details, payment terms, credit limits, bank account information, and address structures. Custom fields on customer or supplier records are discovered during the ECM field audit phase and mapped to Epicor User-Defined Fields (UDFs) on the respective entity. Payment terms transform from TechnologyOne codes to Epicor Payment Terms lookup values.

Accounts payable open items including supplier invoices, credit notes, and payment arrangements migrate to Epicor AP Invoice and AP Payment. We sequence open AP items carefully to avoid triggering duplicate payment runs in Epicor's cash management module during import. Direct debit arrangements and prepayment records from TechnologyOne map to Epicor Prepaid Invoice and Prepayment Application records. Historical payment records that affect open item balance (part-payments, holds) are attached as notes on the migrated AP Invoice.

Accounts receivable open items including customer invoices, credit notes, and direct debit collections migrate to Epicor AR Invoice and AR Payment. We preserve customer payment terms, invoice due dates, and any aged balances. Payment arrangements stored in TechnologyOne are recreated as Epicor Recurring Invoice schedules or attached as notes on the parent AR Invoice. Bulk transaction histories (repeated direct debits or batch receipts) are migrated as Epicor Cash Receipt batches to maintain the payment run audit trail.

TechnologyOne Assets module records (asset register, depreciation schedules, acquisition dates, asset classifications, locations) migrate to Epicor Asset Management. Depreciation methods may differ between platforms (straight-line, reducing balance, units-of-production) and require value-mapping from TechnologyOne depreciation codes to Epicor Depreciation Method lookup values. We flag any depreciated asset that has a remaining net book value incompatible with Epicor's depreciation engine for manual review before import.

HR and payroll records from TechnologyOne HR module, including compensation history, job titles, department assignments, and effective-dated changes, migrate to Epicor HR (if deployed) or to a flat employee table for import. Effective-dated change sequences require careful ordering to preserve the most recent active record state. Employees are mapped to Epicor Cost Centres and Locations if the HR module is not in scope. We do not migrate payroll tax configurations or direct payroll feeds; those require reconfiguration with the customer's payroll provider.

Purchase orders, purchase requisitions, and receipt records in the TechnologyOne Procurement module migrate to Epicor PO and Purchase Demand records. We extract PO header fields (vendor, date, terms, status), PO line items (part number or description, quantity, unit cost, UOM), and receipt history. Approval workflow states and approval history from TechnologyOne are documented as notes on the migrated PO because Epicor's approval routing must be rebuilt in Epicor Kinetic approval chains. Workflow states like Pending Approval, Approved, and Closed are mapped to Epicor PO status values.

TechnologyOne ECM stores documents, document sets, compound documents, and custom document fields via the EzeScan connector (CMIS-compatible endpoints). We extract document metadata (document type, description, custom fields, parent reference) and binary attachments. The custom document field discovery requires a pre-migration field audit against the live ECM environment because there is no self-documenting schema endpoint for custom fields. Missed custom fields result in blank values in Epicor's document management; we run the audit to prevent this. Document parent relationships map to Epicor Reference fields on the linked entity (AP Invoice, AR Invoice, PO, Asset, Employee).

The Property and Rating module is specific to TechnologyOne local government customers and has no equivalent in Epicor ERP's standard object model. Epicor does not include a property assessment, rates billing, or council charge module. We offer two options: (1) archive the Property and Rating data as a flat exported table for reference, or (2) map it to Epicor's User-Defined Tables (UDTs) if the customer requires ongoing access within Epicor. The billing engine uses custom calculation rules that require manual transformation. We document the full schema and calculation logic during discovery for the customer to rekey or rebuild in a purpose-built rates module.

Custom fields added to any standard TechnologyOne object are stored in the dataset without a unified custom field registry. We discover all custom fields during the discovery phase by querying the dataset directly and cross-referencing form definitions. Each custom field is mapped to an Epicor UDF on the equivalent entity, with type mapping (text to String, number to Decimal, date to Date, checkbox to Boolean). Multi-select custom fields map to Epicor Character01-style string fields with delimiter conventions agreed during scoping. UDMs (User-Defined Methods) tied to custom fields do not migrate.

TechnologyOne user accounts and role-based security profiles are tied to the CiA internal identity layer and role/user interface configuration. We do not migrate user accounts because they must be recreated in Epicor Identity Manager with the customer's Epicor tenant. We document the TechnologyOne role hierarchy (which roles have access to which modules, forms, and functions) as a Role Map deliverable so the Epicor administrator can assign equivalent permissions in Epicor's Kinetic Role maintenance. This is a manual step that the customer completes before cutover.