Migrate from Digit to Microsoft Dynamics 365 Business Central

DIGIT Citizen records map to Dynamics 365 Contact. Citizen UUID becomes an external identifier field (citizen_uuid__c) for cross-system reference. We create a custom Contact field government_entity__c (boolean) to flag citizen records migrated from DIGIT, and preserve the original citizen identifier as a lookup anchor in case the organisation needs to reference the original DIGIT citizen service history. PGR complaint associations migrate to Case records linked to this Contact. Note that DIGIT Citizens do not map to Leads because government service entities are always identified and tracked, not marketed-to prospects.

Property Tax records in DIGIT (assessment value, owner association, boundary, payment history) have no direct Dynamics 365 Finance standard equivalent. We assess the primary use case during scoping. For municipalities focused on property tax billing, PT records map to a custom Property__c object with fields for assessment_value__c, property_type__c, zone__c, owner_name__c, and boundary_reference__c, linked to the Contact owner via Lookup. For organisations needing asset tracking of municipal infrastructure, PT records map to Dynamics 365 Asset Management (available in Finance and Operations). The DIGIT demand register (outstanding property tax) maps to Accounts Receivable invoice records or a custom demand record object.

Trade Licence records map to a custom Business_Licence__c object we provision in Dynamics 365 during schema design. Fields include licence_number__c, business_name__c, category__c (mapped from DIGIT trade category), issue_date__c, expiry_date__c, status__c (Active, Expired, Revoked), and issuing_authority__c. The TL Citizen reference resolves to a Contact lookup on Business_Licence__c. Licence category picklist values are extracted from DIGIT localisation files and populated as Dynamics 365 global picklist values.

PGR complaints migrate to Dynamics 365 Case with status, priority, and department assignment preserved. DIGIT complaint workflow states (Lodged, Assigned, In Progress, Resolved, Closed) map to Case Status values and a custom workflow_stage__c field. Department assignments from DIGIT become Case Teams or Queues in Dynamics 365 Service. The original complaint timeline (created date, assigned date, resolution date) migrates as Case activity records. PGR module attachments migrate as Note or SharePoint document attachments linked to the Case.

FSM sanitation, drainage, and desludging service requests map to Dynamics 365 Field Service WorkOrder. DIGIT FSM workflow states (New, Assigned, In Progress, Completed, Closed) map to WorkOrder SystemStatus and FieldServiceStage values. FSM asset associations (vehicle, equipment) map to BookableResourceBooking linked to the WorkOrder. If the destination Dynamics 365 tenant does not include Field Service licensing, FSM records map to custom FSM_Request__c with equivalent fields. Routing history migrates as WorkOrderIncident records.

DIGIT HRMS employee records map to Dynamics 365 Human Resources Worker. Employee number, name, department, designation, and employment status transfer directly. Leave balance history migrates as WorkerLeaveEntry records. However, DIGIT role-permission assignments are deployment-specific configurations that do not map to Dynamics 365 Security Roles without manual reconciliation. We flag all HRMS role assignments in a separate HRMS_Role_Map__c file for the customer's HR admin to rebuild as Dynamics 365 Security Roles and HRMS role assignments post-migration.

DIGIT demand registers (property tax billing, FSM service invoices) store outstanding and paid demand with status flags. For Dynamics 365 Finance and Operations destinations, these map to CustInvoiceJour (Accounts Receivable journal lines) with InvoiceAccount, InvoiceDate, and AmountMST fields. For non-Finance Dynamics 365 CRM destinations, demand records map to a custom Demand__c object with status__c (Raised, PartiallyPaid, Paid, Overdue) and amount__c. The demand record to Citizen link is preserved via Contact lookup.

DIGIT localisation files contain region-specific labels, business rules, and module configurations that are specific to the deployment's government context. We extract all localisation files during migration and deliver them as a managed package alongside the migrated data. The customer's Dynamics 365 admin applies the equivalent regional labels via Dynamics 365 translation and customisation tools (Data Management framework, Power Platform environment variables, or Dataverse column metadata). We do not automate the application of localisation files because they represent government-specific compliance and language settings that require human review before activation.

DIGIT boundary definitions (municipal zone, ward, block) stored in the PT module map to a custom Geographic_Boundary__c object with fields for boundary_type__c (Ward, Block, Zone, Circle), boundary_code__c, parent_boundary__c (self-lookup for hierarchy), and geometry_reference__c. This preserves the spatial hierarchy used for property assessment jurisdiction without requiring a GIS integration.

Property tax assessment records (annual assessment value, effective date, assessment reason, exemptions) map to a custom Property_Assessment__c object linked to the Property__c record. Annual assessment history is preserved as a child record list, which allows the Dynamics 365 admin to query historical assessments per property for reporting.

DIGIT TL licence applications (pending, approved, rejected) with workflow history split into two Dynamics 365 objects: a Business_Licence_Application__c record for the application lifecycle and related Case records for the adjudication workflow steps. This preserves the application progression without attempting to map DIGIT module-specific workflow states to Dynamics 365 Case status values directly.

PGR complaint action history (all status changes, department reassignments, citizen communications) migrates as a chronological list of Task and EmailMessage records attached to the Case, preserving the full audit trail of government grievance handling. Action timestamps use the original DIGIT created_date for ordering.