Migrate from Digit to Epicor Prophet 21

DIGIT Citizen records map to Epicor Customer entities. The Citizen UUID becomes the Epicor CustNum or an external reference field. Citizen address, phone, and email map to Customer address and contact records. We extract cross-module links (citizen-to-property, citizen-to-complaint, citizen-to-service-request) during export and preserve them as Epicor CustomerContact or ShipTo links depending on the Epicor configuration. Active citizen status from PGR determines Customer status (active/inactive) in Epicor.

DIGIT property records map to Epicor in two ways depending on use case. For property-tax billing migration, properties map to Epicor Customer ShipTo records with the property address as ShipTo address and the assessment value stored as a custom numeric field. For commercial property assets, properties map to Epicor Part records with Part Type=NonStock. We use the DIGIT PT boundary and assessment data to populate Epicor Part or ShipTo fields and preserve the ulb (Urban Local Body) identifier as a reference field.

DIGIT Trade Licence records are mapped to Epicor Customer records with trade licence category and licence number stored in custom fields. If the migration involves commercial inventory associated with a trade licence (e.g., a licensed food vendor), the associated inventory maps to Epicor Part with the licence reference as a Part comment or UD field. We preserve licence status, issuance date, and expiry date as custom fields on the Epicor Customer record.

DIGIT PGR complaint records map to Epicor Kinetic Service Call (case management) entities. The complaint workflow state (New, Assigned, WIP, Resolved, Closed) maps to Service Call status values. Department assignment from DIGIT maps to Epicor Project or Work Resource depending on Epicor Kinetic FSM configuration. We preserve the full complaint timeline (status changes, action history, resolution notes) as Service Call activities and attach the original citizen identifier for audit.

DIGIT FSM sanitation, drainage, and desludging service requests map to Epicor Kinetic Field Service or Work Order records. FSM vehicle assignment and route data map to Epicor Resource and Resource Group fields. Service completion records and asset associations migrate as Work Order operations with labour and materials. We extract FSM workflow state and preserve it as the Epicor Work Order status with completion notes migrated as operation comments.

DIGIT HRMS employee records map to Epicor EmpBasic (Employee) records or export to a linked HRIS. Employee roles and department assignments migrate as Epicor Resource or UserGroup assignments. We flag that role-permission mappings are deployment-specific and carry a manual validation step post-migration. Leave balances and HRMS-specific fields that have no Epicor native equivalent migrate as custom numeric fields on EmpBasic for the customer's HR admin to reconcile against their HR policy.

DIGIT demand records (property tax bills, FSM service invoices) do not have a direct Epicor equivalent in standard financial modules. We map active demand records to Epicor AR Invoice records linked to the corresponding Customer (citizen). Demand status flags (paid, pending, overdue) map to Invoice status. Historical demand records that are fully closed and do not require financial carry-forward are flagged for archiving rather than active migration to avoid inflating the Epicor financial ledger with historical closed items.

DIGIT JSON/CSV localisation files (region-specific labels, compliance rules, module configurations) cannot migrate as a file to Epicor. We extract the applicable locale settings (language, fiscal year conventions, tax rate configurations, compliance metadata) and map them to Epicor System Configuration values and Epicor Tax Register settings. Multi-language labels that DIGIT stores per locale migrate as Epicor Business Object labels or custom UD fields depending on Epicor edition.

DIGIT PT boundary definitions (municipal ward boundaries, revenue circle definitions) have no direct Epicor ERP equivalent. We extract boundary data during export and deliver it as a structured reference document for the customer's GIS team or Epicor admin to configure as Regions or Sites in Epicor if the deployment includes multi-site operations. This is a configuration step, not a direct data migration.

DIGIT module-specific business rules (workflow triggers, routing logic, approval chains) do not migrate as executable code to Epicor ERP. Epicor Kinetic uses Business Process Management (BPM) for workflow rules, which operates differently from DIGIT's module-trigger model. We deliver a written inventory of every DIGIT workflow and business rule with its trigger condition, action sequence, and a recommended Epicor Kinetic BPM equivalent for the customer's admin to rebuild.

Heavily customised DIGIT installations with additional module tables beyond the standard PT/TL/PGR/FSM/HRMS schema require custom mapping. We assess the deployment's extended schema during discovery, document non-standard tables, and map them to Epicor Kinetic custom UD (User-Defined) tables with equivalent field types. Custom field names and data types are preserved as UD column definitions with appropriate Epicor data type mappings.

DIGIT user assignments on Citizen, Property, Complaint, and FSM records map to Epicor User records by email match. Any DIGIT user without a matching Epicor User record goes to a reconciliation queue for the customer's admin to provision before record import resumes. Inactive DIGIT users map to inactive Epicor User records to preserve assignment history without generating active licenses.